如果我要设计一个巨大的分布式系统，其吞吐量应该与系统中的订阅者数量和通道数量成线性关系，哪个更好？
1）Redis Cluster（仅适用于Redis 3.0 alpha，如果它是集群模式，你可以在一个节点上发布并在另一个完全不同的节点上订阅，消息会传播并到达你）。Publish 的复杂度是O(N+M)，其中 N 是订阅客户端的数量，M 是系统中订阅模式的数量，但是在 Redis 集群中它如何扩展？我接受有根据的猜测。
2) ZeroMQ从 3.x 开始，它进行服务器端过滤，所以它也有一些时间复杂度，但我在文档中没有看到任何关于它的内容。如果我想扩展它，我可以让许多服务器发布到任何频道，每个订阅者将连接到所有服务器，并订阅所需的频道。这看起来不错。
那么，对于大型发布者系统的横向扩展，哪一个更适合呢？我应该研究哪些其他解决方案？请记住，我想最小化延迟和吞吐量，但能够水平扩展。
我猜你想最小化延迟。通道数无关紧要。关键因素是发布者的数量和订阅者的数量，消息大小，每个发布者每秒的消息数量，每个订阅者接收到的消息数量，大致。ZeroMQ 每秒可以从一个节点到另一个节点处理数百万条小消息；您的瓶颈将在软件出现之前很久就出现在网络上。因此，大多数大容量 pubsub 架构使用 ZeroMQ 支持的 PGM 多播之类的东西。
在 Redis 中，就像在 ZeroMQ 中一样，瓶颈将是网络。Redis 每秒可以达到数百万条消息，至少与 ZeroMQ 一样多。
您应该知道，Redis 集群的当前实现使用节点间总线在所有集群节点上分发 PUBLISH 消息。这种方法假设 PUBLISH 在 Redis 上非常便宜（如Github 上的本期所述）。
但是，涉及的开销很小，即节点间通信。当您扩大规模时，这种开销将更加显着。我知道还有另一种Redis Cluster 实现——请注意，它是一种商业实现——其中通道或模式以与 Redis 密钥分布方式类似的方式分布在集群节点上。至少根据供应商的说法，这应该可以节省节点间通信的开销并提高性能，但我自己没有进行基准测试。