消息中間件選型

1、     分佈式系統消息通訊技術簡介

分佈式系統消息通訊技術主要包括如下幾種：

1. 1.         RPC(Remote Procedure Call Protocol).

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

1. 2.         CORBA(Common Object Request Broker Architecture).

CORBA從概念上擴展了RPC。面向對象的，企業級的(面向對象中間件還有DCOM)

1. 3.         RMI(Remote Method Invocation).

面向對象方式的 Java RPC

1. 4.         WebService.

基於Web，C/S或B/S，跨系統跨平臺跨網絡。多爲同步調用, 實時性要求較高

1. 5.         MOM(Message oriented Middleware).

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

JMS是Java平臺上的面向接口的消息規範，是一套API標準，並無考慮異構系統。AMQP是一個面向協議的，跟語言平臺無關的消息傳遞應用層協議規範。STOMP是流文本定向消息協議，是一種爲MOM設計的簡單文本協議。AMQP和STOMP都是跟http處於同一層的協議。

在 AMQP 模型中，消息的 producer 將 Message 發送給 Exchange，Exchange 負責交換 / 路由，將消息正確地轉發給相應的 Queue。消息的 Consumer 從 Queue 中讀取消息。

AMQP 系統構架

 

 

2、     常見開源跨平臺MQ簡介

目前業界上關於消息中間件的實現多達好幾十種，可謂百花齊放，所用的實現語言一樣也五花八門。下面挑選了一部分，在網上開源社區相對容易搜索出來的十多種MQ來做簡單介紹。

開源MQ	概述
1.Qpid	Apach的一個開源AMQP實現，broker架構，有C++和Java兩個版本
2.RabbitMQ	LShift 用Erlang實現，支持多協議，broker架構，重量級
3.ZeroMQ	AMQP最初設計者iMatix公司實現，輕量消息內核，無broker設計。C++實現
4.Jafka/Kafka	LinkedIn用Scala語言實現，支持hadoop數據並行加載
5.ActiveMQ	Apach的一種JMS具體實現，支持代理和p2p部署。支持多協議。Java實現
6.Apollo	ActiveMQ的下一代產品，支持多協議，Scala實現
7.Redis	Key-value  NoSQL數據庫，有MQ的功能
8.MemcacheQ	國人利用memcache緩衝隊列協議開發的消息隊列,C/C++實現
9.Open-MQ	C++和QT實現，支持JMS
10.ActiveMQ-CPP	ActiveMQ的C++純客戶端庫，用於跟ActiveMQ通訊
11.MQ4CPP	一個C++實現的MQ，信息甚少
12.MetaQ	Alibaba對Kafka的改造，增長事務支持等新特性，用純Java實現
13.Beanstalkd	一個類memcached協議設計的消息隊列,C/C++實現
14.OpenAMQ	iMatix公司AMQP1.0的實現，相似rabbitMQ。C++實現。2010年項目放棄
15.Spread Toolkit	高性能的分佈式分組消息系統，C++實現
16.SAFMQ	C++實現的儲存轉發消息隊列中間件
17. Mosquitto	一個輕量級的IBM物聯網鏈接協議的消息中間件實現，C/C++實現
18.MUSCLE	提供一個多路消息服務器和消息對象傳遞功能，支持C/C++
19.JORAM	一個相似OpenJMS(Sun OpenMQ)的JMS消息中間件，JAVA實現

 

Qpid

 

Qpid 是 Apache 開發的一款面向對象的消息中間件，它是一個 AMQP 的實現，能夠和其餘符合 AMQP 協議的系統進行通訊。Qpid 提供了 C++/Python/Java/C# 等主流編程語言的客戶端庫，Qpid 提供了不少額外的 HA 特性，很是適於集羣環境下的消息通訊。

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

• 採用 Corosync 來保證了集羣環境下的 Fault-tolerant 特性
• 支持 XML 類型的 Exchange，當消息格式爲 XML 時，能夠利用 Xquery 進行過濾
• 支持 plugin，用戶能夠方便地增長新的功能，好比新的 exchange 類型

提供了安全認證特性，任何 producer/consumer 須要和 broker 通訊時，都須要提供身份認證。QPID 的安全認證使用 SSL 協議。

