messaging - ZeroMQ 生产准备好了吗？

Question

您对 ZeroMQ 作为通用消息传递中间件有何经验？

1. 您是否遇到过任何令人震惊的错误或不明显的“功能”？例如 2.0 没有正确刷新消息，故障排除指南似乎给出了最可怕的解决方法：“sleep(1)退出前”。
2. API 是否降低了应用程序的复杂性，还是被证明很麻烦？
3. 向后兼容性是否经常被破坏？

Answer 1

我将它用于研究，因此是“半生产”。这是一个很棒的框架，一旦你完全理解它，事物的架构方式肯定是有意义的。但是我遇到了太多问题，无法考虑将其投入生产。我正在使用 jzmq，所以其中一些可能是特定的。

1. 在 OS X / Eclipse 上设置 jzmq 是……不愉快的。
2. 启动应用程序偶尔会导致 ZeroMQ C 代码中的断言失败，因此我需要将我的应用程序包装在检查这种异常状态的东西中。
3. 错误通常是非常难以描述的。我有太多没有解释性信息的非法状态异常。
4. 不支持 TLS。这对我来说几乎是一个交易破坏者，我可以很容易地看到它排除了它对许多应用程序的可用性。
5. 文档已“关闭”。官方指南很好，但如果您有特定问题，通常没有帮助。在谷歌搜索时，我需要比平时更长的时间才能找到问题的答案。然而，邮件列表非常活跃。

但是，这是一个很大的但是，我无法计算它为我节省了多少工时。这篇文章很好地总结了它使生活更愉快的一些方式。

Answer 2

我还在“半生产”环境（DARPA 的原型设计）中使用 ZeroMQ。到目前为止，“将猫绑在一起”确实非常出色，尤其是当这些猫用不同的语言编写并生活在不同的机器上时。可用的套接字习语使思考分布式计算问题变得非常简单。ZeroMQ 的优势在于人机工程学：坚实的心智模型和丰富的语言绑定。

但是，如果您遇到严格的性能限制，请谨慎行事。我正在开发一个实时系统，并发现虽然 ZeroMQ 旨在成为一个高性能的解决方案，但它还没有准备好迎接黄金时段。我认为现有的架构具有巨大的潜力。它似乎只是被一些琐碎的错误所阻碍。对于一个发展如此迅速的库，我可能应该预料到这一点，在相对较短的时间内从 0.0 到 3.0。不过，我想我会得到一个替代我自己的、手工工具的协议栈的替代品，并立即遇到一些交易破坏者。如果您决定使用 ZeroMQ，请记住您在传输层之上工作得很好，如果性能不如预期，那么您几乎无能为力。

话虽如此，邮件列表和 IRC 频道上的闲聊非常棒。开发人员似乎真的对构建完全最先进的东西感兴趣。他们喜欢他们的图书馆有嗡嗡声，并且习惯于处理严肃、有趣的事情。他们是忙碌的人，所以不要指望大量的牵手。但是，如果您遇到真正的问题，他们很想知道发生了什么。

底线：解决日常分布式计算问题的一把伟大的瑞士军刀。如果您正在寻找最先进的性能，请谨慎行事；它至少是一个主要版本。尽管如此，这个项目的未来看起来很棒，所以使用它并支持它。

Answer 3

免责声明：这来自以前从未使用过 AMQP 或任何其他类似产品的人。

糟糕的文档是糟糕的。（如果没有 .Net 和 C# 的文档，C# 会很糟糕）所以如果你知道如何使用 ZMQ，它可能是最好的东西，但是存在的文档（不是很多）非常糟糕（我们是如此聪明，这太好了，Erlang，等等等等，指南中没有一个 n 对 n 的例子......）。
你说什么，大多数操作系统项目的文档都不好或没有。是的，但是对于相当多的操作系统项目，你可以用谷歌搜索大量的东西（教程、示例......）。对于 ZMQ，它是：零用于文档。由于我是 C++ 开发人员，我会这样说。在尝试使用 ZMQ 之前，我认为 boost 的文档很糟糕，并且互联网上的示例相对较少。但与 ZMQ Boost 相比，文档很棒，示例也很多。

编辑：让事情变得更有趣（内战：P）： http: //www.infoq.com/news/2012/03/Crossroads-IO

最初的 ZeroMQ 的创建者 Martin Sustrik 和 Martin Lucina 决定通过分叉来重新获得对该项目的控制权。这个名为 Crossroads I/O 的新项目正在建立，以鼓励能够更好地满足其长期财务需求的商业生态系统。

EDIT2：复制和运行指南中的示例（“A Request-Reply Broker”的cpp版本）不起作用。您可以通过他们没有将示例作为测试的事实来了解库开发过程有多好。:P
EDIT3：一些示例在 v2.* 中，ofc 最新版本是 v3.2。所以这又一次闻起来像一个腐烂的无人维护的操作系统项目。