可扩展的实时发布/订阅引擎答案

【问题标题】：Scalable Pub/Sub engine for realtime可扩展的实时发布/订阅引擎
【发布时间】：2011-11-20 15:58:27
【问题描述】：

我正在寻找具有以下要求的发布/订阅引擎：

我希望能够拥有多个发布/订阅服务器，并且能够从任何服务器发布或订阅频道，无论在哪个服务器上声明了频道。

例如：

如果用户A连接到服务器SRV1并且用户B连接到服务器SRV2，如果用户 B 订阅“MyChannel”，用户 A 在频道“MyChannel”上发布内容，用户 B即使他没有连接到同一台服务器也会收到消息。

我不知道 Redis 是否能够做到这一点。我没有找到有关该主题的任何信息。

【问题讨论】：

试试activeMQ？ activemq.apache.org
这听起来像是我们在Pusher 构建的基础架构。我们使用 WebSocket 服务器实现客户端和服务器之间的低延迟连接，使用 AWS ELB 实现负载平衡以及队列技术的组合。第 3 点对我们来说还不是大问题，但我们正在研究。
嗨！查看 [Realtime.co][1] [1]：framework.realtime.co

【解决方案1】：

nanomsg 是ZeroMQ 的继承者，由同一作者编写，并具有多种语言绑定。

它是用 C 语言编写的，并使用零拷贝机制。如果您正在寻找出色的延迟，并且愿意亲自动手（如果您的目标是极端的，那么您应该这样做），我会推荐这两者之一。

如果您正在寻找卓越的吞吐量，请选择Kafka。

注意，这些解决方案都没有实现开箱即用的地理定位，Redis 3.2 会有一些东西：http://antirez.com/news/89

如果您正在寻找一个简单、“足够好”的解决方案，我会选择Redis（请务必先阅读this blog post from aphyr）。

【讨论】：

是的，nanomsg 是聪明的妹妹，已经广为人知的ZeroMQ 杰作。对于真正的见解，更多的是软-实时生态系统设计，值得一读 Martin Sustrik 的精彩博文和出版物 >>> 250bpm.com 关于协同程序和其他智能笔记 + Pieter Hintjens 的书 pdf ：“Code Connected, Vol.1”。（顺便说一句。500 毫秒的延迟是一个非常非实时的标准，基础设施是问题所在，糟糕的第 3 层传输服务可能会使会议无效这样的限制。ZeroMQ 和 nanomsg 都具有出色的延迟避免，剃掉 ns(!s))

【解决方案2】：

您似乎正在寻找某种消息。尝试RabbitMQ，使用shovel 或federation 插件

【讨论】：

【解决方案3】：

我建议你看看Data Distribution Service for Real Time Systems (DDS) 标准。它专门设计为可扩展的发布/订阅中间件，适用于实时和非实时系统。

它有一些成熟的实现，它们都有自己的优势，但通常实现是可扩展的和低延迟的。

这些是我建议您查看的实现（如果您需要它们在 WAN 环境中工作，我想前两个对此有很好的支持）：

【讨论】：

【解决方案4】：

我们一直在使用ZeroMQ，它的发布/订阅功能现在已经有一段时间了，我们对所看到的非常满意。

还值得关注下一个version 中的内容（通过向上游推送订阅请求来减少网络带宽）

【讨论】：