消息隊列已經(jīng)逐漸成為企業(yè)IT系統(tǒng)內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一。當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發(fā)RocketMQ等。RabbitMQ比Kafka成熟，在可用性上，可靠性上，穩(wěn)定性上，RabbitMQ理論上勝于Kafka，由于Kafka設計初衷是處理日志，可以看做是日志（消息）系統(tǒng)一個重要組件，針對性很強，雖然吞吐量遠高于RabbitMQ，但從業(yè)務方面考慮還是建議選擇RabbitMQ。

消息隊列已經(jīng)逐漸成為企業(yè)IT系統(tǒng)內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一。當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發(fā)RocketMQ等。

主流消息中間件比較：

對比之總結如下：

一般的業(yè)務系統(tǒng)要引入MQ，最早大家都用ActiveMQ，但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證，社區(qū)也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；

后來大家開始用RabbitMQ，但是Erlang語言阻止了大量java工程師去深入研究它，對公司而言，幾乎處于不可控的狀態(tài)，但是開源，穩(wěn)定，活躍度依然很高；

現(xiàn)在確實越來越多的公司，會去用RocketMQ，確實很不錯，但是我提醒一下自己想好社區(qū)萬一突然黃掉的風險，對自己公司技術實力有絕對自信的，我推薦用RocketMQ，否則回去老老實實用RabbitMQ吧，活躍開源社區(qū)，絕對不會黃，所以中小型公司，技術實力較為一般，技術挑戰(zhàn)不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發(fā)實力較強，用RocketMQ是很好的選擇；

如果是大數(shù)據(jù)領域的實時計算、日志采集等場景，用Kafka是業(yè)內標準的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規(guī)范。

RabbitMQ比Kafka成熟，在可用性上，可靠性上，穩(wěn)定性上，RabbitMQ理論上勝于Kafka，由于Kafka設計初衷是處理日志，可以看做是日志（消息）系統(tǒng)一個重要組件，針對性很強，雖然吞吐量遠高于RabbitMQ，但從業(yè)務方面考慮還是建議選擇RabbitMQ。

參考資料：

https://blog.csdn.net/leexide/article/details/80035462

https://blog.csdn.net/luckyzhoustar/article/details/50411500

https://blog.csdn.net/java_zyq/article/details/80022391

https://blog.csdn.net/kingmax54212008/article/details/51706128

https://www.jianshu.com/p/5192654fc0a7

https://www.jianshu.com/p/be2958745054

http://www.80iter.com/blog/1437455520862503

https://blog.csdn.net/dgutliangxuan/article/details/82939313