高併發架構系列:Kafka、RocketMQ、RabbitMQ的優劣勢比較

在高併發業務場景下,典型的阿里雙11秒殺等業務,消息隊列中間件在流量削峰、解耦上有不可替代的作用。

今天我們一起來探討:

全量的消息隊列究竟有哪些? Kafka、RocketMQ、RabbitMQ的優劣勢比較,以及消息隊列的選型。那麼目前在業界有哪些比較知名的消息引擎呢?如下圖所示

這裡面幾乎完全列舉了當下比較知名的消息引擎,包括:

ZeroMQ推特的DistributedlogActiveMQ:Apache旗下的老牌消息引擎RabbitMQ、Kafka:AMQP的默認實現。RocketMQArtemis: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(高級消息隊列協議)基礎上完成的,可複用的企業消息系統,是當前最主流的消息中間件之一。

RabbitMQ優點:

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

RabbitMQ缺點:

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

4.RocketMQ

RocketMQ出自 阿里公司的開源產品,用 Java 語言實現,在設計時參考了 Kafka,並做出了自己的一些改進。

RocketMQ在阿里集團被廣泛應用在訂單,交易,充值,流計算,消息推送,日誌流式處理,binglog分發等場景。

RocketMQ優點:

單機吞吐量:十萬級可用性:非常高,分佈式架構消息可靠性:經過參數優化配置,消息可以做到0丟失功能支持:MQ功能較為完善,還是分佈式的,擴展性好支持10億級別的消息堆積,不會因為堆積導致性能下降源碼是java,我們可以自己閱讀源碼,定製自己公司的MQ,可以掌控

RocketMQ缺點:

支持的客戶端語言不多,目前是java及c++,其中c++不成熟;社區活躍度一般沒有在 mq 核心中去實現JMS等接口,有些系統要遷移需要修改大量代碼

消息隊列選擇建議

1.Kafka

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

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

2.RocketMQ

天生為金融互聯網領域而生,對於可靠性要求很高的場景,尤其是電商裡面的訂單扣款,以及業務削峰,在大量交易湧入時,後端可能無法及時處理的情況。

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

3.RabbitMQ

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

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

喜歡的小夥伴,點個關注吧,每天分享新的內容!