一、???? 分布式系統(tǒng)消息通信技術(shù)簡介

分布式系統(tǒng)消息通信技術(shù)主要包括以下幾種：

1.RPC(Remote Procedure Call Protocol).

一般是C/S方式，同步的，跨語言跨平臺，面向過程

2.CORBA(Common Object Request Broker Architecture).

CORBA從概念上擴展了RPC。面向?qū)ο蟮?#xff0c;企業(yè)級的(面向?qū)ο笾虚g件還有DCOM)

3.RMI(Remote Method Invocation).

面向?qū)ο蠓绞降?Java RPC

4.WebService.

基于Web，C/S或B/S，跨系統(tǒng)跨平臺跨網(wǎng)絡(luò)。多為同步調(diào)用, 實時性要求較高

5.MOM(Message oriented Middleware).

面向消息中間件，主要適用于消息通道、消息總線、消息路由和發(fā)布/訂閱的場景。目前主流標準有JMS(Java Message Service)、AMQP(Advanced Message Queuing Protocol)和STOMP(Streaming Text Oriented Messaging Protocol)。

JMS是Java平臺上的面向接口的消息規(guī)范，是一套API標準，并沒有考慮異構(gòu)系統(tǒng)。AMQP是一個面向協(xié)議的，跟語言平臺無關(guān)的消息傳遞應(yīng)用層協(xié)議規(guī)范。STOMP是流文本定向消息協(xié)議，是一種為MOM設(shè)計的簡單文本協(xié)議。AMQP和STOMP都是跟http處于同一層的協(xié)議。

在 AMQP 模型中，消息的 producer 將 Message 發(fā)送給 Exchange，Exchange 負責(zé)交換 / 路由，將消息正確地轉(zhuǎn)發(fā)給相應(yīng)的 Queue。消息的 Consumer 從 Queue 中讀取消息。

AMQP 系統(tǒng)構(gòu)架

二、???? 常見開源跨平臺MQ簡介

目前業(yè)界上關(guān)于消息中間件的實現(xiàn)多達好幾十種，可謂百花齊放，所用的實現(xiàn)語言同樣也五花八門。下面挑選了一部分，在網(wǎng)上開源社區(qū)相對容易搜索出來的十多種MQ來作簡單介紹。

開源MQ

概述

1.Qpid

Apach的一個開源AMQP實現(xiàn)，broker架構(gòu)，有C++和Java兩個版本

2.RabbitMQ

LShift 用Erlang實現(xiàn)，支持多協(xié)議，broker架構(gòu)，重量級

3.ZeroMQ

AMQP最初設(shè)計者iMatix公司實現(xiàn)，輕量消息內(nèi)核，無broker設(shè)計。C++實現(xiàn)

4.Jafka/Kafka

LinkedIn用Scala語言實現(xiàn)，支持hadoop數(shù)據(jù)并行加載

5.ActiveMQ

Apach的一種JMS具體實現(xiàn)，支持代理和p2p部署。支持多協(xié)議。Java實現(xiàn)

6.Apollo

ActiveMQ的下一代產(chǎn)品，支持多協(xié)議，Scala實現(xiàn)

7.Redis

Key-value? NoSQL數(shù)據(jù)庫，有MQ的功能

8.MemcacheQ

國人利用memcache緩沖隊列協(xié)議開發(fā)的消息隊列,C/C++實現(xiàn)

9.Open-MQ

C++和QT實現(xiàn)，支持JMS

10.ActiveMQ-CPP

ActiveMQ的C++純客戶端庫，用于跟ActiveMQ通信

11.MQ4CPP

一個C++實現(xiàn)的MQ，信息甚少

12.MetaQ

Alibaba對Kafka的改造，增加事務(wù)支持等新特性，用純Java實現(xiàn)

13.Beanstalkd

一個類memcached協(xié)議設(shè)計的消息隊列,C/C++實現(xiàn)

14.OpenAMQ

iMatix公司AMQP1.0的實現(xiàn)，類似rabbitMQ。C++實現(xiàn)。2010年項目放棄

15.Spread Toolkit

高性能的分布式分組消息系統(tǒng)，C++實現(xiàn)

16.SAFMQ

C++實現(xiàn)的儲存轉(zhuǎn)發(fā)消息隊列中間件

17. Mosquitto

一個輕量級的IBM物聯(lián)網(wǎng)連接協(xié)議的消息中間件實現(xiàn)，C/C++實現(xiàn)

18.MUSCLE

提供一個多路消息服務(wù)器和消息對象傳遞功能，支持C/C++

19.JORAM

一個類似OpenJMS(Sun OpenMQ)的JMS消息中間件，JAVA實現(xiàn)

Qpid

Qpid 是 Apache 開發(fā)的一款面向?qū)ο蟮南⒅虚g件，它是一個 AMQP 的實現(xiàn)，可以和其他符合 AMQP 協(xié)議的系統(tǒng)進行通信。Qpid 提供了 C++/Python/Java/C# 等主流編程語言的客戶端庫，Qpid 提供了很多額外的 HA 特性，非常適于集群環(huán)境下的消息通信。

