Embedded middleware: As the name suggests, this typeof middleware handles embedded applications (software or firmware)。java
RPC middleware: RPC (Remote Procedure Call)middleware communicates with applications using calls。python
Object request broker: Here, applications can sendand receive objects, like CORBA。mysql
SQL-oriented data access middleware: Primarily meantfor database-related applications, this class of middleware sits betweenapplications that communicate with databases, like JDBC,ODBC。sql
Message-oriented middleware(MOM): Message-oriented middleware mediate thecommunication or messages, between applications。數據庫
ActiveMQ是Apache開發的開源消息中間件,Java實現,基於JMS1.1及J2EE 1.4規範。
RabbitMQ 是由 LShift 提供的一個 Advanced MessageQueuing Protocol (AMQP) 的開源實現,由以高性能、健壯以及可伸縮性出名的 Erlang 寫成,所以也是繼承了這些優勢。
ZeroMQ是由iMatix公司使用C語言開發的高性能消息中間件,是對socket的封裝,在發送端緩存消息。
ActiveMQ架構編程
Queue Region是P2P消息模型,Topic Region是Publish/Subscribe模型。api
Connectors負責消息通訊,支持OpenWire, Stomp,REST,WS Notification, XMPP等協議。緩存
Network Services負責存儲轉發,集羣等服務。bash
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特色
AMQP協議的開源實現,使用Erlang編寫,維護時有語言障礙。
經過plugin徹底支持STOMP 協議。
有Vmware的支持,RabbitMQ在雲計算領域應該會有更多的特殊支持,架構會更適合雲應用。
有SpringSource的商業支持,包括技術支持,培訓。
支持持久化,不過只能使用它本身的數據庫,不能使用mysql等。
Python客戶端是pika,編程靈活簡單;java的客戶端編程靈活簡單
須要消息服務器存儲轉發消息。
消息延時是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.
ActiveMQ | RabbitMQ | ZeroMQ | |
遵循規範 | JMS1.1及J2EE 1.4 | AMPQ | --- |
架構模型 | 消息代理架構Broker | 消息代理架構Broker | C/S架構 |
實現語言 | Java | Erlang | C/C++ |
支持消息協議 | Stomp | AMPQ、Stomp等 | --- |
主要推進力量 | Apache、Redhat | Lshift、Vmware、SpringSource | iMatix |
支持編程語言 | C,Java,Python | C,Java,Python | C,Java,Python |
編程複雜度 | 複雜 | 簡單 | 中等 |
持久化 | 支持 | 支持,不支持第三方數據庫 | 發送端緩存 |
性能 | Normal | Normal | High |
內存使用率 | High | High | Normal |