**1.ZeroMQ** 號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。 擴展性好，開發比較靈活，采用C語言實現，實際上只是一個socket庫的重新封裝，如果做為消息隊列使用，需要開發大量的代碼。ZeroMQ僅提供非持久性的隊列，也就是說如果down機，數據將會丟失；**Twitter的Storm中使用ZeroMQ作為數據流的傳輸** **2.RabbitMQ** 結合erlang語言本身的并發優勢，支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合于企業級的開發。 性能較好，但是不利于做二次開發和維護 **3.ActiveMQ** 歷史悠久的開源項目，是Apache下的一個子項目。已經在很多產品中得到應用，實現了JMS1.1規范，可以和spring-jms輕松融合，實現了多種協議，不夠輕巧（源代碼比RocketMQ多），支持持久化到數據庫，對隊列數較多的情況支持不好 **4.Kafka/Jafka** Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發布/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。 具有以下特性： * 快速持久化，可以在O(1)的系統開銷下進行消息持久化； * 高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分布式系統，Broker、Producer、Consumer都原生自動支持分布式，自動實現負載均衡； * 支持Hadoop數據并行加載，對于像Hadoop的一樣的日志數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。 Kafka通過Hadoop的并行加載機制統一了在線和離線的消息處理。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分布式系統 ### 當前主流MQ比較 | | kafka | RocketMQ | RabbitMQ | | --- | --- | --- | --- | | 設計定位 |系統間的數據流管道，實時數據處理，例如常規的消息系統，監控數據日志的收集處理 | 非日志消息的可靠傳輸，例如訂單、交易、充值、消息推送等 | 可靠消息傳輸，和RocketMQ類似 | | 成熟度 | 成熟 | 成熟 | 成熟 | | 社區/公司 |apache |alibaba/已捐獻給apache | | | 社區活躍度 | 高 | 中 | 高 | | 文檔 | 完備 | 完備 | 完備 | |開發語言 | scala | java | erlang | | 協議 |自定義基于TCP的二進制協議 |自定義 |AMQP | | 多語言支持 |c/c++/python/go/erlang/.net/Ruby/node/java/php | java |java/c/c++/python/php/perl | |持久化方式 |磁盤文件 |磁盤文件 |內存/文件 | |部署方式 |單機/集群 |單機/集群 | 單機/集群 | |集群管理 |zookeeper | name server | | |選主方式 |從ISR中自動選舉一個Leader |不支持自動選主 |最早加入集群的Broker | |主從切換 |自動切換 |不支持自動切換 | 自動切換 | |數據可靠性 |支持producer單條發送/同步刷盤/同步復制 |單條發送/同步刷盤/異步刷盤/同步雙寫/異步復制 | | |堆積能力 | 非常好，消息存儲在log，每個分區一個Log | 非常好，消息存儲在同一個commitlog |一般 | |消息過濾 |不支持 | 支持 | 不支持 | | 消息重試 |不支持 | 支持 |支持 | | 消費方式 |consumer pull | consumer pull/ broker push | broker push | | 部署依賴 |zookeeper | name server | erlang環境 | | 管理后臺 |官方不提供 | rocketmq-console |rabbitmqadmin | |優點 |1.高吞吐、低延遲、高可用、集群熱擴展、集群容錯；<br>2.支持多語言客戶端；<br>3.生態完善，在大數據處理方面有大量配套設施 |1.高吞吐、低延遲、高可用，消息堆積時性能也很好；<br>2.系統設計更加適合業務處理場景；<br>3.支持多種消費方式；<br>4.支持broker消息過濾；<br>5.支持事務；<br>6.支持順序消息；<br>7.集群規模50臺左右，單日處理消息上百億，經歷過大數量驗證，比較可靠穩定 | 1.高吞吐、高可用不如前兩者；<br>2.支持多語言客戶端；支持AMQP協議；<br>3.由于erlang語言的特性，性能較好；互聯網公司有大規模應用 | |缺點 | 1.消費集群數目受到分區數目限制；<br>2.單機topic多時性能明顯降低；<br>3.不支持事務 |1.相比于Kafka使用者較少，生態不夠完善；消息堆積、吞吐率也有所不如；<br>2.不支持主從自動切換，master失效后，consumer需要一定時間才能感知(30s)；<br>3.客戶端只支持JAVA |1.erlang語言難度較大，集群不支持動態擴展；<br>2.不支持事務、消息吞吐能力有限；<br>3.消息堆積時性能明顯降低 |