它提供了 C++ 和 Java 兩個版本的 broker服務(wù)端，并支持多種語言的客戶端。C++版本的服務(wù)器端具備高性能/低消耗以及RDMA支持；而Java版本的服務(wù)器則支持JMS。Qpid 還提供了一些額外的特性：

采用 Corosync 來保證了集群環(huán)境下的 Fault-tolerant 特性

支持 XML 類型的 Exchange，當(dāng)消息格式為 XML 時，可以利用 Xquery 進行過濾

支持 plugin，用戶可以方便地增加新的功能，比如新的 exchange 類型

提供了安全認證特性，任何 producer/consumer 需要和 broker 通信時，都需要提供身份認證。QPID 的安全認證使用 SSL 協(xié)議。

授權(quán)協(xié)議： Apache

開發(fā)語言： Java C/C++

操作系統(tǒng)： 跨平臺

官網(wǎng)：http://qpid.apache.org??最新版本0.30發(fā)布于2014-09-26。

有新浪的朋友比較推薦Qpid，它比rabbitmq要輕型，比zeromq保險點！各方面的文檔都比較健全。目前在openstack中作為一種可選的消息中間件服務(wù)配置。MB(WSO2 Message Broker) 基于Apache Qpid，這是一個Java項目。開源的企業(yè)服務(wù)總線(ESB) – Celtix，基于Apache Incubator項目Qpid。

跟Qpid有關(guān)聯(lián)的其他項目主要有:

RabbitMQ

LShift 用Erlang編寫的一個開源的消息隊列，支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，重量級，更適合于企業(yè)級的開發(fā)。代理(Broker)架構(gòu)，對路由(Routing)，負載均衡(Load balance)或者數(shù)據(jù)持久化都有很好的支持。

缺點：可擴展性差，速度較慢，因為中央節(jié)點增加了延遲，消息封裝后也比較大。

AMQP 里主要要說兩個組件：Exchange 和 Queue (在 AMQP 1.0 里還會有變動)，如下圖所示，綠色的 X 就是 Exchange ，紅色的是 Queue ，這兩者都在 Server 端，又稱作 Broker ，這部分是 RabbitMQ 實現(xiàn)的，而藍色的則是客戶端，通常有 Producer 和 Consumer 兩種類型：

授權(quán)協(xié)議： MPL

開發(fā)語言： ErLang

操作系統(tǒng)： 跨平臺

官網(wǎng)：http://www.rabbitmq.com/，最新版本3.4.3發(fā)布于2015-1-7

?MQ(ZeroMQ)

早期需要設(shè)計可靠消息系統(tǒng)比如AMQP，但是這種方式引入了single-point broker。對于需要這種可靠消息系統(tǒng)的應(yīng)用來說，需要在broker上面做相當(dāng)多的事情確?？煽啃砸约靶阅堋５沁@樣對于中小應(yīng)用陷入了尷尬，為了使用這種方便的消息系統(tǒng)他們需要引入broker這么東西是不能夠忍受的。我們需要的一種簡單方便的消息傳輸系統(tǒng)，沒有任何附加代價(比如所有數(shù)據(jù)都流經(jīng) broker)，這就是ZeroMQ設(shè)計初衷。

2010年3月30日，AMQP的最初設(shè)計者iMatix公司的首席執(zhí)行官Pieter Hintjens宣布iMatix將退出AMQP工作組，而且為了簡單得多，快的多的ZeroMQ，將不支持可能發(fā)布的AMQP/1.0。一個非常輕量級的消息內(nèi)核，專門為高吞吐量/低延遲的場景開發(fā)。ZeroMQ支持許多高級消息場景，但是你必須實現(xiàn)ZeroMQ框架中的各個塊(比如Socket或Device等)。沒有中間件架構(gòu)，應(yīng)用程序端點扮演了這個服務(wù)角色。部署簡單，僅提供非持久性的隊列。與RabbitMQ相比，?MQ并不像是一個傳統(tǒng)意義上的消息隊列服務(wù)器，事實上，它也根本不是一個服務(wù)器，它更像是一個底層的網(wǎng)絡(luò)通訊庫，在socket API之上做了一層封裝，將網(wǎng)絡(luò)通訊、進程通訊和線程通訊抽象為統(tǒng)一的API接口。

支持C、C++、Python、.NET /Mono、Fortran和Java語言

授權(quán)協(xié)議： LGPL

開發(fā)語言： C/C++

操作系統(tǒng)： 跨平臺

官網(wǎng)：http://zeromq.org/,?? 最新版本4.1.0發(fā)布于2014/10/14。Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸，還有常見于金融界的應(yīng)用中。Mongrel2是使用ZeroMQ的一個Web服務(wù)器。

Jafka/Kafka

LinkedIn用Scala語言開發(fā)。高吞吐量高性能支持跨語言分布式Publish/Subscribe消息隊列系統(tǒng)，而Jafka是在Kafka之上孵化而來的。快速持久化、高吞吐、完全的分布式系統(tǒng)、支持Hadoop數(shù)據(jù)并行加載。