受權協議： Apache

開發語言： Java C/C++

操做系統： 跨平臺

官網：http://qpid.apache.org  最新版本0.30發佈於2014-09-26。

 

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

跟Qpid有關聯的其餘項目主要有:

ActiveMQ and AMQP using Qpid Proton

Apache Camel and AMQP using Qpid

Apache Axis and AMQP using Qpid

Microsofe Azure using Qpid Proton

Apache軟件基金會一級開源項目入選Qpid is a top-level project at Apache

Pulp 2.5程序庫內容管理工具裏集成有Qpid.

Fedora默認使用Qpid做爲消息隊列

 

 

RabbitMQ

 

LShift 用Erlang編寫的一個開源的消息隊列，支持不少的協議：AMQP，XMPP, SMTP, STOMP，重量級，更適合於企業級的開發。代理(Broker)架構，對路由(Routing)，負載均衡(Load balance)或者數據持久化都有很好的支持。

缺點：可擴展性差，速度較慢，由於中央節點增長了延遲，消息封裝後也比較大。

AMQP 裏主要要說兩個組件：Exchange 和 Queue （在 AMQP 1.0 裏還會有變更），以下圖所示，綠色的 X 就是 Exchange ，紅色的是 Queue ，這二者都在 Server 端，又稱做 Broker ，這部分是 RabbitMQ 實現的，而藍色的則是客戶端，一般有 Producer 和 Consumer 兩種類型：

 

受權協議： MPL

開發語言： ErLang

操做系統： 跨平臺

官網：http://www.rabbitmq.com/，最新版本3.4.3發佈於2015-1-7

 

ØMQ(ZeroMQ)

 

早期須要設計可靠消息系統好比AMQP，可是這種方式引入了single-point broker。對於須要這種可靠消息系統的應用來講，須要在broker上面作至關多的事情確保可靠性以及性能。可是這樣對於中小應用陷入了尷尬，爲了使用這種方便的消息系統他們須要引入broker這麼東西是不可以忍受的。咱們須要的一種簡單方便的消息傳輸系統，沒有任何附加代價(好比全部數據都流經 broker)，這就是ZeroMQ設計初衷。

2010年3月30日，AMQP的最初設計者iMatix公司的首席執行官Pieter Hintjens宣佈iMatix將退出AMQP工做組，並且爲了簡單得多，快的多的ZeroMQ，將不支持可能發佈的AMQP/1.0。一個很是輕量級的消息內核，專門爲高吞吐量/低延遲的場景開發。ZeroMQ支持許多高級消息場景，可是你必須實現ZeroMQ框架中的各個塊（好比Socket或Device等）。沒有中間件架構，應用程序端點扮演了這個服務角色。部署簡單，僅提供非持久性的隊列。與RabbitMQ相比，ØMQ並不像是一個傳統意義上的消息隊列服務器，事實上，它也根本不是一個服務器，它更像是一個底層的網絡通信庫，在socket API之上作了一層封裝，將網絡通信、進程通信和線程通信抽象爲統一的API接口。

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

受權協議： LGPL

開發語言： C/C++

操做系統： 跨平臺

官網：http://zeromq.org/,   最新版本4.1.0發佈於2014/10/14。Twitter的Storm中使用ZeroMQ做爲數據流的傳輸，還有常見於金融界的應用中。Mongrel2是使用ZeroMQ的一個Web服務器。

 

Jafka/Kafka

 

LinkedIn用Scala語言開發。高吞吐量高性能支持跨語言分佈式Publish/Subscribe消息隊列系統，而Jafka是在Kafka之上孵化而來的。快速持久化、高吞吐、徹底的分佈式系統、支持Hadoop數據並行加載。

 

受權協議： Apache

開發語言： Scala

操做系統： 跨平臺

 

ActiveMQ

 

居於二者(RabbitMQ & ZeroMQ)之間，相似於ZeroMQ，它能夠部署於代理模式和P2P模式。徹底支持JMS1.1和J2EE 1.4規範。跨平臺的，多種語言和協議編寫客戶端,Java, C, C++, C#, Ruby, Perl, Python, PHP。應用協議: OpenWire, Stomp REST, WS Notification, XMPP, AMQP。如需配置ActiveMQ則須要在目標機器上安裝Java環境。支持集羣，同等網絡，自動檢測，TCP，SSL，廣播，持久化，XA，多個消息也能夠組成原子事務

