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