授權(quán)協(xié)議： Apache

開發(fā)語言： Scala

操作系統(tǒng)： 跨平臺

ActiveMQ

居于兩者(RabbitMQ & ZeroMQ)之間，類似于ZeroMQ，它可以部署于代理模式和P2P模式。完全支持JMS1.1和J2EE 1.4規(guī)范?？缙脚_的，多種語言和協(xié)議編寫客戶端,Java, C, C++, C#, Ruby, Perl, Python, PHP。應(yīng)用協(xié)議: OpenWire, Stomp REST, WS Notification, XMPP, AMQP。如需配置ActiveMQ則需要在目標機器上安裝Java環(huán)境。支持集群，同等網(wǎng)絡(luò)，自動檢測，TCP，SSL，廣播，持久化，XA，多個消息也可以組成原子事務(wù)

缺點：默認的配置性能偏低，需要優(yōu)化配置，但是配置文件復(fù)雜，本身不提供管理工具；示例代碼非常少；主頁上的文檔看上去比較全面，但是缺乏一種有效的組織方式，文檔只有片段，用戶很難由淺入深進行了解，二來文檔整體的專業(yè)性太強。

授權(quán)協(xié)議： Apache

開發(fā)語言： Java

操作系統(tǒng)： 跨平臺

Apollo

ActiveMQ的下一代產(chǎn)品為Apollo，Apollo以ActiveMQ原型為基礎(chǔ)，是一個更快、更可靠、更易于維護的消息代理工具。Apache稱Apollo為最快、最強健的STOMP(Streaming Text Orientated Message Protocol，流文本定向消息協(xié)議)服務(wù)器。

l? Apollo的特性如下：

l? 支持Stomp 1.0和Stomp 1.1協(xié)議

l? 主題和隊列

l? 隊列瀏覽器

l? 主題持久訂閱

l? 鏡像隊列

l? 可靠的消息傳遞

l? 消息過期和交換

l? 消息選擇器

l? JAAS驗證

l? 基于ACL的授權(quán)

l? 支持SSL/TLS，證書驗證

l? REST Management API

Redis

一個Key-Value的NoSQL數(shù)據(jù)庫，開發(fā)維護很活躍，雖然它是一個Key-Value數(shù)據(jù)庫存儲系統(tǒng)，但它本身支持MQ功能，所以完全可以當(dāng)做一個輕量級的隊列服務(wù)來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時間。測試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個不同大小的數(shù)據(jù)。實驗表明：入隊時，當(dāng)數(shù)據(jù)比較小時Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過了10K，Redis則慢的無法忍受；出隊時，無論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。(盛大開源的DOMQ用的是redis)

MemcacheQ

國人開發(fā)的持久化消息隊列memcacheq(簡稱mcq)是一個輕量級的消息隊列，MemcacheQ的特性：

l? 簡單易用

l? 處理速度快

l? 多條隊列

l? 并發(fā)性能好

l? 與memcache的協(xié)議兼容。這就意味著只要裝了memcache的extension就可以了，不需要額外的插件。

l? 在zend framework中使用也很方便。

Open-MQ

一個開源的消息中間件，類似IBM的 WebSphere MQ(MQSeries)，采用 C++ 和 Qt 庫編寫的，支持Windows、Unix 以及 Mac OS 平臺，支持 JMS。

授權(quán)協(xié)議： 未知

開發(fā)語言： C/C++

操作系統(tǒng)： 跨平臺

官網(wǎng)：?http://www.open-mq.com/?(打不開)? 目前Open Message Queue 已經(jīng)集成到了 GlassFish 和OpenESB中。

ActiveMQ-CPP

CMS (全稱是 C++ Messaging Service) 是一個 C++ 實現(xiàn)的類似 JMS 的 API，用于實現(xiàn)例如 ActiveMQ 的消息代理服務(wù)。CMS 可以幫助你的 C++ 客戶端代碼更見簡單。ActiveMQ-CPP 是一個純客戶端庫，用它來跟例如 ActiveMQ 等消息服務(wù)通訊。我們的 CMS 實現(xiàn)名為 ActiveMQ-CPP，使用可插入式的傳輸和協(xié)議，當(dāng)前支持 OpenWire 和 Stomp協(xié)議，基于 TCP 和 SSL 。同時支持故障轉(zhuǎn)移傳輸。

授權(quán)協(xié)議： Apache

開發(fā)語言： C/C++

操作系統(tǒng)： 跨平臺

MQ4CPP(Message Queuing for C++)

MQ4CPP is a Message Oriented Middleware (MOM) and implements the following messaging paradigms:

– Direct/Indirect messaging (local)

– Unsolicited messaging (remote)

– Request/Reply (remote)

– Conversation (remote)

– Broadcast (local/remote)

– Publish/Subscribe

– Store & Forward

– Memory Channel

– File Transfer

– Distributed Lock Manager

Support of:

– Multithreading (pthread, WinThread)

– Sockets (berkley , Win Sock2)

– Cluster (failover, session replication)

– Encription (Rijndael 128/256)

– Compression

– Service lookup (local/remote)

– Message routing

Tested platforms:

– Linux (x86, IA64) POSIX

– Windows (x86, IA64) SDK

授權(quán)協(xié)議：LGPL

開發(fā)語言：C++

操作系統(tǒng)：跨平臺

官網(wǎng)：http://www.sixtyfourbit.org? 域名已失效，資料甚少。僅有個overview PDF文檔鏈接：

Metamorphosis (MetaQ)

一個高性能、高可用、可擴展的分布式消息中間件，Linkedin開源MQ——Kafka的Java版本，阿里巴巴對此做了定制和優(yōu)化，具有消息存儲順序?qū)?、吞吐量大和支持本地和XA事務(wù)等特性，適用于大吞吐量、順序消息、廣播和日志數(shù)據(jù)傳輸?shù)葓鼍?/p>

開發(fā)語言： Java

操作系統(tǒng)： 跨平臺

Beanstalkd

一個簡單、快速的消息隊列。Beanstalk之于RabbitMQ，就好比Nginx之于Apache，Varnish之于Squid。簡單、輕量級、高性能、易使用等特點，以及優(yōu)先級、多隊列、持久化、分布式容錯、超時控制等特性。Beanstalkd 包含多種編程語言的客戶端開發(fā)包。Beanstalkd是典型的類Memcached設(shè)計。

不足就是尚無提供刪除一個tube的操作，只能將tube的job依次刪除，并讓Beanstalkd來自動刪除空tube。還有就是Beanstalkd不支持客戶端認證機制(開發(fā)者將應(yīng)用場景定位在局域網(wǎng))。沒有提供主從同步+故障切換機制，在應(yīng)用中有可能成為單點的風(fēng)險。在實際應(yīng)用中，可以使用數(shù)據(jù)庫為job提供持久化存儲。和Memcached類似，Beanstalkd依賴libevent單線程事件分發(fā)機制，不能有效的利用多核cpu的性能。這一點可以通過單機部署多個實例克服。

授權(quán)協(xié)議： MIT

開發(fā)語言： C/C++

操作系統(tǒng)： 跨平臺

鏈接：https://github.com/kr/beanstalkd??目前支持過有9.5 million用戶的Facebook Causes應(yīng)用。PostRank大規(guī)模部署和使用，每天處理百萬級任務(wù)

OpenAMQ

一個分布式的消息通訊框架。消息異步傳遞的。主要為高性能和可靠性而設(shè)計。該項目服務(wù)器端采用 GPL 授權(quán)協(xié)議，客戶端(Python、Java、Ruby、C)是 BSD 授權(quán)協(xié)議。iMatrix公司早期也是計劃按照AMQP/1.0標準開發(fā)一個類似RabbitMQ的項目，名字叫做OpenAMQ。然而，隨著項目的推進，iMatrix公司在這個項目上迷失了方向。iMatrix的CEO Pieter Hintjens在一篇文章中描述了自己對AMQP標準化進程的困惑和思考，并認為AMQP中存在一些無法克服的問題。2010年3月，iMatrix公司宣布退出AMQP/1.0標準化，放棄OpenAMQ項目，并正式啟動了?MQ，即ZeroMQ

授權(quán)協(xié)議： GPLv2/BSD

開發(fā)語言： C/C++

操作系統(tǒng)： 跨平臺

官網(wǎng)：http://www.openamq.org/? 目前最新版1.4發(fā)布于2010/10/7

The Spread Toolkit

高性能的分布式分組消息系統(tǒng)，支持局域網(wǎng)以及廣域網(wǎng)通訊. Spread可以作為一個分布式應(yīng)用的消息總線，并且具有高度的靈活性，可以做到多播，分組，以及點對點餓消息傳遞。

The Spread toolkit 包括一個消息服務(wù)器 server，以及多種語言的api C/C++ libraries (with and without thread support), a Java Perl, Python, and Ruby. 還有很多其他語言的第三方擴展。

在一個典型的環(huán)境中，通常每臺服務(wù)器上運行一個Spread server，客戶端的程序本地連接server，發(fā)送信息，而這臺服務(wù)器上的spread server會傳遞信息給其他訂閱了這條消息的應(yīng)用。當(dāng)然也可以只有一個spread server，而其他的客戶端分布在整個網(wǎng)絡(luò)中。

Some of the services and benefits provided by Spread:

l? Reliable and scalable messaging and group communication.

l? A very powerful but simple API simplifies the construction of distributed architectures.

l? Easy to use, deploy and maintain.

l? Highly scalable from one local area network to complex wide area networks.

l? Supports thousands of groups with different sets of members.

l? Enables message reliability in the presence of machine failures, process crashes and recoveries, and network partitions and merges.

l? Provides a range of reliability, ordering and stability guarantees for messages.

l? Emphasis on robustness and high performance.