缺點：默認的配置性能偏低，須要優化配置，可是配置文件複雜，自己不提供管理工具；示例代碼很是少；主頁上的文檔看上去比較全面，可是缺少一種有效的組織方式，文檔只有片斷，用戶很難由淺入深進行了解，二來文檔總體的專業性太強。

受權協議： Apache

開發語言： Java

操做系統： 跨平臺

 

Apollo

 

ActiveMQ的下一代產品爲Apollo，Apollo以ActiveMQ原型爲基礎，是一個更快、更可靠、更易於維護的消息代理工具。Apache稱Apollo爲最快、最強健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息協議）服務器。

l  Apollo的特性以下：

l  支持Stomp 1.0和Stomp 1.1協議

l  主題和隊列

l  隊列瀏覽器

l  主題持久訂閱

l  鏡像隊列

l  可靠的消息傳遞

l  消息過時和交換

l  消息選擇器

l  JAAS驗證

l  基於ACL的受權

l  支持SSL/TLS，證書驗證

l  REST Management API

http://activemq.apache.org/apollo/

 

Redis

一個Key-Value的NoSQL數據庫，開發維護很活躍，雖然它是一個Key-Value數據庫存儲系統，但它自己支持MQ功能，因此徹底能夠當作一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操做，各執行100萬次，每10萬次記錄一次執行時間。測試數據分爲128Bytes、512Bytes、1K和10K四個不一樣大小的數據。實驗代表：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而若是數據大小超過了10K，Redis則慢的沒法忍受；出隊時，不管數據大小，Redis都表現出很是好的性能，而RabbitMQ的出隊性能則遠低於Redis。（盛大開源的DOMQ用的是redis）

 

MemcacheQ

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

l  簡單易用

l  處理速度快

l  多條隊列

l  併發性能好

l  與memcache的協議兼容。這就意味着只要裝了memcache的extension就能夠了，不須要額外的插件。

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

官網：http://memcachedb.org/memcacheq/  最新版本0.2.0發佈於2009/12。新浪微博有用。

 

Open-MQ

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

受權協議： 未知

開發語言： C/C++

操做系統： 跨平臺

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

 

ActiveMQ-CPP

CMS (全稱是 C++ Messaging Service) 是一個 C++ 實現的相似 JMS 的 API，用於實現例如 ActiveMQ 的消息代理服務。CMS 能夠幫助你的 C++ 客戶端代碼更見簡單。ActiveMQ-CPP 是一個純客戶端庫，用它來跟例如 ActiveMQ 等消息服務通信。咱們的 CMS 實現名爲 ActiveMQ-CPP，使用可插入式的傳輸和協議，當前支持 OpenWire 和 Stomp協議，基於 TCP 和 SSL 。同時支持故障轉移傳輸。

 

受權協議： Apache

開發語言： C/C++

操做系統： 跨平臺

 

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

 

受權協議：LGPL

開發語言：C++

操做系統：跨平臺

官網：http://www.sixtyfourbit.org  域名已失效，資料甚少。僅有個overview PDF文檔連接：

http://blog.chinaunix.net/attachment/attach/24/54/45/42245445426591fadde801572bf29de4e1f5bd0f37.pdf

最新版本1.16發佈於2007年 http://freecode.com/projects/mq4cpp

 

Metamorphosis (MetaQ)

一個高性能、高可用、可擴展的分佈式消息中間件，Linkedin開源MQ——Kafka的Java版本，阿里巴巴對此作了定製和優化，具備消息存儲順序寫、吞吐量大和支持本地和XA事務等特性，適用於大吞吐量、順序消息、廣播和日誌數據傳輸等場景

 

開發語言： Java  

操做系統： 跨平臺

官網： http://metaq.taobao.org/   https://github.com/killme2008/Metamorphosis/

 

Beanstalkd

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

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

受權協議： MIT

開發語言： C/C++

