訊息佇列Kafka、RocketMQ、RabbitMQ的優劣勢、技術應用及選擇

在高併發業務場景下，典型的阿裡雙11、12306春運火車票、秒殺等業務系統的正常執行，訊息佇列中介軟體在流量削峯、解耦上有着不可替代的作用。

搞懂以下幾個問題，相信你會對訊息佇列有更加全面的認識與瞭解：

全量訊息佇列都有哪些

Kafka、RocketMQ、RabbitMQ的優劣勢比較
訊息佇列的選型

這裏面幾乎完全列舉了當下比較知名的訊息引擎，包括：

ZeroMQ
推特的Distributedlog
ActiveMQ：
Apache旗下的老牌訊息引擎
RabbitMQ、Kafka：AMQP的預設實現
RocketMQ
Artemis：Apache的ActiveMQ下的子專案
Apollo：同樣爲Apache的ActiveMQ的子專案的號稱下一代訊息引擎
商業化的訊息引擎IronMQ
實現了JMS(Java Message Service)標準的OpenMQ

MQ訊息佇列的技術應用

1.解耦

解耦是訊息佇列要解決的最本質問題。

2.最終一致性

最終一致性指的是兩個系統的狀態保持一致，要麼都成功，要麼都失敗。

最終一致性不是訊息佇列的必備特性，但確實可以依靠訊息佇列來做最終一致性的事情。

3.廣播

訊息佇列的基本功能之一是進行廣播。

有了訊息佇列，我們只需要關心訊息是否送達了佇列，至於誰希望訂閱，是下遊的事情，無疑極大地減少了開發和聯調的工作量。

4.錯峯與流控

典型的使用場景就是秒殺業務用於流量削峯場景。

由於篇幅的關係，本文重點介紹訊息佇列比較，詳細應用場景請參考我的往期分享：什麼是流量削峯？如何解決秒殺業務的削峯場景
Kafka、RocketMQ、RabbitMQ比較

1.ActiveMQ

優點：

單機吞吐量：萬級topic數量都吞吐量的影響；
時效性高；
ms級可用性高；
基於主從架構實現高可用性訊息可靠性；
有較低的概率丟失數據功能支援；
MQ領域的功能極其完備。

缺點:

官方社羣現在對ActiveMQ 5.x維護越來越少，較少在大規模吞吐的場景中使用。

2.Kafka

號稱大數據的殺手锏，談到大數據領域內的訊息傳輸，則繞不開Kafka，這款爲大數據而生的訊息中介軟體，以其百萬級TPS的吞吐量名聲大噪，迅速成爲大數據領域的寵兒，在數據採集、傳輸、儲存的過程中發揮着舉足輕重的作用。

Apache Kafka它最初由LinkedIn公司基於獨特的設計實現爲一個分佈式的提交日誌系統( a distributed commit log)，之後成爲Apache專案的一部分。

目前已經被LinkedIn，Uber, Twitter, Netflix等大公司所採納。

優點：

效能卓越：單機寫入TPS約在百萬條/秒，最大的優點，就是吞吐量高。
時效性：ms級可用性非常高，kafka是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用消費者採用Pull方式獲取訊息，訊息有序，通過控制能夠保證所有訊息被消費且僅被消費一次。
有優秀的第三方Kafka Web管理介面Kafka-Manager；在日誌領域比較成熟，被多家公司和多個開源專案使用；
功能支援：功能較爲簡單，主要支援簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用。

缺點：

Kafka單機超過64個佇列/分割區，Load會發生明顯的飆高現象，佇列越多，load越高，發送訊息響應時間變長使用短輪詢方式，實時性取決於輪詢間隔時間；
消費失敗不支援重試；支援訊息順序，但是一臺代理宕機後，就會產生訊息亂序；
社羣更新較慢；

3.RabbitMQ

RabbitMQ 2007年發佈，是一個在AMQP(高階訊息佇列協定)基礎上完成的，可複用的企業訊息系統，是當前最主流的訊息中介軟體之一。

優點：

由於erlang語言的特性，mq 效能較好，高併發；吞吐量到萬級，MQ功能比較完備。
健壯、穩定、易用、跨平臺、支援多種語言、文件齊全；開源提供的管理介面非常棒，用起來很好用社羣活躍度高。

缺點：

erlang開發，很難去看懂原始碼，基本職能依賴於開源社羣的快速維護和修復bug，不利於做二次開發和維護。
RabbitMQ確實吞吐量會低一些，這是因爲他做的實現機制 機製比較重。
需要學習比較複雜的介面和協定，學習和維護成本較高。

4.RocketMQ

RocketMQ出自 阿裡公司的開源產品，用 Java 語言實現，在設計時參考了 Kafka，並做出了自己的一些改進。
RocketMQ在阿裡集團被廣泛應用在訂單，交易，充值，流計算，訊息推播，日誌流式處理，binglog分發等場景。

優點：

單機吞吐量：十萬級可用性，非常高。
分佈式架構訊息可靠性：經過參數優化設定，訊息可以做到0丟失功能支援。
MQ功能較爲完善，還是分佈式的，擴充套件性好支援10億級別的訊息堆積，不會因爲堆積導致效能下降原始碼是java，我們可以自己閱讀原始碼，定製自己公司的MQ，可以掌控。

缺點：

支援的用戶端語言不多，目前是java及c++，其中c++不成熟。
社羣活躍度一般沒有在 mq 核心中去實現JMS等介面，有些系統要遷移需要修改大量程式碼。

訊息佇列選擇建議

1.Kafka

Kafka主要特點是基於Pull的模式來處理訊息消費，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸，適合產生大量數據的網際網路服務的數據收集業務。

大型公司建議可以選用，如果有日誌採集功能，肯定是首選kafka了。

2.RocketMQ

天生爲金融網際網路領域而生，對於可靠性要求很高的場景，尤其是電商裏面的訂單扣款，以及業務削峯，在大量交易涌入時，後端可能無法及時處理的情況。

RoketMQ在穩定性上可能更值得信賴，這些業務場景在阿裡雙11已經經歷了多次考驗，如果你的業務有上述併發場景，建議可以選擇RocketMQ。

3.RabbitMQ

RabbitMQ :結合erlang語言本身的併發優勢，效能較好，社羣活躍度也比較高，但是不利於做二次開發和維護。不過，RabbitMQ的社羣十分活躍，可以解決開發過程中遇到的bug。

如果你的數據量沒有那麼大，小公司優先選擇功能比較完備的RabbitMQ。