l? Completely distributed algorithms with no central point of failure.

授權(quán)協(xié)議： Spread Open-Source License(類似BSD)&&商業(yè)協(xié)議

開發(fā)語言： C/C++

操作系統(tǒng)： 跨平臺

SAFMQ (Store and Forward Message Queue)

消息隊列服務(wù)器提供了異步的、round-trip、可靠的消息傳輸。

一個簡單的消息中間件，采用C++編寫，截至2006年11月SAFMQ的的版本為0.5.2，具有如下的功能： 1. 提供多隊列、多優(yōu)先級的消息轉(zhuǎn)發(fā)服務(wù)。 2. 支持文本、二進制的消息類型。 3. 支持轉(zhuǎn)發(fā)功能，即多個消息中間件之間的消息轉(zhuǎn)發(fā)。 4. 支持事務(wù)操作 5. 支持Java、PHP客戶端 6. 支持SSL加密 7. 支持用戶權(quán)限 8. 支持對消息的標記 9. 支持TTL(Time To Live)時間戳。目前最新版本0.8.3.1，2010年

授權(quán)協(xié)議： Apache

開發(fā)語言： Java C/C++ PHP

操作系統(tǒng)： 跨平臺

Mosquitto

一個開源(BSD許可證)的消息代理，實現(xiàn)MQTT(消息隊列遙測傳輸)協(xié)議版本3.1。提供了Windows、Linux以及qnx系統(tǒng)的版本。MQTT是輕量級基于代理的發(fā)布/訂閱的消息傳輸協(xié)議。?MQTT是IBM開發(fā)的一個即時通訊協(xié)議。MQTT是面向M2M和物聯(lián)網(wǎng)的連接協(xié)議，采用輕量級發(fā)布和訂閱消息傳輸機制

有三種消息發(fā)布服務(wù)質(zhì)量：

“至多一次”，消息發(fā)布完全依賴底層 TCP/IP 網(wǎng)絡(luò)。會發(fā)生消息丟失或重復(fù)。這一級別可用于如下情況，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂，因為不久后還會有第二次發(fā)送。

“至少一次”，確保消息到達，但消息重復(fù)可能會發(fā)生。

“只有一次”，確保消息到達一次。這一級別可用于如下情況，在計費系統(tǒng)中，消息重復(fù)或丟失會導(dǎo)致不正確的結(jié)果。

授權(quán)協(xié)議： BSD

開發(fā)語言： C/C++

操作系統(tǒng)： 跨平臺

官網(wǎng)：?http://mosquitto.org/?最新版本1.3.5發(fā)布于2014/10/8

MUSCLE (Multi User Server Client Linking Environment)

提供一個多路的消息服務(wù)器以及相應(yīng)的網(wǎng)絡(luò)API，其客戶端涉及多種語言包括 C, C++, C#, Delphi, Java, 和 Python。MUSCLE 用來在網(wǎng)絡(luò)上傳輸消息對象，所有消息存儲在服務(wù)端并為客戶端進行傳遞。

授權(quán)協(xié)議： BSD

開發(fā)語言： Java C/C++ Python C#

操作系統(tǒng)： 跨平臺

官網(wǎng)：https://public.msli.com/lcs/muscle/?目前新版6.10發(fā)布于2014/12/12。MUSCLE has been developed, used, and refined as the networking component of?BeShare,?CueStation?and various other audio control applications atMeyer Sound Laboratories?for over twelve years

JORAM

JORAM一個類似于openJMS分布在ObjectWeb之下的JMS消息中間件。文檔非常完備，并且?guī)в泻芏嗍纠?/p>

缺點：

判斷JMS客戶端是否在線非常緩慢，有時甚至不會通知應(yīng)用

授權(quán)協(xié)議： 未知

開發(fā)語言： Java

操作系統(tǒng)： 跨平臺

三、???? MQ比較

一些國外網(wǎng)站提供的，ActiveMQ、RabbitMQ、RocketMQ(MeteMQ)、HornetQ、Qpid、ZeroMQ的對比數(shù)據(jù)。

協(xié)議支持比較：

ActiveMQ

Apollo

HornetQ

Qpid

RabbitMQ

ZeroMQ

AMQP

1.0

1.0

announced

1.0

0-8, 0-9, 0-9-1

-

MQTT

-

-

-

OpenWire

-

-

-

-

REST

-

-

STOMP

-

-

STOMP over Websockets

-

-

XMPP

-

-

-

Over Gateway

-

客戶端接口支持比較：

ActiveMQ

Apollo

HornetQ

Qpid

RabbitMQ

ZeroQ

C

-

-

C++

-

-

-

Erlang

-

-

-

-

Haskell

-

-

-

-

Java JMS

-

-

-

Java proprietary

-

-

.NET

-

-

-

Objective-C

-

-

-

-

-

Perl

-

-

-

-

PHP

-

-

-

-

Python

-

-

-

Ruby

-

-

-

性能測試場景對比：

l? 情景A：先入隊20,000 條1024 字節(jié)大小的消息, 然后再出隊

