我正在尝试评估不同的发布/订阅消息传递协议的横向扩展能力，而不会产生不必要的交叉聊天。
我的架构将有连接了Web套接字客户端的NodeJS服务器。我计划使用一致的基于哈希的路由器根据他们感兴趣订阅的主题将客户端引导到服务器。这意味着对于给定主题，只有一部分服务器将具有订阅该主题的客户端。然后，消息将发布到pub / sub代理，该代理负责将该数据扇出到具有订阅者的服务器。
我想避免的情况是每个代理接收到每个请求，并且网络变得饱和。这是缩放Redis Pub / Sub的明显问题。 Adding servers shouldn't create an n squares' problem
发布/订阅协议上的客户端数量是服务器数量。理想情况下，每个服务器都可以使用本地代理将数据有效地扇出到多个NodeJS进程，以避免不必要的网络带宽。在大多数情况下，对于给定主题，所有订阅者都将位于同一服务器上。
哪种pub / sub协议提供这种基于主题的数据传播？
我正在评估的协议是：MQTT，RabbitMQ，ZMQ，nanomsg。这不包括在内，SAAS选项是可以接受的。
质量保证限制很容易。最多一次，或至少一次都足够。致谢并不重要。事件顺序并不重要。我们正在寻找火，忘记，强调水平可扩展性。
答案 0 :(得分：0)
在许多情况下，类似的词语并不意味着相同的事情。缩写越多。
话虽如此，让我回顾一下 PUB / SUB 终端技术。
Martin SUSTRIK和Pieter HINTJENS的团队在imatix＆amp; 250bpm在过去几十年中开发了一些智能消息传递框架，因此这些人对架构优势，约束和实现妥协有很多了解。
这说明让我说这些引入现代消息传递理由的父亲不会考虑 PUB / SUB 来是一个协议。
至少在nanomsg＆amp; ZeroMQ，而非智能分布式 可扩展性 - 聚焦正式沟通模式 - 即模拟行为所有有关方面。
ZeroMQ和nanomsg 都是经纪商。
从这个意义上说，问“什么协议”没有坚实的理由。
在最初的ZeroMQ实施中， PUB 别无选择，只能将所有消息分发到{{1}中的所有 SUB -s }}-州。 Pieter HINTJENS多次解释这一决定，即基于订阅的实际过滤是在 connected -side上进行的（以1：全连接方式分发）。
稍后实施 SUB - 基于订阅的过滤，您可以检查修订历史记录，以查找此开始避免的版本1：所有连接的数据广播。
同样，您可以查看Martin SUSTRIK的 PUB 评论，他们在他精彩的nanomsg项目中提供了很多关于性能改进的深度帖子。
如果 nanomsg 是你的帖子的重点，如果它是一个严肃的项目，我的第一个问题将是定量度量用于根据此类项目目标比较可行候选项 - 即，将可行性转换为效用函数以对候选项进行评分以比较项目感兴趣的所有并行属性？