總結：

ActiveMQ 的社區(qū)算是比較成熟，但是較目前來說，ActiveMQ 的性能比較差，而且版本迭代很慢，不推薦使用。

RabbitMQ 在吞吐量方面雖然稍遜于 Kafka 和 RocketMQ ，但是由于它基于 erlang 開發(fā)，所以并發(fā)能力很強，性能極其好，延時很低，達到微秒級。但是也因為 RabbitMQ 基于 erlang 開發(fā)，所以國內(nèi)很少有公司有實力做erlang源碼級別的研究和定制。如果業(yè)務場景對并發(fā)量要求不是太高（十萬級、百萬級），那這四種消息隊列中，RabbitMQ 一定是你的首選。如果是大數(shù)據(jù)領域的實時計算、日志采集等場景，用 Kafka 是業(yè)內(nèi)標準的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規(guī)范。

RocketMQ 阿里出品，Java 系開源項目，源代碼我們可以直接閱讀，然后可以定制自己公司的MQ，并且 RocketMQ 有阿里巴巴的實際業(yè)務場景的實戰(zhàn)考驗。RocketMQ 社區(qū)活躍度相對較為一般，不過也還可以，文檔相對來說簡單一些，然后接口這塊不是按照標準 JMS 規(guī)范走的有些系統(tǒng)要遷移需要修改大量代碼。還有就是阿里出臺的技術，你得做好這個技術萬一被拋棄，社區(qū)黃掉的風險，那如果你們公司有技術實力我覺得用RocketMQ 挺好的

kafka 的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms 級的延遲，極高的可用性以及可靠性，而且分布式可以任意擴展。同時 kafka 最好是支撐較少的 topic 數(shù)量即可，保證其超高吞吐量。kafka 唯一的一點劣勢是有可能消息重復消費，那么對數(shù)據(jù)準確性會造成極其輕微的影響，在大數(shù)據(jù)領域中以及日志采集中，這點輕微影響可以忽略這個特性天然適合大數(shù)據(jù)實時計算以及日志收集。