8大常用通訊中介軟體/MQ使用總結
轉自：http://www.voidcn.com/blog/fanyun_01/article/p-6151771.html
看來ZeroMQ和Kafka在這些中介軟體當中還是比較突出的。
8大通訊中介軟體/MQ，比較常用且有名的有如下幾種：
1. ACE：
ACE提供了一組豐富的可重用C++包裝外觀（WrapperFacade）和框架元件，可跨多種平臺完成通用的通訊軟體任務，其中包括：事件多路分離和事件處理器分派、訊號處理、服務初始化、程序間通訊、共享記憶體管理、訊息路由、分散式服務動態（重）配置、併發執行和同步等等。ACE簡化了使用程序間通訊、事件多路分離、顯式動態連結和併發的面向物件的網路應用和服務的開發。
ACE架構圖如圖1-1所示：
圖1-1 ACE架構圖
ACE的優點主要有：
(1).增強可移植性：在ACE元件的幫助下，很容易在一種OS平臺上編寫併發網路應用，然後快速地將它們移植到各種其他的OS平臺上。
(2).更好的軟體質量：ACE使用了許多可提高軟體質量的關鍵設計模式，提供了通訊軟體靈活性、可擴充套件性、重用性和模組性。
(3).更高的效率和可預測性：ACE支援廣泛的應用服務質量（QoS）需求，包括延遲敏感應用的低響應等待時間、高頻寬應用的高效能，以及實時應用的可預測性。
(4).更容易轉換到標準的高階中介軟體：TAO使用了ACE提供的可重用元件和模式，按照CORBA的標準實現，並且為高效能和實時系統作了優化。
(5).ACE包含一個高階的網路程式設計框架，整合並增強了較低層次的C++包裝外觀。該框架支援將併發分散式服務動態配置進應用。後者比前者更加底層，更加抽象。ACE可以認為是通用網路程式設計框架軟體，而ICE則是一個跨平臺的RPC軟體。
ACE的缺點主要有：
(1).整個架構比較複雜，研究學習還是比較好的選擇，但是使用比較複雜。
2. ICE：
ICE是一款高效能的中介軟體，支援分散式的部署管理，訊息中介軟體，以及網格計算等等。主要結構如下圖2-1所示：
圖2-1 ICE架構圖
ICE的優點主要有：
(1).面向物件的語義，所有的操作呼叫都使用遲後繫結。
(2).支援同步和非同步的訊息傳遞，提供了同步和非同步的操作呼叫和分派，提供了釋出——訂閱訊息傳遞機制。
(3).與硬體架構無關，客戶端及伺服器與底層的硬體架構遮蔽開來。對於應用程式碼而言，像位元組序和填充這樣的問題都隱藏了起來。
(4).與上層的程式語言無關，客戶端和伺服器可以分別部署，所用語言也可以不同，支援C++、Java語言，客戶端支援PHP語言。
(5).與採用的作業系統無關，ICE完全是可移植的，同樣的原始碼能夠在Windows、Linux、MacOS和UNIX上編譯和執行。
(6).完全是執行緒化的，其API是執行緒安全的。
(7).採用TCP、IP 和UDP作為傳輸協議，客戶端和伺服器程式碼都不需要了解底層的傳輸機制。
(8).伺服器的位置是對使用者透明的，ICE例程負責定位物件，並管理底層的傳輸機制，比如開啟和關閉連線。客戶與伺服器之間的互動顯得像是無連線的。伺服器可以遷移到不同的實體地址，而不會使客戶持有的代理失效，而客戶完全不知道物件實現是怎樣分佈在多個伺服器程序上的。
(9).採用SSL強加密，可以使客戶和伺服器完全安全地進行通訊。
(10).採用內建的持久機制建立持久的物件。並且提供了對高效能資料庫Berkeley DB的內建支援。
ICE的缺點主要有：
(1).整個架構比較複雜，研究學習還是比較好的選擇，但是使用比較複雜。
3. Boost::ASIO：
Boost Asio ( asynchronous input and output)關注非同步輸入輸出。BoostAsio庫提供了平臺無關性的非同步資料處理能力（當然它也支援同步資料處理）。一般的資料傳輸過程需要通過函式的返回值來判斷資料傳輸是否成功。Boost Asio將資料傳輸分為兩個獨立的步驟：
採用非同步任務的方式開始 資料傳輸。將傳輸結果通知呼叫端。與傳統方式相比，優點在於程式在資料傳輸期間不會阻塞。
Boost：：ASIO架構圖如下圖3-1所示：
圖3-1 Boost：：ASIO架構圖
Boost::ASIO的優點：
(1). 與傳統方式相比，優點在於程式在資料傳輸期間不會阻塞。
(2). 可擴充套件多執行緒。
(3). 可移植。
Boost::ASIO的缺點：
(1).抽象複雜。
(2).記憶體佔用。
4. MSMQ：
MSMQ全稱MicroSoft Message Queue，微軟訊息佇列,是在多個不同的應用之間實現相互通訊的一種非同步傳輸模式，相互通訊的應用可以分佈於同一臺機器上，也可以分佈於相連的網路空間中的任一位置。它的實現原理是：訊息的傳送者把自己想要傳送的資訊放入一個容器中（我們稱之為Message），然後把它儲存至一個系統公用空間的訊息佇列(Message Queue)中；本地或者是異地的訊息接收程式再從該佇列中取出發給它的訊息進行處理。訊息Message是由通訊的雙方所需要傳遞的資訊。
MSMQ架構圖如圖4-1所示：
圖4-1 MSMQ架構圖
MSMQ系統配置圖如圖4-2所示：
圖4-2 MSMQ系統配置圖
佇列的型別主要包括一下幾種:
(1).“公共佇列”在整個“訊息佇列”網路中複製，並且有可能由網路連線的所有站點訪問。
(2).“專用佇列”不在整個網路中釋出。相反，它們僅在所駐留的本地計算機上可用。專用佇列只能由知道佇列的完整路徑名或標籤的應用程式訪問。
(3).“管理佇列”包含確認在給定“訊息佇列”網路中傳送的訊息回執的訊息。指定希望 MessageQueue 元件使用的管理佇列（如果有的話）。
(4).“響應佇列”包含目標應用程式接收到訊息時返回給傳送應用程式的響應訊息。指定希望 MessageQueue 元件使用的響應佇列（如果有的話）。
優點:穩定、訊息優先順序、離線能力以及安全性,有保障的訊息傳遞和執行許多業務處理的可靠的防故障機制。
缺點:MSMQ不適合於Client需要Server端實時互動情況.大量請求時候,響應延遲.
5. ActiveMQ：
ActiveMQ 是Apache出品，最流行的、功能強大的即時通訊和整合模式的開源伺服器。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMSProvider實現。提供客戶端支援跨語言和協議，帶有易於在充分支援JMS 1.1和1.4使用J2EE企業整合模式和許多先進的功能。（官網：http://activemq.apache.org/ 5.3.0）
ActiveMQ架構圖如圖5-1所示：
圖5-1 ActiveMQ架構圖
優點：
(1). 支援多種語言和協議編寫客戶端。語言：Java、C、C++、C#、Ruby、Perl、Python、PHP。應用協議：OpenWire、Stomp REST、WS Notification、XMPP、AMQP
(2). 支援多種傳送協議：in-VM、TCP、SSL、NIO、UDP、JGroups、JXTA。
(3). 支援通過JDBC和journal提供高速的訊息持久化。
(4). 從設計上保證了高效能的叢集，客戶端-伺服器，點對點，執行效率高。
(5). 使用環境簡單，支援自動重連，支援Ajax，支援與Axis的整合。
(6). 可以很容易得呼叫內嵌JMSprovider，進行測試
缺點：
(1). 傳輸檔案不方便，而且效率相對來說不是很高
6. RabbitMQ：RabbitMQ是由 LShift 提供的一個 Advanced Message Queuing Protocol (AMQP) 的開源實現，由以高效能、健壯以及可伸縮性出名的 Erlang 寫成，因此也是繼承了這些優點。
主要要說兩個元件：Exchange和 Queue （在 AMQP 1.0 裡還會有變動），如下圖所示，綠色的 X 就是 Exchange ，紅色的是 Queue ，這兩者都在 Server 端，又稱作 Broker ，這部分是 RabbitMQ 實現的，而藍色的則是客戶端，通常有 Producer 和 Consumer 兩種型別：
架構圖如圖6-1所示：
圖6-1 RabbitMQ架構圖
（官網： http://www.rabbitmq.com/1.7.0 ）
優點：
(1).RabbitMQ易於使用和部署，適宜於很多場景如路由、負載均衡或訊息持久化等，用訊息佇列只需幾行程式碼即可搞定。
(2).對外提供客戶端API，支援多種程式語言。
(3).基於erlang語言開發具有高可用高併發的優點，適合叢集伺服器。
(4). 健壯、穩定、易用、開源、跨平臺、支援多種語言、文件齊全。
(5). 有訊息確認機制和持久化機制，可靠性高。
缺點：
(1).這使得它的可擴充套件性差，速度較慢，因為中央節點增加了延遲，訊息封裝後也比較大。
7. ZeroMQ：
ZeroMQ是一種基於訊息佇列的多執行緒網路庫，其對套接字型別、連線處理、幀、甚至路由的底層細節進行抽象，提供跨越多種傳輸協議的套接字。ZeroMQ是網路通訊中新的一層，介於應用層和傳輸層之間（按照TCP/IP劃分），其是一個可伸縮層，可並行執行，分散在分散式系統間。ZeroMQ是一個非常輕量級的訊息系統，專門為高吞吐量/低延遲的場景開發，在金融界的應用中經常可以發現它。與RabbitMQ相比，ZeroMQ支援許多高階訊息場景，但是你必須實現ZeroMQ框架中的各個塊（比如Socket或Device等）。
ZeroMQ架構圖如圖7-1所示：
圖7-1 ZeroMQ架構圖
ZeroMQ優點：
(1).簡單，僅僅提供24個API介面，風格類似於BSDSocket。處理了網路異常，包括連線異常中斷、重連等。改變TCP基於位元組流收發資料的方式，處理了粘包、半包等問題，以msg為單位收發資料，結合Protocol Buffers，可以對應用層徹底遮蔽網路通訊層。對大資料通過SENDMORE/RECVMORE提供分包收發機制。通過執行緒間資料流動來保證同一時刻任何資料都只會被一個執行緒持有，以此實現多執行緒的“去鎖化”。通過高水位HWM來控制流量，用交換SWAP來轉儲記憶體資料，彌補HWM丟失資料的缺陷。伺服器端和客戶端的啟動沒有先後順序。
(2).靈活，支援多種通訊協議，可以靈活地適應多種通訊環境，包括程序內、程序間、機器間、廣播。支援多種訊息模型，訊息模型之間可以相互組合，形成特定的解決方案。
(3).跨平臺，支援Linux、Windows、OS X等。
(4).多語言，可以繫結C、C++、Java、.NET、Python等30多種開發語言。
(5).高效能，相對同類產品，效能卓越。
ZeroMQ缺點：
(1). 過高的效率會造成可靠性下降，偶然會丟失某些訊息的現象。
下圖是來自於Internet的效能測試資料。顯示的是每秒鐘傳送和接受的訊息數。整個過程共產生1百萬條1K的訊息，測試環境為Windows 。從測試資料可以看出，ZeroMQ的效能遠遠高於其它3個MQ。
但是測試資料僅供參考，因為缺少必須的環境引數和效能指標，比如：CPU引數、記憶體引數、訊息模型、通訊協議、極限時消耗CPU百分比、極限時消耗記憶體百分比等。大家可做參考：
圖7-2 中介軟體效能分析圖
8. KAFKA：
Kafka是Apache下的一個子專案，是一個高效能跨語言分散式Publish/Subscribe訊息佇列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行訊息持久化；高吞吐，在一臺普通的伺服器上既可以達到10W/s的吞吐速率；完全的分散式系統，Broker、Producer、Consumer都原生自動支援分散式，自動實現複雜均衡；支援Hadoop資料並行載入，對於像Hadoop的一樣的日誌資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的並行載入機制來統一了線上和離線的訊息處理，這一點也是本課題所研究系統所看重的。Apache Kafka相對於ActiveMQ是一個非常輕量級的訊息系統，除了效能非常好之外，還是一個工作良好的分散式系統。Apache Kafka架構圖如下圖所示：
圖8-1 Apache Kafka架構圖
Kafka優點：
(1).通過O(1)的磁碟資料結構提供訊息的持久化，這種結構對於即使數以TB的訊息儲存也能夠保持長時間的穩定效能。
(2).高吞吐量：即使是非常普通的硬體kafka也可以支援每秒數十萬的訊息，適合產生大量資料的網際網路服務的資料收集業務。
(3).支援通過kafka伺服器和消費機叢集來分割槽訊息。
(4).支援Hadoop並行資料載入。
具體部署參考：http://blog.csdn.net/fanyun_01/article/details/52159684
http://blog.csdn.net/fanyun_01/article/details/52159674
國內中介軟體發展：
Notify是淘寶自主研發的一套訊息服務引擎，是支撐雙11最為核心的系統之一，在淘寶和支付寶的核心交易場景中都有大量使用。訊息系統的核心作用就是三點：解耦，非同步和並行。通過訊息中介軟體，應用程式或元件之間可以進行可靠的非同步通訊來降低系統之間的耦合度，從而提高整個系統的可擴充套件性和可用性。
以下連結是淘寶的一個經典中介軟體，大家可以參考學習下！
（詳細見 http://www.tuicool.com/articles/AfQRru）
本人水平有限，文章中可能存在錯誤和不足，歡迎批評指正。