ActiveMQ

　　單機吞吐量：萬級

　　topic數量都吞吐量的影響：

　　時效性：ms級

　　可用性：高，基於主從架構實現高可用性

　　訊息可靠性：有較低的概率丟失資料

　　功能支援：MQ領域的功能極其完備

　　總結：

　　　　非常成熟，功能強大，在早些年業內大量的公司以及專案中都有應用  

　　　　偶爾會有較低概率丟失訊息  

　　　　現在社群以及國內應用都越來越少，官方社群現在對ActiveMQ 5.x維護越來越少，幾個月才釋出一個版本   

　　　　主要是基於解耦和非同步來用的，較少在大規模吞吐的場景中使用

RabbitMQ

　　單機吞吐量：萬級

　　topic數量都吞吐量的影響：

　　時效性：微秒級，延時低是一大特點。

　　可用性：高，基於主從架構實現高可用性

　　訊息可靠性：

　　功能支援：基於erlang開發，所以併發能力很強，效能極其好，延時很低

　　總結：　　

　　　　erlang語言開發，效能極其好，延時很低；  

　　　　吞吐量到萬級，MQ功能比較完備  

　　　　開源提供的管理介面非常棒，用起來很好用  

　　　　社群相對比較活躍，幾乎每個月都發布幾個版本分  

　　　　在國內一些網際網路公司近幾年用rabbitmq也比較多一些   但是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是因為他做的實現機制比較重。  

　　　　erlang開發，很難去看懂原始碼，基本職能依賴於開源社群的快速維護和修復bug。  

　　　　rabbitmq叢集動態擴充套件會很麻煩，不過這個我覺得還好。其實主要是erlang語言本身帶來的問題。很難讀原始碼，很難定製和掌控。

RocketMQ

　　單機吞吐量：十萬級

　　topic數量都吞吐量的影響：topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降。可支援大量topic是一大優勢。

　　時效性：ms級

　　可用性：非常高，分散式架構

　　訊息可靠性：經過引數優化配置，訊息可以做到0丟失

　　功能支援：MQ功能較為完善，還是分散式的，擴充套件性好

　　總結：

　　　　介面簡單易用，可以做到大規模吞吐，效能也非常好，分散式擴充套件也很方便，社群維護還可以，可靠性和可用性都是ok的，還可以支撐大規模的topic數量，支援複雜MQ業務場景  

　　　　而且一個很大的優勢在於，原始碼是java，我們可以自己閱讀原始碼，定製自己公司的MQ，可以掌控  

　　　　社群活躍度相對較為一般，不過也還可以，文件相對來說簡單一些，然後介面這塊不是按照標準JMS規範走的有些系統要遷移需要修改大量程式碼  

Kafka

　　單機吞吐量：十萬級，最大的優點，就是吞吐量高。

　　topic數量都吞吐量的影響：topic從幾十個到幾百個的時候，吞吐量會大幅度下降。所以在同等機器下，kafka儘量保證topic數量不要過多。如果要支撐大規模topic，需要增加更多的機器資源

　　時效性：ms級

　　可用性：非常高，kafka是分散式的，一個數據多個副本，少數機器宕機，不會丟失資料，不會導致不可用

　　訊息可靠性：經過引數優化配置，訊息可以做到0丟失

　　功能支援：功能較為簡單，主要支援簡單的MQ功能，在大資料領域的實時計算以及日誌採集被大規模使用

　　總結：

　　　　kafka的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，而且分散式可以任意擴充套件  

　　　　同時kafka最好是支撐較少的topic數量即可，保證其超高吞吐量  

　　　　kafka唯一的一點劣勢是有可能訊息重複消費，那麼對資料準確性會造成極其輕微的影響，在大資料領域中以及日誌採集中，這點輕微影響可以忽略

最後

　　一般的業務系統要引入MQ，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社群也不是很活躍

　　後來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的java工程師去深入研究和掌控他，對公司而言，幾乎處於不可控的狀態，但是確實人家是開源的，比較穩定的支援，活躍度也高；

　　不過現在確實越來越多的公司，會去用RocketMQ，確實很不錯，但是要想好社群萬一突然黃掉的風險

　　所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇

　　如果是大資料領域的實時計算、日誌採集等場景，用Kafka是業內標準的，絕對沒問題，社群活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範