ZeroMQ和RabbitMQ的对比

在分布式架构的不同程序间以及程序的不同模块间进行消息传递是通用的业务场景. 消息服务框架为消息处理提供语义清晰的API, 为基于消息的程序架构提供解耦以提高可扩展性,也可能提供某种形式的高可用性.关于消息服务的简单概述请参考https://en.wikipedia.org/wiki/Message_queue,每种消息服务框架有共同之处也有各自的特点.

ZeroMQ和RabbitMQ均提供了消息服务, 可以满足某些使用场景下的消息处理,下面对这两种框架做一个宏观的对比.

• ZeroMQ是以C++语言实现的,可以编译成so库, 其提供了以C语言风格访问的API(见其头文件zmq.h),主流程序设计语言如C++,Java, python, PHP等都提供了语言绑定的接口.
• RabbitMQ是Erlang语言实现的,在部署RabbitMQ的时候,需要安装其匹配版本的Erlang环境.RabbitMQ提供了主流程序设计语言的客户端库来访问RabbitMQ服务器.
• ZeroMQ的设计思想较其他MQ架构有些不同的是,其并没有刻意设计一个broker角色的服务器, 当然也可以基于ZeroMQ构造broker角色,事实上,ZeroMQ被编译成一个嵌入式的库, 不需要事先去启动它,其运行依赖于宿主程序对其API接口的调用,ZeroMQ也没有任何配置文件.
• RabbitMQ以boker角色的服务器启动运行,用于连接消息的生产者和消息的消费者.需要对RabbitMQ进行配置以满足特定场景的使用需求.
• ZeroMQ架构中,消息没有持久化,ZeroMQ中也不包含任何高可用性的设计机制,如主备,集群等.如果需要这些特性,需要调用者程序在ZeroMQ之外实现.
• RabbitMQ框架中的消息默认是不持久化的,但是该选项是可以配置的,RabbitMQ有自己的数据库系统来存储持久化的消息.RabbitMQ包含了原生的内嵌集群,集群节点可以部署在同一物理机器上,也可以部署到同一数据中心的不同物理机器上,原生的RabbitMQ集群节点之间互相通信,对实时性要求比较高,需要部署到同一数据中心. 通过使用RabbitMQ插件可以跨数据中心部署完全独立的集群节点.RabbitMQ可以结合负载均衡组件,如HAProxy等,对集群节点进行故障切换和高效率访问.
• ZeroMQ的API是对网络插口socket的封装,根据并提供了若干角色,如REQ, REP, PUB, SUB,PUSH, PULL等等,在特定的使用场景中, 可能需要调用者处理ZeroMQ的frame的细节(除了ZeroMQ的核心库外, ZeroMQ社区提供了C语言实现的CZMQ,简化了ZeroMQ的API调用, 并对frame处理进行了封装).另外, ZeroMQ对底层网络协的支持除了TCP外,还支持广播协议,这在特定的网络拓扑结构中可能是合适的选择.
• ZeroMQ不但可以提供和远程物理机器的访问, 还提供了ipc和inproc机制,进行进程间和进程内不同线程间的访问连接.
• RabbitMQ的API语义非常清晰,其API是遵循AMQP协议, RabbitMQ在AMQP的exchange, queue, binding, route key等概念基础上,构造不同的使用模式.

总结:
ZeroMQ框架的特殊之处,在于它是一个嵌入式的库, 某些特性可能需要调用者在ZeroMQ之外进行实现,比如实现消息持久化, 在这样的需求场景中, ZeroMQ可能并不是很好的选择.但是嵌入式库的优势是可以实现ipc甚至inproc机制,其可以包含在一个以stand-alone形式运行的复杂应用程序中, 处理其不同进程或者线程间的消息.也这因为ZeroMQ是个嵌入式库, 所以其另一个优势是其移植性, ZeroMQ甚至可以在Android移动平台中以JNI的方式使用.