l? 情景B：20,000條1024字節(jié)大小的消息同時入隊和出隊

l? 情景C：200,000 條32 字節(jié)大小的消息同時入隊和出隊

l? 情景D：200 條32K字節(jié)大小的消息同時入隊和出隊

兩種不同配置的broker，一種開啟持久化消息(Persistent)，一種是沒有開啟持久化，即瞬時化消息(Transient)

下面是測試的所有brokers和對應(yīng)的配置:

情景A：

情景 B：

情景 C：

情景 D：

結(jié)論：

1)??????? Brokers普遍擅長于處理大消息。因此如果客戶端支持對消息分組，那性能會得到更大的提升。但分組消息卻不能在consumer之間傳播。

2)??????? 處理大消息，持久化的弊端(磁盤或數(shù)據(jù)庫保存)就開始凸顯 (QPID 處理瞬時化消息不論消息大小，都顯得非常高效)?？梢缘贸?#xff0c;處理中小消息的耗時主要在集中CPU，而不是I/O網(wǎng)絡(luò)上。

3)??????? ZeroMQ broker比其他所有MQ broders表現(xiàn)得更優(yōu)越。倘若需求上要用到一些特殊的broker特性，不然ZeroMQ 絕對是分發(fā)消息系統(tǒng)的一個最好選擇。

4)??????? QPID 似乎是在處理瞬時消息上綜合表現(xiàn)得最好。

5)??????? 從RabbitMQ的測試結(jié)果看，AMQP 協(xié)議似乎比STOMP協(xié)議更優(yōu)越. 當(dāng)然這結(jié)果也可能跟不良設(shè)計的客戶端受到影響。

6)??????? HornetQ 在處理中、小消息時，表現(xiàn)得最差的。

7)??????? 除了處理大消息之外，RabbitMQ 似乎是最好的選擇，因它的性能是其他的3倍左右。

下圖是顯示的是發(fā)送和接受的每秒鐘的消息數(shù)。整個過程共產(chǎn)生1百萬條1K的消息。測試的執(zhí)行是在一個Windows Vista上進行的。

選擇消息系統(tǒng)根據(jù)業(yè)務(wù)需要需要考慮以下幾個方面：

l? 是否持久化

l? 吞吐能力

l? 高可用，避免單點故障

l? 分布式擴展能力

l? 兼容現(xiàn)有協(xié)議

l? 易于維護

l? 其他，如消息丟失和重復(fù)的處理

l? 負載均衡

常見消息系統(tǒng)協(xié)議：

l? STOMP

l? AMQP

l? 類似 MEMCACHE 的協(xié)議

l? HTTP

l? MQTT

非C/C++實現(xiàn)服務(wù)端的，資料文檔缺乏的，版本最后更新時間久遠的，活躍度低的，重量級的，這些MQ排除不考慮。下面是篩選出來的若干個MQ作對比

Qpid

ZeroMQ

Beanstalkd

Spread

Open-MQ

memcachedQ

SAFMQ

Mosquitto

MUSCLE

JMS

━

━

━

━

√

━

━

━

━

AMQP

√

━

━

━

━

━

━

━

━

MQTT

━

━

━

━

━

━

━

√

━

OpenWire

━

━

━

━

━

━

━

━

━

Stomp

━

━

━

━

√

━

━

━

━

Memcache協(xié)議

━

━

√

━

━

√

━

━

━

HA集群(防單點故障)

√

√

━

√

━

━

━

━

━

認證

√

━

━

√

━

━

√

━

━

Broker架構(gòu)

√

━

√

√

√

√

√

√

√

持久化

√

━

√

√

━

━

√

━

━

支持廣域網(wǎng)

━

━

━

√

━

━

━

━

━

高吞吐

√

√

√

√

√

√

√

━

━

事務(wù)

√

━

━

━

━

━

━

━

━

下面對非持久化消息進行了測試(ZeroMQ自實現(xiàn)一個簡單broker，直接內(nèi)存操作和轉(zhuǎn)發(fā))

測試硬件環(huán)境：

Broker:

Operation System:???????? Windows7 旗艦版? sp1? x64

CPU:??????????????????? Intel? Core? i5-3470 CPU @ 3.20GHz

MEM：??????????????? 4.00GB

Disk:???????????????????? 500GB

Network Adapter:????????? Gibabit? Network connection

Client:

Operation System:???????? Windows7 旗艦版? sp1? x64

CPU:??????????????????? Intel? Core? 2 Duo CPU T6400 @ 2.00GHz

MEM：??????????????? 4.00GB

Disk:???????????????????? 250GB

Network Adapter:????????? Gibabit? Network connection

測試結(jié)果：

結(jié)論：

1)??????瞬時化消息的處理性能明顯大大優(yōu)于持久化消息的處理

2)????? 兩者都更擅長處理大消息體數(shù)據(jù)

3)????? 處理的消息體越小時，Qpid的性能下降得比較明顯

