ActiveMQ；RabbitMQ；ZeroMQ

中间件类型：

• Embedded middleware: As the name suggests, this typeof middleware handles embedded applications (software or firmware)。
• RPC middleware: RPC (Remote Procedure Call)middleware communicates with applications using calls。
• Object request broker: Here, applications can sendand receive objects, like CORBA。
• SQL-oriented data access middleware: Primarily meantfor database-related applications, this class of middleware sits betweenapplications that communicate with databases, like JDBC,ODBC。
• Message-oriented middleware（MOM）: Message-oriented middleware mediate thecommunication or messages, between applications。

常见的三款开源消息中间件：

ActiveMQ

ActiveMQ是Apache开发的开源消息中间件，Java实现，基于JMS1.1及J2EE 1.4规范。

RabbitMQ

RabbitMQ 是由 LShift 提供的一个 Advanced MessageQueuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成，因此也是继承了这些优点。

ZeroMQ

ZeroMQ是由iMatix公司使用C语言开发的高性能消息中间件，是对socket的封装，在发送端缓存消息。

ActiveMQ架构

• Queue Region是P2P消息模型，Topic Region是Publish/Subscribe模型。
• Connectors负责消息通信，支持OpenWire, Stomp,REST,WS Notification, XMPP等协议。
• Network Services负责存储转发，集群等服务。
• Message Store负责消息的存储，支持内存、文件、内嵌数据库和外部数据库等四种消息持久化方式。

ActiveMQ特点

支持多语言：Java, C, C++,C#, Ruby, Perl, Python, PHP

消息模型：

Point to Point
Publish/Subscribe

协议支持情况：

支持OpenWire,Stomp,REST,WS Notification,XMPP。
对于python仅支持Stomp 协议。
不支持AMQP协议。
支持STOMP 1.0，不支持STOMP 1.1。 

支持Spring，可以很容易集成到Spring，并用Spring脚本配置。

支持Clustering built-in with autodiscovery，可以互相自动发

有Apache的支持，持续发展的优势明显。

支持Python的clients，都是很微小的开源项目，编程较复杂，不灵活：

Pyactivemq——基本已经不在维护，活跃度为低。
stomppy——推荐使用，rhel还有相应的rpm包，活跃度为中。 

需要消息服务器存储转发消息。

消息延时是10ms级别。

RabbitMQ架构

• RabbitMQ包括虚拟主机（virtualhost），交换机（exchange），队列（queue）和绑定（binding）四个概念。
• virtualhost：持有一组exchange、queue及bingding，可以做权限控制。
• Queue：存放消息，由consumer建立，并绑定到Exchange。
• Exchange：根据绑定的规则进行消息转发。
• Binding：绑定规则。

RabbitMQ特点

1. AMQP协议的开源实现，使用Erlang编写，维护时有语言障碍。
2. 通过plugin完全支持STOMP 协议。
3. 有Vmware的支持，RabbitMQ在云计算领域应该会有更多的特殊支持，架构会更适合云应用。
4. 有SpringSource的商业支持，包括技术支持，培训。
5. 支持持久化，不过只能使用它自己的数据库，不能使用mysql等。
6. Python客户端是pika，编程灵活简单；java的客户端编程灵活简单
7. 需要消息服务器存储转发消息。
8. 消息延时是10ms级别。

ActiveMQ与RabbitMQ性能测试对比

持久化性能对比

非持久化性能对比

ZerorMQ特点

• 是对socket的封装与扩展，API和socket编程的方式基本一致，支持请求-响应、Publish/Subscribe等消息模式。
• 仅支持异步I/O，为了提高性能通过新建的线程发送消息。
• 不需要单独的消息服务器来存储转发消息，重点放在消息的传输上，性能高于TCP。
• 支持C, C++, Java,Python等20多种语言。Java的开发包是jzmq，python的开发包是pyzmq。
• 消息延时是微秒级别。
• 由imatix开发，并可以提供支持与培训。 imatix 是AMQP协议最初的creator，并开发了开源的OpenAMQ ，但是在2010年imatix 宣布iMatix to drop OpenAMQ support by 2011， AMQP it now believes it is “fundamentally flawed and unfixable”。目前主要将精力集中到ZeroMQ。

zeroMQ——摘自zguide

• Itturns out that building reusable messaging systems is really difficult, whichis why few FOSS projects ever tried, and why commercial messaging products arecomplex, expensive, inflexible, and brittle. In 2006 iMatix designed AMQP whichstarted to give FOSS developers perhaps the first reusable recipe for amessaging system. AMQP works better than many other designs butremains relatively complex, expensive, and brittle.It takes weeks to learn to use, and months to create stable architectures thatdon‘t crash when things get hairy.
• Mostmessaging projects, like AMQP, that try to solve this long list of problems ina reusable way do so by inventing a new concept, the "broker", thatdoes addressing, routing, and queuing. This results in a client-server protocolor a set of APIs on top of some undocumented protocol, that let applicationsspeak to this broker. Brokers are an excellent thing in reducing the complexityof large networks. But addingbroker-based messaging to a product like Zookeeper would make it worse, notbetter. It would mean adding an additional big box, and a new single point offailure. A broker rapidly becomes a bottleneck and a new risk to manage. Ifthe software supports it, we can add a second, third, fourth broker and makesome fail-over scheme. People do this. It creates more moving pieces, more complexity,more things to break.
• Anda broker-centric set-up needs its own operations team. You literally need towatch the brokers day and night, and beat them with a stick when they startmisbehaving. You need boxes, and you need backup boxes, and you need people tomanage those boxes. It is only worth doing for large applications with manymoving pieces, built by several teams of people, over several years.
• Sosmall to medium application developers are trapped. Either they avoid networkprogramming, and make monolithic applications that do not scale. Or they jumpinto network programming and make brittle, complex applications that are hardto maintain. Or they bet on a messaging product, and end up with scalableapplications that depend on expensive, easily broken technology. There has beenno really good choice, which is maybe why messaging is largely stuck in thelast century and stirs strong emotions. Negative ones for users, gleeful joyfor those selling support and licenses.