操做系統： 跨平臺

連接：https://github.com/kr/beanstalkd  目前支持過有9.5 million用戶的Facebook Causes應用。PostRank大規模部署和使用，天天處理百萬級任務

 

OpenAMQ

一個分佈式的消息通信框架。消息異步傳遞的。主要爲高性能和可靠性而設計。該項目服務器端採用 GPL 受權協議，客戶端（Python、Java、Ruby、C）是 BSD 受權協議。iMatrix公司早期也是計劃按照AMQP/1.0標準開發一個相似RabbitMQ的項目，名字叫作OpenAMQ。然而，隨着項目的推動，iMatrix公司在這個項目上迷失了方向。iMatrix的CEO Pieter Hintjens在一篇文章中描述了本身對AMQP標準化進程的困惑和思考，並認爲AMQP中存在一些沒法克服的問題。2010年3月，iMatrix公司宣佈退出AMQP/1.0標準化，放棄OpenAMQ項目，並正式啓動了ØMQ，即ZeroMQ

受權協議： GPLv2/BSD

開發語言： C/C++

操做系統： 跨平臺

官網：http://www.openamq.org/  目前最新版1.4發佈於2010/10/7

 

The Spread Toolkit

 

高性能的分佈式分組消息系統，支持局域網以及廣域網通信. Spread能夠做爲一個分佈式應用的消息總線，而且具備高度的靈活性，能夠作到多播，分組，以及點對點餓消息傳遞。

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

在一個典型的環境中，一般每臺服務器上運行一個Spread server，客戶端的程序本地鏈接server，發送信息，而這臺服務器上的spread server會傳遞信息給其餘訂閱了這條消息的應用。固然也能夠只有一個spread server，而其餘的客戶端分佈在整個網絡中。

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.

 

受權協議： Spread Open-Source License(相似BSD)&&商業協議

開發語言： C/C++

操做系統： 跨平臺

官網： http://www.spread.org/ 目前最新版本4.4.0發佈於2014/5/28，目前所知國內豆瓣在使用。國外有研究項目Secure Spread、Wackamole、Oasis、MEAD、ATLAS RepDB*等，國外應用有mod_log_spread、Fedora Unity Spread Logging、Splash、MySQL Message API、Zope Replication Services、Spread Management Tools、Ssrc Wisp™ Event-based distributed service framework、Perl Messaging:Courier library、Perl Spread-Queue module等等。

 

SAFMQ (Store and Forward Message Queue)

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

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

受權協議： Apache

開發語言： Java C/C++ PHP

操做系統： 跨平臺

官網： http://safmq.sourceforge.net/  ，最新版本0.8.3.1發佈於2010/11/3

 

Mosquitto

一個開源(BSD許可證)的消息代理，實現MQTT(消息隊列遙測傳輸)協議版本3.1。提供了Windows、Linux以及qnx系統的版本。MQTT是輕量級基於代理的發佈/訂閱的消息傳輸協議。 MQTT是IBM開發的一個即時通信協議。MQTT是面向M2M和物聯網的鏈接協議，採用輕量級發佈和訂閱消息傳輸機制

有三種消息發佈服務質量：

「至多一次」，消息發佈徹底依賴底層 TCP/IP 網絡。會發生消息丟失或重複。這一級別可用於以下狀況，環境傳感器數據，丟失一次讀記錄無所謂，由於不久後還會有第二次發送。

「至少一次」，確保消息到達，但消息重複可能會發生。

「只有一次」，確保消息到達一次。這一級別可用於以下狀況，在計費系統中，消息重複或丟失會致使不正確的結果。

受權協議： BSD

開發語言： C/C++

操做系統： 跨平臺

官網： http://mosquitto.org/ 最新版本1.3.5發佈於2014/10/8

 

MUSCLE (Multi User Server Client Linking Environment)

提供一個多路的消息服務器以及相應的網絡API，其客戶端涉及多種語言包括 C, C++, C#, Delphi, Java, 和 Python。MUSCLE 用來在網絡上傳輸消息對象，全部消息存儲在服務端併爲客戶端進行傳遞。

受權協議： BSD

開發語言： Java C/C++ Python C#