4)????? Qpid在處理持久化消息時，消息體越大，性能越高。這說明消息體比較大的情形，瓶頸在于網(wǎng)絡(luò)IO，消息體越小，瓶頸在于CPU和磁盤讀寫。

四、???? ZeroMQ簡介

ZeroMQ用于node與node間的通信，node可以是主機或者是進程。ZeroMQ 把通訊的需求看成四類。其中一類(Exclusive-Pair)是一對一對應(yīng)通訊，用來支持傳統(tǒng)的 TCP socket 模型，但并不推薦使用。常用的通訊模式只有三類。

請求回應(yīng)模型(Request-Reply)。

由請求端發(fā)起請求，并等待回應(yīng)端回應(yīng)請求(阻塞的)。請求端和回應(yīng)端都可以是1:N的模型。通常把1認為是server，N認為是Client。ZeroMQ 可以很好的支持路由功能(實現(xiàn)路由功能的組件叫作 Device)，把 1:N 擴展為 N:M。

發(fā)布訂閱模型(Publish-Subscribe)。

發(fā)布端是單向只發(fā)送數(shù)據(jù)的，且不關(guān)心是否把全部的信息都發(fā)送給訂閱端。如果發(fā)布端開始發(fā)布信息的時候，訂閱端尚未連接上來，這些信息直接丟棄。不過一旦訂閱端連接上來，中間會保證沒有信息丟失(之前的消息會丟掉，Slow joiner問題)。同樣，訂閱端則只負責(zé)接收，而不能反饋。Publisher 中途離開，所有的 Subscriber 會 hold 住，等待 Publisher 再上線的時候，會繼續(xù)接受信息。如果發(fā)布端和訂閱端需要交互(比如要確認訂閱者是否已經(jīng)連接上)，則使用額外的 socket 采用請求回應(yīng)模型滿足這個需求。

管道模型(Push-Pull)。

這個模型里，管道是單向的，從 PUSH 端單向的向 PULL 端單向的推送數(shù)據(jù)流。

任何分布式并行的需求，都可以用這三種模型組合起來解決問題。ZeroMQ 只專注和解決了消息通訊這一基本問題。

ZeroMQ 中的 Transient (短暫) 和 Durable (持久) socket 也并非區(qū)別于實現(xiàn)層是否保持了 tcp 連接。而是概念上的不同。對于 Durable socket ，其生命期可以長于一個進程的生命期，即使進程退出，再次啟動后依舊可以維持繼續(xù)之前的 socket。

l? zmq_init創(chuàng)建一個context，可以認為是一個MQ實例或句柄。1表示IO線程數(shù)。

l? zmq_socket根據(jù)context來創(chuàng)建一個socket,后面類型指定了MQ通信類型。

l? zmq_bind/zmq_connect可以進行綁定進行監(jiān)聽或者是進行連接。

l? zmq_msg_init/zmq_msg_init_size可以用來初始化一個message

l? zmq_send/zmq_recv可以進行message的發(fā)送和接收。

l? zmq_msg_close銷毀一個message

l? zmq_close關(guān)閉一個socket

l? zmq_term銷毀一個context

通信協(xié)議：

l? tcp // 跨主機間通信

l? ipc // 進程間通信

l? inproc // 線程間通信

l? pgm // ━━━

l? epgm // ━━━

消息：

ZeroMQ通信通信單元是消息，他除了知道 Bytes 的大小，他并不關(guān)心的消息格式。zmq_recv/zmq_send只能夠處理內(nèi)置的消息格式，而不能夠處理http請求這種字節(jié)流。ZMQ允許一條message按照多個部分進行發(fā)送(multipart message)。底層使用其他線程完成了IO讀寫。ZMQ內(nèi)置有一個字節(jié)流成幀策略。

Identity：可以用來表示一個socket的身份

Device：一旦通信節(jié)點超過一定數(shù)量的話，那么最好需要一個轉(zhuǎn)發(fā)節(jié)點或者是中間節(jié)點。

擁塞：

ZMQ可以通過控制HWM(high-water mark)來控制擁塞。內(nèi)部實現(xiàn)上每一個socket有關(guān)聯(lián)了buffer,HWM可以控制buffer大小

l? PUB/PUSH有transmit buffers.

l? SUB/PULL/REQ/REP有receive buffers.

l? DEALER/ROUTER/PAIR有transmit buffers也有receive buffers.

一旦socket達到了high-water mark的話，那么會根據(jù)socket類型來決定是丟棄還是block.現(xiàn)在實現(xiàn)而言的話PUB會嘗試丟棄數(shù)據(jù)，而其他類型的socket就會block住。 如果socket是線程之間進行通信的話，那么HWM是兩者socket的HWM之和。因為默認HWM是ulimited的，所以只要一端沒有設(shè)置的話那么容量就無限。

官網(wǎng)：http://zeromq.org/, 最新版本4.1.0發(fā)布于2014/10/14。Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸，還有常見于金融界的應(yīng)用中。

關(guān)于ZeroMQ的權(quán)威資料，除了官方文檔，還有O'Reilly出版社2013年出版的一本書，《ZeroMQ: Messaging for Many Applications》，作者: Pieter Hintjens

