MQ應用場景分析

MQ對比文檔

MQ主要做用

1.解耦

每一個成員沒必要受其餘成員的影響，一個大的系統拆分爲多個子系統，子系統中間利用mq進行通訊，共享數據就是接耦的一種表現

2.異步通訊

有些業務不想也不須要當即處理消息。消息隊列提供了異步處理機制，容許用戶把一個消息放入隊列，但並不當即處理它。想向隊列中放入多少消息就放多少，而後在須要的時候再去處理它們。

2.削峯

利用消息中間件，不管前面壓力又多大，對後端系統來講，都是一個有序的過程，減小後端系統瞬時壓力

3.消息廣播

這是MQ自帶的特性，進行消息的發送，消息有隊列和廣播模式，根據業務需求自行選擇

MQ系統特性

• 提供豐富的消息訂閱模式，
• 消息持久化以及可靠傳輸
• 消息重發機制
• 支持的隊列數量
• 事務消息
• 順序消息
• 消息堆積能力
• 消息消費模式
• 消息過濾
• 消息丟失
• 定時消息
• 可用性
• 併發性
• 容災機制
• 單機吞吐量
• 負載均衡
• 可維護性
• 可擴展性

MQ對比

特性	ActiveMq	RabbitMq	Rocketmq	kafka
開發語言	java	erlang	java	Scala
消息訂閱模式	完美支持JMS規範，支持訂閱和廣播模式	支持訂閱廣播模式	支持訂閱廣播模式	支持訂閱廣播模式
消息持久化	內存、文件、數據庫	內存、文件	磁盤文件	磁盤文件
消息重發機制	支持	支持	支持	不支持
支持隊列數量	大數量隊列，mq會出問題	支持大數量隊列	支持很大數量隊列	支持大數量隊列
事務消息	支持	支持	支持	不支持
順序消息	支持（實現比較麻煩）	支持	支持嚴格的順序消息，即便down機也不會亂序	支持
消息堆積能力	通常	通常	億級消息堆積能力	億級消息堆積能力
消息消費模式	廣播、集羣	廣播、集羣	廣播、集羣、回溯消費	極高
消息過濾	支持	不	支持客戶端過濾和服務端過濾模式	不支持
消息丟失	低	低	理論上不會丟失	理論上不會丟失
定時消息	支持	支持	支持	不支持
可用性	高(主從)	高（主從）	極高（分佈式）	極高（分佈式）
併發性	高	極高	高	高
容災機制	高	極高	極高	極高
單機吞吐量	萬級	萬級	萬級	十萬級
負載均衡	通常	極高	極高	極高
可維護性	高	高	高	高
可擴展性	通常	集羣不支持動態擴展	集羣支持動態擴展	支持動態擴展

ActiveMq是根據標準JMS規範實現的，採用JAVA編寫，項目比較成熟。 Rabbitmq是erlang開發，所以他的併發性極高，要優於其餘MQ，可是也是因爲erlang語言的特性，集羣不支持動態擴展。 Rocketmq是基於JAVA開發，在設計初衷，借鑑JMS和COBAR Notification規範。並且rocketmq裏面的部署都是分佈式，提供了同步雙寫，異步刷盤等多種存儲策略，同時採用零拷貝技術，因此在兼顧數據一致性、可用性的時候他的吞吐量極高。 Kafak因爲在實現上並無實現不少MQ的特性，因此他的性能比較優越，同時採用零拷貝技術，他的吞吐量能夠說是業界目前最高的。

綜上所述： MQ沒有好壞之分，只有合適的應用場景合適的MQ 。 針對通常的業務場景，併發量不是太大，AMQ足以 。 針對注重數據一致性、可用性和穩定性比較高，可是吞吐量不怎麼關心的時候能夠採用Rabbitmq 。 針對流計算、日誌、大數據方面的採用 Kafak 針對即注重數據一致性、穩定性、可用性的，又關心吞吐量的能夠採用Rocketmq。