你使用 ZeroMQ 作为通用消息中间件的经验如何?
- 你是否遇到了任何严重的错误或不明显的“特性”?例如,2.0 版本不能正确地刷新消息,而 故障排除指南 看起来给出了一个最可怕的解决方案:“在退出前睡眠1秒钟”。
- 这个 API 是否减少了应用程序的复杂性,还是证明它很麻烦?
- 向后兼容性是否经常会被打破?
我正在用它进行研究,因此是“半生产”状态。这是一个很棒的框架,一旦你完全掌握了它的架构,事情的安排肯定是有道理的。但是我遇到了太多问题,以至于无法考虑将其用于生产。我正在使用jzmq,所以其中一些问题可能特定于它。
但是,这是一个重要的优点,我无法计数它为我节省了多少人工时。这篇文章有一个很好的总结,列举了它使生活更加愉快的几种方式。
我在一个“半生产”环境中(DARPA的原型设计)也使用了ZeroMQ。到目前为止,特别是当这些程序被用不同语言编写且运行在不同机器上时,它对于“连接应用程序”非常有效。可用的套接字惯用语使得思考分布式计算问题变得非常直观。ZeroMQ的优势在于其人体工学:它有一个坚实的心智模型和丰富的语言绑定。
然而,如果您面临严格的性能限制,请小心谨慎。我正在开发一个实时系统,并发现虽然ZeroMQ旨在成为高性能解决方案,但它尚未准备好进入主流市场。我认为其现有架构具有很大的潜力;只是似乎受到一些小错误的妨碍。从0.0到3.0的库的演变如此迅速,我可能应该预料到这种情况。即使如此,我仍然认为我会获得自己手动构建的协议栈的替代品并立即遇到一些不能容忍的问题。如果您决定采用ZeroMQ,只需记住您正处于传输层之上,如果性能不理想,则几乎无能为力。
话虽如此,邮件列表和IRC频道上的聊天内容非常棒。开发人员似乎真正有兴趣构建一些完全先进的东西。他们喜欢他们的库受到关注并被用于严肃而有趣的事情。他们是忙碌的人,所以不要期望他们提供大量帮助。但是,如果您遇到了真正的问题,他们会很乐意了解情况。
底线:一个出色的瑞士军刀,可用于日常分布式计算问题。如果您正在寻找最新性能,请谨慎对待;至少还需要一个主要版本的发布。然而,这个项目的未来看起来很美好,因此使用它并支持它。