中間件技術選型

常用的 MQ組件有 ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ、MetaMQ，Kafka，當然 Kafka的功能更加強大，雖然不同的 MQ都有自己的特點和優勢，但是，不管是哪種MQ，都有 MQ本身自帶的一些特點，下面，介紹 MQ的特點，

中間件選型

Kafka

Kafka是 LinkedIn開源的分布式發布-訂閱訊息系統，目前歸屬于 Apache頂級專案，Kafka主要特點是基于 Pull的模式來處理訊息，訊息有序，通過控制能夠保證所有訊息被消費且僅被消費一次，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，支持復制、事務，對訊息的重復、丟失、錯誤沒有嚴格要求，適合產生大量資料的互聯網服務的資料收集業務，完全的分布式系統，Broker、Producer、Consumer都原生自動支持分布式，自動實作負載均衡，支持 Hadoop資料并行加載，對于像Hadoop的一樣的日志資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案，Kafka通過 Hadoop的并行加載機制來統一了在線和離線的訊息處理，這一點也是本課題所研究系統所看重的，Apache Kafka相對于 ActiveMQ是一個非常輕量級的訊息系統，除了性能非常好之外，還是一個作業良好的分布式系統，詳細博文鏈接

號稱大資料的殺手锏，談到大資料領域內的訊息傳輸，則繞不開Kafka，這款為大資料而生的訊息中間件，以其百萬級TPS（單機寫入TPS約在百萬條/秒）的吞吐量名聲大噪，迅速成為大資料領域的寵兒，在資料采集、傳輸、存盤的程序中發揮著舉足輕重的作用，可用性非常高，kafka是分布式的，一個資料多個副本，少數機器宕機，不會丟失資料，不會導致不可用，有優秀的第三方 Kafka Web管理界面 Kafka-Manager，

缺點：① Kafka單機超過 64個佇列/磁區，Load會發生明顯的飆高現象，佇列越多，load越高，發送訊息回應時間變長，② 使用短輪詢方式，實時性取決于輪詢間隔時間，③ 消費失敗不支持重試， ④ 支持訊息順序，但是一臺代理宕機后，就會產生訊息亂序，⑤ 社區更新較慢，

RabbitMQ

RabbitMQ是使用 Erlang語言開發的開源訊息佇列系統，支持很多的協議 AMQP，XMPP，SMTP，STOMP協議，AMQP的主要特征是面向訊息、佇列、路由（包括點對點和發布/訂閱）、可靠性、安全，AMQP協議使的它變的非常重量級，更適合于企業級的開發，對路由(Routing)，負載均衡(Load balance)、資料一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次，健壯、穩定、易用、跨平臺、支持多種語言、檔案齊全，開源提供的管理界面非常棒，用起來很好用，社區活躍度高，詳細博文鏈接

缺點：① Erlang開發，很難去看懂原始碼，基本職能依賴于開源社區的快速維護和修復bug，不利于做二次開發和維護，② RabbitMQ確實吞吐量會低一些，這是因為他做的實作機制比較重，③ 需要學習比較復雜的介面和協議，學習和維護成本較高，

RocketMQ

RocketMQ是阿里開源的訊息中間件，它是純 Java開發，具有高吞吐量、高可用性、適合大規模分布式系統應用的特點，RocketMQ思路起源于 Kafka，并做出了自己的一些改進，它對訊息的可靠傳輸及事務性做了優化，目前在阿里集團被廣泛應用于交易、充值、流計算、訊息推送、日志流式處理、binglog分發等場景，訊息可靠性非常高，經過引數優化配置，訊息可以做到0丟失，MQ功能較為完善，還是分布式的，擴展性好，支持10億級別的訊息堆積，不會因為堆積導致性能下降，原始碼是 Java，我們可以自己閱讀原始碼，定制自己公司的MQ，可以掌控，

天生為金融互聯網領域而生，對于可靠性要求很高的場景，尤其是電商里面的訂單扣款，以及業務削峰，在大量交易涌入時，后端可能無法及時處理的情況，RoketMQ在穩定性上可能更值得信賴，這些業務場景在阿里雙11已經經歷了多次考驗，如果你的業務有上述并發場景，建議可以選擇RocketMQ，

缺點：① 支持的客戶端語言不多，目前是 java及c++，其中 c++不成熟，② 社區活躍度一般， ③ 沒有在 MQ核心中去實作 JMS等介面，有些系統要遷移需要修改大量代碼，

ZeroMQ

號稱最快的訊息佇列系統，尤其針對大吞吐量的需求場景，ZMQ能夠實作 RabbitMQ不擅長的高級/復雜的佇列，但是開發人員需要自己組合多種技術框架，技術上的復雜度是對這 MQ能夠應用成功的挑戰，ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個訊息服務器或中間件，因為你的應用程式將扮演了這個服務角色，你只需要簡單的參考 ZeroMQ程式庫，可以使用 NuGet安裝，然后你就可以愉快的在應用程式之間發送訊息了，但是 ZeroMQ僅提供非持久性的佇列，也就是說如果 down機，資料將會丟失，其中，Twitter的 Storm中使用 ZeroMQ作為資料流的傳輸，

ActiveMQ

