MQ稱爲Message Queue 解決項目之間的耦合問題 解決A和B項目之間的通信
主流MQ對比：Kafka、RocketMq、RabbitMq
Kafka：Apache下的子項目，使用scala實現的一個高性能分佈式Publish/Subscribe消息隊列系統（用於日誌領域）
- 快速持久化：通過磁盤順序讀寫與零拷貝機制，可以在O(1)的系統開銷下消息持久化
- 高吞吐：在一臺普通服務器上既可以達到10w/s的吞吐速率
- 高堆積：支持topic下消費者較長時間離校，消息堆積量大
- 完全的分佈式系統：Broker、Producer、Consumer都原生自動支持分佈式，依賴zookeeper自動實現負載均衡
- 支持Hadoop數據並行加載：對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案
RocketMq：前身是Metaq，發佈3.0時改名爲RocketMq。RocketMq是一款分佈式、隊列模型的消息中間件（正常業務）
- 能夠保證嚴格的消息順序
- 提供豐富的消息拉取模式
- 高效的訂閱者水平擴展能力
- 實時的消息訂閱機制
- 支持事物消息
- 億級消息堆積能力比kafka低一點點
RabbitMq：使用Erlang編寫的開源的消息隊列，本身支持很多的協議：AMQP，XMPP，SMTP，STOMP，使它變的非常重量級，適合於企業級的開發
- 路由（Routing）
- 負載均衡（Load balance）
- 數據持久化
|
Kafka |
RocketMq |
RabbitMq |
|
|
設計定位 |
系統間的數據流管道，實時數據處理 例如：常規的消息系統、網站活躍性跟蹤、監控數據、日誌收集
|
非日誌的可靠消息傳輸 例如：訂單，交易，充值，流計算，消息推送，binlog分發
|
可靠消息傳輸和RocketMq類似
|
|
所屬社區 |
Apache |
Alibaba開發，假如Apache下 |
Mozilla Public License |
|
開發語言 |
Scala |
Java |
Erlang |
|
支出協議 |
一套自行設計的基於TCP的二進制協議 |
自定義的一套 |
AMQP
|
|
客戶端語言 |
C/C++、Python、Go、Erlang、Ruby、Node.js、Java、PHP等 |
Java |
Java、C/C++、Python、PHP |
|
持久化方式 |
磁盤文件 |
磁盤文件 |
內存、文件 |
|
部署方式 |
單機/集羣 |
單機/集羣 |
單機/集羣 |
|
集羣管理 |
zookeeper |
name server |
|
|
選主方式 |
從ISR中自動選舉一個leader |
不支持自動選主。通過設定brokername、brokerid實現，brokername相同，brokerid=0時爲master其他爲slave |
最早入集羣的broker |
|
可用性 |
非常高 分佈式、主從 |
非常高 分佈式、主從 |
高 主從，採用鏡像模式實現，數據最大時可能產生性能瓶頸
|
|
主從切換 |
自動切換 N個副本，允許N-1個失效；master失效以後自動從ISR中選擇一個主 |
不支持自動切換 master失效以後不能向master發送消息，consumer大概30s可以感知此事件，此後從slave消費；如果master無法恢復，異步複製此時可能出現部分信息丟失 |
自動切換 最早加入集羣的slave會成爲master；因爲新加入的slave不會同步master之前的數據，所以可能回出現部分數據丟失 |
|
數據可靠性 |
很好 支持producer單條發送、異步刷盤、同步複製，但這種場景下性能明顯下降 |
很好 producer單條發送，broker端支持同步刷盤，同步雙寫，異步複製 |
好 producer支持同步/異步ack,支持隊列數據持久化，鏡像模式中支持主從同步 |
|
消息寫入性能 |
非常好 每條10個字節測試：百萬條/s |
很好 每條10個字節測試：單機單broker越7w/s，單機3broker約12w/s |
RAM約爲RocketMq的1/2 Disk的性能爲RAM性能的1/3 |
|
定時消息 |
開源版本僅支持定時Level |
||
|
事務消息 |
不支持 |
支持 |
不支持 |
|
消息查詢 |
不支持 |
根據MessageId查詢 |
不支持 |
|
優點 |
1、高吞吐、低延遲、高可用、集羣熱擴展、集羣容錯上變現非常好 2、producer端提供緩存、壓縮功能，可節省性能，提高效率 3、提供順序消費能力 4、提供多種客戶端語言 5、生態完善，在大數據處理方面 有大量配套設施 |
1、高吞吐、低延遲、高可用、消息堆積、性能很好 2、api、系統設計更下適合在業務處理場景 3、支持多種消費方式 4、支持broker消息過濾 5.支持事物 6、提供消息順序消費能力；consumer可以水平擴展，消費能力很強 7、集羣規模在50臺左右，單日處理消息上百億；經歷過大數據量的考驗，比較穩定可靠 |
1、在高吞吐量、高可用上前兩者都有所不如 2、支持多客戶端語言；支持amqp協議 3、由於erlange語言特性，性能比較好，使用RAM模式時，性能很好 4、管理界面非常豐富 |
|
缺點 |
1、消費集羣數目受到分區數目限制 2、單機topic多時，性能會明顯降低 3、不支持事務 |
1、相比於kafka，消息推擠、吞吐率也有所哺乳 2、不支持主從自動切換，master失效後，消費者要一定的時間才能感知 3、客戶端只支持java |
1、erlang語言難度較大，集羣不支持動態擴展 2、不支持事務、消息吞吐能力有限 3、消息堆積時，性能會明顯下降 |