Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什麼優缺點?架構
特性併發 |
ActiveMQ分佈式 |
RabbitMQ性能 |
RocketMQ大數據 |
Kafka優化 |
單機吞吐量spa |
萬級,比 RocketMQ、Kafka 低一個數量級日誌 |
同 ActiveMQci |
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,不然回去老老實實用 RabbitMQ 吧,人家有活躍的開源社區,絕對不會黃。
因此中小型公司,技術實力較爲通常,技術挑戰不是特別高,用 RabbitMQ 是不錯的選擇;大型公司,基礎架構研發實力較強,用 RocketMQ 是很好的選擇。
若是是大數據領域的實時計算、日誌採集等場景,用 Kafka 是業內標準的,絕對沒問題,社區活躍度很高,絕對不會黃,況且幾乎是全世界這個領域的事實性規範。