現在市面上的消息中間件種類很多，常用的大致有4種，分別是Kafka、ActiveMQ、RabbitMQ、RocketMQ。
那么Kafka、ActiveMQ、RabbitMQ、RocketMQ都有什么優缺點？怎么技術選型呢？
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 單機吞吐量 | 萬級，比 RocketMQ、Kafka 低一個數量級 | 同 ActiveMQ | 10 萬級，支撐高吞吐 | 10 萬級，高吞吐，一般配合大數據類的系統來進行實時數據計算、日志采集等場景 |
| topic 數量對吞吐量的影響 | topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic | topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 盡量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源 | ||
| 時效性 | ms 級 | 微秒級，這是 RabbitMQ 的一大特點，延遲最低 | ms 級 | 延遲在 ms 級以內 |
| 可用性 | 高，基於主從架構實現高可用 | 同 ActiveMQ | 非常高，分布式架構 | 非常高，分布式，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數據 | 基本不丟 | 經過參數優化配置，可以做到 0 丟失 | 同 RocketMQ |
| 功能支持 | MQ 領域的功能極其完備 | 基於 erlang 開發，並發能力很強，性能極好，延時很低 | MQ 功能較為完善，還是分布式的，擴展性好 | 功能較為簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日志采集被大規模使用 |
綜上，各種對比之后，有如下建議：
一般的業務系統要引入 MQ，最早大家都用 ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
后來大家開始用 RabbitMQ，但是確實 erlang 語言阻止了大量的 Java 工程師去深入研究和掌控它，對公司而言，幾乎處於不可控的狀態，但是確實人家是開源的，比較穩定的支持，活躍度也高；
不過現在確實越來越多的公司會去用 RocketMQ，確實很不錯，畢竟是阿里出品，但社區可能有突然黃掉的風險（目前 RocketMQ 已捐給 Apache，但 GitHub 上的活躍度其實不算高）對自己公司技術實力有絕對自信的，推薦用 RocketMQ，否則回去老老實實用 RabbitMQ 吧，人家有活躍的開源社區，絕對不會黃。
所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用 RabbitMQ 是不錯的選擇；大型公司，基礎架構研發實力較強，用 RocketMQ 是很好的選擇。
如果是大數據領域的實時計算、日志采集等場景，用 Kafka 是業內標准的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規范。