为什么 ZeroMQ 不应该成为你的第一选择

Tyler Treat 是一名软件开发人员，他近日发表了一篇博文《为什么ZeroMQ 不应该成为你的第一选择》。

文中，Tyler Treat 对 nanomsg 和 ZeroMQ 进行了比较。nanomsg 是一个套接字库，提供了多种常见的通信协议，其目标是使网络层更快、更具扩展性、更容易使用。它用 C 进行了彻底地重写，可以说是对 ZeroMQ 的重建。它构建在 ZeroMQ 的可靠性能之上，同时又提供了若干重要的改进。而且，它还试图消除 ZeroMQ 经常出现一些怪异行为。作者从以下几个方面对二者进行了比较：

• 用于新传输协议的 API——对于 ZeroMQ，人们经常抱怨的问题是它没有提供用于新传输协议的 API，这从根本上把用户限制在 TCP、PGM、IPC 和 ITC 上。而 nanomsg 提供了一个可插拔的接口，用于新的传输（如 WebSockets）和消息协议。
• POSIX 兼容性——nanomsg 完全兼容 POSIX，而且 API 更简洁，兼容性更好。在 ZeroMQ 中，套接字用空指针表示，然后绑定到上下文；而在 nanomsg 中，只需要初始化一个新的套接字并使用它，一步即可完成。
• 线程安全——ZeroMQ 在架构上有一个根本性缺陷：其套接字不是线程安全的。在 ZeroMQ 中，每个对象都被隔离在自己的线程中，因此不需要信号量和互斥锁。并发是通过消息传递实现的。nanomsg 消除了对象与线程间的一对一关系，它不再依赖于消息传递，而是将交互建模为一组状态机。因此，nanomsg 套接字是线程安全的。
• 内存和 CPU 使用效率——ZeroMQ 使用一种很简单的 Trie 结构存储和匹配发布 / 订阅服务。当订阅数超过 10000 时，该结构很快就显现出不合理之处了。nanomsg 则使用一种称为“基数树（radix tree）”的结构来存储订阅，并提供了真正的零复制 API，允许内存从一台机器复制到另一台机器，而且完全不需要 CPU 的参与，这极大地提高了性能。
• 负载均衡算法——ZeroMQ 采用了轮转调度算法。虽然该算法可以平均分配工作，但也有其局限性。比如，有两个数据中心，一个在伦敦，一个在纽约。在理想情况下，一个位于伦敦数据中心的网站，其请求不应该路由到纽约。但在ZeroMQ 的负载均衡算法里，这完全有可能。而 nanomsg 避免了这种情况的出现。

除此之外，文中还提到，nanomsg 提供了一个名为 nanocat 的命令行工具，用于与系统进行交互。

作者继续写道，nanomsg 旨在实现“可扩展协议（Scalability Protocols）”，用于构建可扩展的高性能分布式系统。当前，它定义了六种不同的可扩展协议：PAIR、REQREP、PIPELINE、BUS、PUBSUB 和 SURVEY。

既然 nanomsg 在 ZeroMQ 的基础上做了如此多的改进，那我们为什么还要用 ZeroMQ 呢？针对这个疑问，作者指出，nanomsg 还相对年轻，它还没有达到 ZeroMQ 的成熟度，没有像 ZeroMQ 那样有一个繁荣的开发者社区。另外，ZeroMQ 有丰富的文档及其它资源，可以帮助开发人员使用它，而 nanomsg 的文档非常少。

尽管如此，作者还是认为 nanomsg 所做的改进，尤其是它的可扩展协议，使它非常有吸引力。从技术上讲，从三月份开始，nanomsg 就已经开始 beta 测试，因此，生产就绪版本已经指日可待。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。