操做系統： 跨平臺

官網：https://public.msli.com/lcs/muscle/ 目前新版6.10發佈於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消息中間件。文檔很是完備，而且帶有不少示例。

缺點：

判斷JMS客戶端是否在線很是緩慢，有時甚至不會通知應用

受權協議： 未知

開發語言： Java

操做系統： 跨平臺

官網：http://joram.objectweb.org/

 

 

3、     MQ比較

一些國外網站提供的，ActiveMQ、RabbitMQ、RocketMQ（MeteMQ）、HornetQ、Qpid、ZeroMQ的對比數據。

協議支持比較：

	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 字節大小的消息, 而後再出隊

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

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

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

 

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

下面是測試的全部brokers和對應的配置:

• ActiveMQ 5.8.0   STOMP
• RabbitMQ 3.0.2   STOMP、AMQP
• HornetQ 2.3.0    STOMP
• Apollo 1.6       STOMP
• QPID 0.20 (Java 版本)   AMQP
• 自制ZeroMQ 2.2.0 broker，無任務協議支持，無持久化

 

 

情景 A：

 

情景 B：

 

 

情景 C：

 

情景 D：

 

結論：

1)        Brokers廣泛擅長於處理大消息。所以若是客戶端支持對消息分組，那性能會獲得更大的提高。但分組消息卻不能在consumer之間傳播。

2)        處理大消息，持久化的弊端（磁盤或數據庫保存）就開始凸顯 (QPID 處理瞬時化消息不論消息大小，都顯得很是高效)。能夠得出，處理中小消息的耗時主要在集中CPU，而不是I/O網絡上。

3)        ZeroMQ broker比其餘全部MQ broders表現得更優越。假若需求上要用到一些特殊的broker特性，否則ZeroMQ 絕對是分發消息系統的一個最好選擇。

4)        QPID 彷佛是在處理瞬時消息上綜合表現得最好。

5)        從RabbitMQ的測試結果看，AMQP 協議彷佛比STOMP協議更優越. 固然這結果也可能跟不良設計的客戶端受到影響。

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

7)        除了處理大消息以外，RabbitMQ 彷佛是最好的選擇，因它的性能是其餘的3倍左右。

下圖是顯示的是發送和接受的每秒鐘的消息數。整個過程共產生1百萬條1K的消息。測試的執行是在一個Windows Vista上進行的。

 

 

選擇消息系統根據業務須要須要考慮如下幾個方面：

l  是否持久化

l  吞吐能力

l  高可用，避免單點故障

l  分佈式擴展能力

l  兼容現有協議

l  易於維護

l  其餘，如消息丟失和重複的處理

l  負載均衡

 

常見消息系統協議：

l  STOMP

l  AMQP

l  相似 MEMCACHE 的協議

l  HTTP

l  MQTT

 

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

	Qpid	ZeroMQ	Beanstalkd	Spread	Open-MQ	memcachedQ	SAFMQ	Mosquitto	MUSCLE
JMS	━	━	━	━	√	━	━	━	━
AMQP	√	━	━	━	━	━	━	━	━
MQTT	━	━	━	━	━	━	━	√	━
OpenWire	━	━	━	━	━	━	━	━	━
Stomp	━	━	━	━	√	━	━	━	━
Memcache協議	━	━	√	━	━	√	━	━	━
HA集羣(防單點故障)	√	√	━	√	━	━	━	━	━
認證	√	━	━	√	━	━	√	━	━
Broker架構	√	━	√	√	√	√	√	√	√
持久化	√	━	√	√	━	━	√	━	━
支持廣域網	━	━	━	√	━	━	━	━	━
高吞吐	√	√	√	√	√	√	√	━	━
事務	√	━	━	━	━	━	━	━	━

 

下面對非持久化消息進行了測試(ZeroMQ自實現一個簡單broker，直接內存操做和轉發)

測試硬件環境：

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

 

測試結果：

 

 

 

結論：

1)      瞬時化消息的處理性能明顯大大優於持久化消息的處理

2)      二者都更擅長處理大消息體數據

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

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

 

4、     ZeroMQ簡介

