一、???? 分布式系統消息通信技術簡介

分布式系統消息通信技術主要包括以下幾種：

1.RPC(Remote Procedure Call Protocol).

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

2.CORBA(Common Object Request Broker Architecture).

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

3.RMI(Remote Method Invocation).

面向對象方式的 Java RPC

4.WebService.

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

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 系統構架

二、???? 常見開源跨平臺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有關聯的其他項目主要有:

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

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中使用也很方便。

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文檔鏈接：

Metamorphosis (MetaQ)

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

開發語言： Java

操作系統： 跨平臺

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++

操作系統： 跨平臺

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

操作系統： 跨平臺

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

操作系統： 跨平臺

三、???? 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和對應的配置:

情景A：

情景 B：

情景 C：

情景 D：

結論：

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

2)??????? 處理大消息，持久化的弊端(磁盤或數據庫保存)就開始凸顯 (QPID 處理瞬時化消息不論消息大小，都顯得非常高效)?？梢缘贸?#xff0c;處理中小消息的耗時主要在集中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和磁盤讀寫。

四、???? ZeroMQ簡介

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

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

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

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

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

管道模型(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千行左右。詳細如下圖。

五、??? ?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 ::=

[ / ] [ ; ]

options ::= { : , ... }

其中 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版本整個源碼包統計詳細結果如下圖。

參考文獻：

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。