zmq vs redis 用于发布-订阅模式答案

【问题标题】：zmq vs redis for pub-sub patternzmq vs redis 用于发布-订阅模式
【发布时间】：2013-09-06 16:06:43
【问题描述】：

redis支持pub-sub
zmq也支持pub-sub via a message broker

在它们之间进行选择的架构优缺点是什么？
我的目标是超出应该完成的明显的用例特定性能基准测试（这里是a nice example）。

假设使用 Python 等高级语言。

【问题讨论】：

嘿，如果所有 * 的答案都是量身定制的，并且像您引用的很好的示例一样深入，那就太好了：) 但它的方式使您的问题过于开放。也许您应该尝试确定您正在苦恼的一些具体差异或权衡，然后重新发布更具针对性的问题。
但是感谢您的博客链接......它看起来是一篇很棒的文章。
这是给n-to-n pub/sub 的吗？
@raffian - 是的 n-to-m 用例。顺便说一句，除了 n-to-m 之外，您还会使用 pub-sub 的用例吗？
您需要考虑 ZeroMQ LGPL 许可证吗？ wiki.zeromq.org/area:licensing

标签： architecture redis zeromq publish-subscribe design-consideration

【解决方案1】：

我自己一直在研究这个，因为我需要决定是使用 Redis pubsub 还是 ZMQ pubsub 作为分布式系统的通信层。我认为 Redis 和 ZMQ 在应用程序的设置方式上有所不同。

ZMQ pubsub 天生就直接连接，即没有中间人。
您可以创建类似中间人的实例，例如转发设备
对于 Redis pubsub，订阅者和发布者都需要连接到 Redis。

ZMQ 中缺少中间人意味着订阅者需要以某种方式知道连接到发布者以获取消息。在我的系统中，应用程序生成需要向订阅者发送信息的发布者，如果没有订阅者在我的应用程序启动之前连接的转发器设备，就无法做到这一点。

延迟在我的系统中很重要，因为我希望远程盒子尽可能快地完成任务。

Zmq (direct pubsub)
avg: 0.000235867897669
max: 0.0337719917297
min: 0.000141143798828

Zmq (w/ forwarder)
Avg: 0.00237249334653
max: 0.00536799430847
min: 0.000249862670898

Redis (8gb ram)
avg: 0.000687216520309
max: 0.0483138561249
min: 0.000313997268677

Redis (32gb ram)
avg: 0.000272458394368
max: 0.00277805328369
min: 0.000216960906982

如果您的应用程序位于订阅者端，那里有您想要从中获取信息的发布者守护进程，那么我会选择 ZMQ，因为您可以直接连接到发布者。
如果您的应用程序在发布者端，那么我会去 Redis 发布订阅，因为订阅者已经连接到 Redis 监听。

【讨论】：

你会记得这些数字的单位吗？秒？毫秒？

【解决方案2】：

我曾使用 python 使用过 ZeroMQ 和 Redis。我会说 ZeroMQ 更健壮，它提供了真正简单的负载平衡，而且比 pub-sub 更多，比如请求回复等。但是如果你只追求pub-sub，redis就简单多了。

如果redis服务器崩溃或停止工作，所有客户端也将停止工作，使用ZeroMQ，即使没有服务器，客户端也可以工作。

这两种服务都适用于任何编程语言、ruby、python、C、C++ 等。

总之，redis 简单很多，很可靠。 ZeroMQ 非常可靠但更复杂。

如果我只做 pub sub，我会选择 redis，否则我会选择 ZeroMQ。如果我能预见到巨大的流量，我会选择 ZeroMQ

【讨论】：

ZeroMQ 如何处理服务器崩溃？
不知道他们是怎么做到的。但是即使没有服务器在运行，您也可以启动客户端并发布消息。您启动服务器，事情仍然发生。我所知道的是它工作得很好，非常有弹性和健壮，并且可以很好地处理崩溃，尽管在合理范围内
IIRC，它运行一个单独的线程/进程，将消息保存在该线程中。因此，您永远不会真正直接在套接字级别进行接口。消息和断开连接都可以方便地在 ZMQ 线程中异步处理，而您的应用程序正在执行它。

【解决方案3】：

这就是我的决定。使用每个产品制作最少的测试用例。看看哪个更容易构建并且效果更好。将每个测试用例推得更远一点，然后因为工作量太大而丢弃一行。

【讨论】：

我确实做到了，但我更愿意向人群咨询我可能会在路上发现的事情......最初的障碍可能会产生误导

【解决方案4】：

ZeroMq 的优点/缺点

Pub/sub 节点可以独立连接和断开连接；消息根据 HWM 设置保存到缓冲区，在对等可用时自动发送（存储和转发）
如果对等点失败，缓冲的消息将丢失
主题订阅仅支持带有 pub/sub 封装的前缀匹配； NEWS订阅匹配NEWS*消息

Redis 的优点/缺点

AOF 快照到磁盘会在 redis 失败时保留消息
Pub/sub 客户端依赖 redis 进行连接
支持news.* 等选择性主题订阅的通配符匹配

【讨论】：