ZeroMQ用於node與node間的通訊，node能夠是主機或者是進程。ZeroMQ 把通信的需求當作四類。其中一類(Exclusive-Pair)是一對一對應通信，用來支持傳統的 TCP socket 模型，但並不推薦使用。經常使用的通信模式只有三類。

1. 請求迴應模型（Request-Reply）。

由請求端發起請求，並等待迴應端迴應請求(阻塞的)。請求端和迴應端均可以是1:N的模型。一般把1認爲是server，N認爲是Client。ZeroMQ 能夠很好的支持路由功能（實現路由功能的組件叫做 Device），把 1:N 擴展爲 N:M。

            

1. 發佈訂閱模型（Publish-Subscribe）。

發佈端是單向只發送數據的，且不關心是否把所有的信息都發送給訂閱端。若是發佈端開始發佈信息的時候，訂閱端還沒有鏈接上來，這些信息直接丟棄。不過一旦訂閱端鏈接上來，中間會保證沒有信息丟失(以前的消息會丟掉，Slow joiner問題)。一樣，訂閱端則只負責接收，而不能反饋。Publisher 中途離開，全部的 Subscriber 會 hold 住，等待 Publisher 再上線的時候，會繼續接受信息。若是發佈端和訂閱端須要交互（好比要確認訂閱者是否已經鏈接上），則使用額外的 socket 採用請求迴應模型知足這個需求。

           

1. 管道模型（Push-Pull）。

這個模型裏，管道是單向的，從 PUSH 端單向的向 PULL 端單向的推送數據流。

 

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

ZeroMQ 中的 Transient (短暫) 和 Durable (持久) socket 也並不是區別於實現層是否保持了 tcp 鏈接。而是概念上的不一樣。對於 Durable socket ，其生命期能夠長於一個進程的生命期，即便進程退出，再次啓動後依舊能夠維持繼續以前的 socket。

l  zmq_init建立一個context，能夠認爲是一個MQ實例或句柄。1表示IO線程數。

l  zmq_socket根據context來建立一個socket,後面類型指定了MQ通訊類型。

l  zmq_bind/zmq_connect能夠進行綁定進行監聽或者是進行鏈接。

l  zmq_msg_init/zmq_msg_init_size能夠用來初始化一個message

l  zmq_send/zmq_recv能夠進行message的發送和接收。

l  zmq_msg_close銷燬一個message

l  zmq_close關閉一個socket

l  zmq_term銷燬一個context

 

通訊協議：

l  tcp // 跨主機間通訊

l  ipc // 進程間通訊

l  inproc // 線程間通訊

l  pgm // ━━━

l  epgm // ━━━

 

消息：

ZeroMQ通訊通訊單元是消息，他除了知道 Bytes 的大小，他並不關心的消息格式。zmq_recv/zmq_send只可以處理內置的消息格式，而不可以處理http請求這種字節流。ZMQ容許一條message按照多個部分進行發送(multipart message)。底層使用其餘線程完成了IO讀寫。ZMQ內置有一個字節流成幀策略。

 

Identity：能夠用來表示一個socket的身份

Device：一旦通訊節點超過必定數量的話，那麼最好須要一個轉發節點或者是中間節點。

 

擁塞：

ZMQ能夠經過控制HWM(high-water mark)來控制擁塞。內部實現上每個socket有關聯了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的話，那麼會根據socket類型來決定是丟棄仍是block.如今實現而言的話PUB會嘗試丟棄數據，而其餘類型的socket就會block住。 若是socket是線程之間進行通訊的話，那麼HWM是二者socket的HWM之和。由於默認HWM是ulimited的，因此只要一端沒有設置的話那麼容量就無限。

 

官網：http://zeromq.org/, 最新版本4.1.0發佈於2014/10/14。Twitter的Storm中使用ZeroMQ做爲數據流的傳輸，還有常見於金融界的應用中。

關於ZeroMQ的權威資料，除了官方文檔，還有O'Reilly出版社2013年出版的一本書，《ZeroMQ: Messaging for Many Applications》，做者: Pieter Hintjens

 

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

 

 

 

 

5、     Qpid簡介

基本 Qpid 通訊系統的幾個組件

 

Address 地址

