0

我正在尝试评估不同的发布/订阅消息协议的水平扩展能力，而不会产生不必要的交叉对话。

我的架构将连接带有 Web 套接字客户端的 NodeJS 服务器。我计划使用一致的基于散列的路由器根据他们感兴趣的主题将客户端引导到服务器。这意味着对于给定的主题，只有一部分服务器会有订阅该主题的客户端。然后消息将发布到发布/订阅代理，该代理负责将数据散播到有订阅者的服务器。

我要避免的情况是每个代理都收到每个请求，并且网络变得饱和。这是扩展 Redis Pub/Sub 的一个明显问题。添加服务器不应产生 n 方问题。

pub/sub 协议上的客户端数量就是服务器的数量。理想情况下，每台服务器都可以有一个本地代理来有效地将数据扇出到多个 NodeJS 进程，以避免不必要的网络带宽。在大多数情况下，对于给定的主题，所有订阅者都在同一台服务器上。

哪些发布/订阅协议提供这种基于主题的数据传播？

我正在评估的协议是：MQTT、RabbitMQ、ZMQ、nanomsg。这不包括在内，并且 SAAS 选项是可以接受的。

质量保证约束很容易。最多一次，或至少一次都足够了。承认并不重要。事件顺序并不重要。我们正在寻找一劳永逸的方法，重点是水平可扩展性。

4

1 回答 1

0

首先，让我解决误解的风险

在许多情况下，相似的词并不意味着同样的事情。缩写越多。

话虽如此，让我回顾一下PUB/SUB终点技术。

Martin SUSTRIK 和 Pieter HINTJENS 的 imatix & 250bpm 团队在过去的几十年中开发了一些智能消息传递框架，所以这些人对架构的好处、约束和实现妥协了如指掌。

这有助于我说明这些引入现代消息传递基础的父亲并不认为PUB/SUB是一种协议。

至少在nanomsg&中ZeroMQ，它是一种智能的以分布式 可扩展性为中心的正式通信模式——即所有相关方都模仿的行为。

两者ZeroMQ都nanomsg 没有经纪人。

从这个意义上说，问“什么协议”没有坚实的根据。

让我们从“数据传播”方面开始

在最初的 ZeroMQ 实现PUB中，没有其他选择，只能将所有消息分发给所有SUB处于connected-state 的 -s。Pieter HINTJENS 多次解释了这个决定，即实际的基于订阅的过滤是在端执行的SUB（以 1:all-connected 方式分布）。

实现PUB基于订阅的过滤要晚得多，您可以检查修订历史以查找从哪个版本开始避免 1:all-connected 数据广播。

同样，您可以查看nanomsgMartin SUSTRIK 的评论，他发表了许多关于在他的精彩nanomsg项目中设计的性能改进的深入帖子。

可扩展性作为优先事项 No.1

如果Scaleability是你的帖子的重点，如果它是一个严肃的项目，我的第一个问题是根据这样的项目目标比较可行候选人的量化指标是什么- 即，什么是可行性转化为实用函数来为候选人评分比较您的项目感兴趣的所有并行属性？

于 2015-09-27T13:39:50.577 回答