一、消息隊列使用場景
1. 異步處理
傳統業務並行處理：
消息隊列進行處理：
2. 應用解耦
傳統業務調用，耦合性太高。
采用消息隊列進行處理， 降低耦合性。
3. 流量削峰
每天0點到11點，A系統風平浪靜，每秒並發請求數量就100個。結果每次一到11點~1點，每秒並發請求數量突然會暴增到1萬條。但是系統最大的處理能力就只能是每秒鍾處理1000個請求啊，導致系統崩潰。
4. 消息通訊
消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。
5. 日志處理
日志處理是指將消息隊列用在日志處理中，比如Kafka的應用，解決大量日志傳輸的問題。架構簡化如下
二、消息隊列缺點
系統可用性降低：系統引入的外部依賴越多，越容易掛掉，本來你就是A系統調用BCD三個系統的接口就好了，人ABCD四個系統好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整？MQ掛了，整套系統崩潰了，你不就完了么。
系統復雜性提高：硬生生加個MQ進來，你怎么保證消息沒有重復消費？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已
一致性問題：A系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統那里，BD兩個系統寫庫成功了，結果C系統寫庫失敗了，咋整？你這數據就不一致了。
二、RobbitMQ、RocketMQ、Kafak對比
| 特性 |
ActiveMQ |
RabbitMQ |
RocketMQ |
Kafka |
| 單機吞吐量 |
萬級，吞吐量比RocketMQ和Kafka要低了一個數量級 |
萬級，吞吐量比RocketMQ和Kafka要低了一個數量級 |
10萬級，RocketMQ也是可以支撐高吞吐的一種MQ |
10萬級別，這是kafka最大的優點，就是吞吐量高。
一般配合大數據類的系統來進行實時數據計算、日志采集等場景 |
| topic數量對吞吐量的影響 |
|
|
topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降
這是RocketMQ的一大優勢，在同等機器下，可以支撐大量的topic |
topic從幾十個到幾百個的時候，吞吐量會大幅度下降
所以在同等機器下，kafka盡量保證topic數量不要過多。如果要支撐大規模topic，需要增加更多的機器資源 |
| 時效性 |
ms級 |
微秒級，這是rabbitmq的一大特點，延遲是最低的 |
ms級 |
延遲在ms級以內 |
| 可用性 |
高，基於主從架構實現高可用性 |
高，基於主從架構實現高可用性 |
非常高，分布式架構 |
非常高，kafka是分布式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 消息可靠性 |
有較低的概率丟失數據 |
|
經過參數優化配置，可以做到0丟失 |
經過參數優化配置，消息可以做到0丟失 |
| 功能支持 |
MQ領域的功能極其完備 |
基於erlang開發，所以並發能力很強，性能極其好，延時很低 |
MQ功能較為完善，還是分布式的，擴展性好 |
功能較為簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日志采集被大規模使用，是事實上的標准 |
| 優劣勢總結 |
非常成熟，功能強大，在業內大量的公司以及項目中都有應用
偶爾會有較低概率丟失消息
而且現在社區以及國內應用都越來越少，官方社區現在對ActiveMQ 5.x維護越來越少，幾個月才發布一個版本
而且確實主要是基於解耦和異步來用的，較少在大規模吞吐的場景中使用
|
erlang語言開發，性能極其好，延時很低；
吞吐量到萬級，MQ功能比較完備
而且開源提供的管理界面非常棒，用起來很好用
社區相對比較活躍，幾乎每個月都發布幾個版本分
在國內一些互聯網公司近幾年用rabbitmq也比較多一些
但是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是因為他做的實現機制比較重。
而且erlang開發，國內有幾個公司有實力做erlang源碼級別的研究和定制？如果說你沒這個實力的話，確實偶爾會有一些問題，你很難去看懂源碼，你公司對這個東西的掌控很弱，基本職能依賴於開源社區的快速維護和修復bug。
而且rabbitmq集群動態擴展會很麻煩，不過這個我覺得還好。其實主要是erlang語言本身帶來的問題。很難讀源碼，很難定制和掌控。 |
接口簡單易用，而且畢竟在阿里大規模應用過，有阿里品牌保障
日處理消息上百億之多，可以做到大規模吞吐，性能也非常好，分布式擴展也很方便，社區維護還可以，可靠性和可用性都是ok的，還可以支撐大規模的topic數量，支持復雜MQ業務場景
而且一個很大的優勢在於，阿里出品都是java系的，我們可以自己閱讀源碼，定制自己公司的MQ，可以掌控
社區活躍度相對較為一般，不過也還可以，文檔相對來說簡單一些，然后接口這塊不是按照標准JMS規范走的有些系統要遷移需要修改大量代碼
還有就是阿里出台的技術，你得做好這個技術萬一被拋棄，社區黃掉的風險，那如果你們公司有技術實力我覺得用RocketMQ挺好的 |
kafka的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，而且分布式可以任意擴展
同時kafka最好是支撐較少的topic數量即可，保證其超高吞吐量
而且kafka唯一的一點劣勢是有可能消息重復消費，那么對數據准確性會造成極其輕微的影響，在大數據領域中以及日志采集中，這點輕微影響可以忽略
這個特性天然適合大數據實時計算以及日志收集 |
總結：
RabbitMQ：性能好，延時低，管理界面好用，社區活躍。但是吞吐量比較低，erlang語言實現，不好進行進一步開發擴展。
RocketMQ：接口簡單易用，源碼是阿里出品，可自定義MQ。但是社區活躍度一般，萬一不維護，需要自己公司研發。
Kafka：僅僅提供較少的核心功能，但是具備超高的吞吐量和ms級的延遲，極高的可用性和拓展性。但是存在消息重復消費的缺點，適合於大數據實時計算和日志收集。