Apache ActiveMQ速度快，支持許多跨語言客戶端和協議，帶有易于使用的企業集成模式和許多高級功能，同時完全支持JMS 1.1和J2EE 1.4，Apache ActiveMQ是在 Apache 2.0許可下發布，有較低的概率丟失資料，詳細博文鏈接

缺點：官方社區現在對 ActiveMQ 5.x維護越來越少，較少在大規模吞吐的場景中使用，

Redis

是一個 Key-Value的 NoSQL資料庫，開發維護很活躍，雖然它是一個 Key-Value資料庫存盤系統，但它本身支持 MQ功能，所以完全可以當做一個輕量級的佇列服務來使用，對于 RabbitMQ和 Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間，測驗資料分為128Bytes、512Bytes、1K和10K四個不同大小的資料，實驗表明：入隊時，當資料比較小時 Redis的性能要高于 RabbitMQ，而如果資料大小超過了10K，Redis則慢的無法忍受；出隊時，無論資料大小，Redis都表現出非常好的性能，而 RabbitMQ的出隊性能則遠低于 Redis，

壓力測驗

對比Kafka、RabbitMQ、RocketMQ發送訊息(124位元組)的性能，壓測我們只關注服務端的性能指標，所以壓測的標準是不斷增加發送端的壓力，直到系統吞吐量不再上升，而回應時間拉長，這時服務端已出現性能瓶頸，可以獲得相應的系統最佳吞吐量，在同步發送場景中，三個訊息中間件的表現區分明顯：

Kafka

Kafka 的吞吐量高達17.3w/s，是高吞吐量訊息中間件的行業老大，這主要取決于它的佇列模式保證了寫磁盤的程序是線性IO，此時 Broker磁盤IO已達瓶頸，

RocketMQ

RocketMQ也表現不俗，吞吐量在 11.6w/s，磁盤IO已接近100%，RocketMQ的訊息寫入記憶體后即回傳ack，由單獨的執行緒專門做刷盤的操作，所有的訊息均是順序寫檔案，

RabbitMQ

RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高，它支持 AMQP協議，實作非常重量級，為了保證訊息的可靠性在吞吐量上做了取舍，我們還做了 RabbitMQ在訊息持久化場景下的性能測驗，吞吐量在 2.6w/s左右，

測驗結論：同步發送的性能上 Kafka>RocketMQ>RabbitMQ

在架構模型方面

RabbitMQ

RabbitMQ遵循 AMQP協議，RabbitMQ的 Broker由 Exchange，Binding，Queue組成，其中 Exchange和 Binding組成了訊息的路由鍵，客戶端 Producer通過連接 Channel和 Server進行通信，Consumer從 Queue獲取訊息進行消費（長連接，Queue有訊息會推送到 Consumer端，Consumer回圈從輸入流讀取資料），RabbitMQ以 Broker為中心，有訊息的確認機制，

Kafka

Kafka遵從一般的 MQ結構，Producer，Broker，Consumer，以 Consumer為中心，訊息的消費資訊保存的客戶端 Consumer上，Consumer根據消費的點，從 Broker上批量 pull資料，無訊息確認機制，

在吞吐量

Kafka

Kafka具有高的吞吐量，內部采用訊息的批量處理，zero-copy機制，資料的存盤和獲取是本地磁盤順序批量操作，具有 O(1)的復雜度，訊息處理的效率很高，

RabbitMQ

RabbitMQ在吞吐量方面稍遜于 Kafka，他們的出發點不一樣，RabbitMQ支持對訊息的可靠的傳遞，支持事務，不支持批量的操作，基于可靠存盤的要求，存盤可以采用記憶體或者硬碟，

在可用性方面

RabbitMQ

RabbitMQ支持 miror的 queue，主 queue失效，miror queue接管，

Kafka

Kafka的 Broker支持主備模式，

在集群負載均衡方面

Kafka

Kafka采用 Zookeeper對集群中的 Broker、Consumer進行管理，可以注冊 Topic到 Zookeeper上，通過 Zookeeper的協調機制，Producer保存對應 Topic的 Broker資訊，可以隨機或者輪詢發送到 Broker上，并且Producer可以基于語意指定分片，訊息發送到 Broker的某分片上，

RabbitMQ

RabbitMQ的負載均衡需要單獨的 loadbalancer進行支持，

總結

Rabbitmq 比 Kafka可靠，Kafka更適合 IO高吞吐的處理，比如 ELK日志收集

Kafka 和 RabbitMq都是以分布式部署為目的，但是他們對訊息語意模型的定義的假設是非常不同的，我對"AMQP 更成熟"這個論點是持懷疑態度的，讓我們用事實說話來看看用什么解決方案來解決你的問題，
【1】以下場景比較適合使用 Kafka，你有大量的事件(10萬以上/秒)、你需要以磁區的，順序的，至少傳遞成功一次到混雜了在線和打包消費的消費者、你希望能重讀訊息、你能接受目前是有限的節點級別高可用或者說你并不介意通過論壇/IRC工具得到還在幼兒階段的軟體的支持，
【2】以下場景你比較適合使用 RabbitMQ，你有較少的事件（2萬以上/秒）并且需要通過復雜的路由邏輯去找到消費者、你希望訊息傳遞是可靠的、你并不關心訊息傳遞的順序、你需要現在就支持集群-節點級別的高可用或則說你需要7*24小時的付費支持（當然也可以通過論壇/IRC工具），