目前最新穩(wěn)定版本4.0.5源代碼中，C/C++代碼一共大概1.7萬行，包括主體代碼占1.3萬左右，API和Demo占4千行左右。詳細如下圖。

五、??? ?Qpid簡介

基本 Qpid 通信系統(tǒng)的幾個組件

Address地址

Qpid Address 表示一個節(jié)點，有兩種節(jié)點：一種是 queue，另外一種是 topic。queue映射到 AMQP 概念就是 Queue；而 topic則映射到 Exchange。Queue 節(jié)點能夠緩存消息，直到被讀取走為止；而 topic 節(jié)點則即時進行轉(zhuǎn)發(fā)，比如假如有 4 個 consumer 對某消息感興趣，當(dāng)消息到達節(jié)點時，有 3 個 consumer 正在運行，那么 topic 節(jié)點會將消息轉(zhuǎn)發(fā)給這 3 個 consumer，然后就將該消息丟棄。剩下的那個 consumer 再運行時，則收不到這個消息。

Address 是一個帶格式的字符串，其語法如下：

address_string ::=

[ / ] [ ; ]

options ::= { : , ... }

其中 address，subject 和 key 都是字符串。

Subject 類似 email 的主題。每個消息都可以有一個主題，接收者可以通過主題對消息進行過濾。

Option 的具體含義有點兒復(fù)雜，可以參考 Qpid 的編程手冊獲取完整的描述。

Broker Federation

單一 Broker 的構(gòu)架

Broker Federation 的配置

設(shè)置 federation 的命令叫 Qpid-route。Qpid 支持兩類路由：Queue routes 和 Exchange Routes。

Queue route：目的地必須是 Exchange，源是一個 Queue。此類路由將源地址 Queue 收到的所有消息都轉(zhuǎn)發(fā)到目的 Exchange 去。

Exchange Route：目的地依然必須是一個 Exchange，源也是一個 Exchange。此類路由允許將源 Exchange 上收到的，擁有指定 RouteKey 的消息轉(zhuǎn)發(fā)到目的 Exchange 上去。

RDMA

RDMA 全稱為“Remote Direct Memory Access”，它是一種協(xié)議，將數(shù)據(jù)從一臺計算機的內(nèi)存直接傳輸?shù)搅硗庖慌_計算機的內(nèi)存中，而無需 CPU 的參與。類似 CPU 與外設(shè)之間的 DMA 傳輸，RDMA 將 DMA 的概念擴展到了網(wǎng)絡(luò)。

C++ 版本的 Qpid broker 除了使用傳統(tǒng)的 TCP/IP 作為網(wǎng)絡(luò)通信機制之外，在擁有 infiniband 設(shè)備的集群上 Qpid 還可以使用 RDMA 進行網(wǎng)絡(luò)通信。

持久化消息

Broker 將收到的消息暫存在磁盤等可以永久保存信息的地方備用，這樣，即使 Broker 因為某種意外而中斷，當(dāng)其再次重新啟動之后，還是可以將保持在永久存儲介質(zhì)中的消息讀出來并繼續(xù)進行轉(zhuǎn)發(fā)。除了 Queue 需要 durable 之外，我們還必須保證發(fā)送的消息有 durable 屬性。

高可用性

在一個 Qpid broker 集群中，所有的 broker 都互相備份，進行 fail over 的必要準備工作。每個 broker 的內(nèi)部對象都同步到其他集群中的 Broker，保持一致，這樣在單一 Broker 無法工作的情況下，client 可以切換到其他 Broker，而避免信息的丟失和服務(wù)中斷。

Qpid 和 Corosync 的工作模式

Qpidd A 和 QpiddB 通過 Corsync 同步。Qpid 還通過 CMAN 來防止集群中的”split brain”問題，CMAN 提供了 quorum 算法，Qpidd 利用 CMAN 的接口，知道自己是否能夠達到法定人數(shù)，是否能夠加入集群工作

Qpid 集群是一個 Active/Active 模式的集群?？蛻舳丝梢允褂萌我庖粋€ broker。如下左圖所示：

當(dāng) client 連接到一個集群中的 broker 時，該 broker 返回給 Client 相應(yīng)的 Broker URL 列表。在上圖中，Client 將得到 [QpiddA,QpiddB] 這樣一個列表。當(dāng) QpiddA 的連接斷開時，客戶端可以自動重新連接到 QpiddB 繼續(xù)服務(wù)。

最新穩(wěn)定版本0.30發(fā)布于2014-09-26。2015-01-27發(fā)布修復(fù)幾個漏洞的0.31版本補丁。0.30版本源代碼中，C/C++代碼一共大概10萬行，其中主體代碼占大概8萬，客戶端API及Demo占大概2萬。官方0.30版本整個源碼包統(tǒng)計詳細結(jié)果如下圖。

參考文獻：

總結(jié)

以上是生活随笔為你收集整理的python消息中间件有哪些_消息中间件选型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。