Qpid Address 表示一個節點，有兩種節點：一種是 queue，另一種是 topic。queue映射到 AMQP 概念就是 Queue；而 topic則映射到 Exchange。Queue 節點可以緩存消息，直到被讀取走爲止；而 topic 節點則即時進行轉發，好比假若有 4 個 consumer 對某消息感興趣，當消息到達節點時，有 3 個 consumer 正在運行，那麼 topic 節點會將消息轉發給這 3 個 consumer，而後就將該消息丟棄。剩下的那個 consumer 再運行時，則收不到這個消息。

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

address_string ::= <address> [ / <subject> ] [ ; <options> ]  options ::= { <key> : <value>, ... }

 

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

Subject 相似 email 的主題。每一個消息均可以有一個主題，接收者能夠經過主題對消息進行過濾。

Option 的具體含義有點兒複雜，能夠參考 Qpid 的編程手冊獲取完整的描述。

 

Broker Federation

單一 Broker 的構架

 

Broker Federation 的配置

 

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

Queue route：目的地必須是 Exchange，源是一個 Queue。此類路由將源地址 Queue 收到的全部消息都轉發到目的 Exchange 去。

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

 

RDMA

RDMA 全稱爲「Remote Direct Memory Access」，它是一種協議，將數據從一臺計算機的內存直接傳輸到另一臺計算機的內存中，而無需 CPU 的參與。相似 CPU 與外設之間的 DMA 傳輸，RDMA 將 DMA 的概念擴展到了網絡。

C++ 版本的 Qpid broker 除了使用傳統的 TCP/IP 做爲網絡通訊機制以外，在擁有 infiniband 設備的集羣上 Qpid 還可使用 RDMA 進行網絡通訊。

 

持久化消息

Broker 將收到的消息暫存在磁盤等能夠永久保存信息的地方備用，這樣，即便 Broker 由於某種意外而中斷，當其再次從新啓動以後，仍是能夠將保持在永久存儲介質中的消息讀出來並繼續進行轉發。除了 Queue 須要 durable 以外，咱們還必須保證發送的消息有 durable 屬性。

 

高可用性

在一個 Qpid broker 集羣中，全部的 broker 都互相備份，進行 fail over 的必要準備工做。每一個 broker 的內部對象都同步到其餘集羣中的 Broker，保持一致，這樣在單一 Broker 沒法工做的狀況下，client 能夠切換到其餘 Broker，而避免信息的丟失和服務中斷。

Qpid 和 Corosync 的工做模式

Qpidd A 和 QpiddB 經過 Corsync 同步。Qpid 還經過 CMAN 來防止集羣中的」split brain」問題，CMAN 提供了 quorum 算法，Qpidd 利用 CMAN 的接口，知道本身是否可以達到法定人數，是否可以加入集羣工做

Qpid 集羣是一個 Active/Active 模式的集羣。客戶端可使用任意一個 broker。以下左圖所示：

 

當 client 鏈接到一個集羣中的 broker 時，該 broker 返回給 Client 相應的 Broker URL 列表。在上圖中，Client 將獲得 [QpiddA,QpiddB] 這樣一個列表。當 QpiddA 的鏈接斷開時，客戶端能夠自動從新鏈接到 QpiddB 繼續服務。

 

最新穩定版本0.30發佈於2014-09-26。2015-01-27發佈修復幾個漏洞的0.31版本補丁。0.30版本源代碼中，C/C++代碼一共大概10萬行，其中主體代碼佔大概8萬，客戶端API及Demo佔大概2萬。官方0.30版本整個源碼包統計詳細結果以下圖。

 

 

參考文獻：

一、http://predic8.com/activemq-hornetq-rabbitmq-apollo-qpid-comparison.htm

二、http://www.tuicool.com/articles/JvQRbm

三、http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/

四、http://blog.jobbole.com/45547/

五、http://blog.fity.cn/post/377/

六、http://www.ibm.com/developerworks/cn/opensource/os-cn-qpid1/#ibm-pcon

七、http://news.cnblogs.com/n/154000/

 

 

 

 

本博客內容爲原創。網友轉載請給出文章出處和個人名字。

 

分類:  MQ