RabbitMQ,RocketMQ,Kafka 幾種訊息佇列的對比

Rick.lz發表於2021-12-10

常用的幾款訊息佇列的對比

前言

訊息佇列的作用:

1、應用耦合:多應用間通過訊息佇列對同一訊息進行處理,避免呼叫介面失敗導致整個過程失敗;

2、非同步處理:多應用對訊息佇列中同一訊息進行處理,應用間併發處理訊息,相比序列處理,減少處理時間;

3、限流削峰:廣泛應用於秒殺或搶購活動中,避免流量過大導致應用系統掛掉的情況;

4、訊息驅動的系統:系統分為訊息佇列、訊息生產者、訊息消費者,生產者負責產生訊息,消費者(可能有多個)負責對訊息進行處理;

首先選擇訊息佇列要滿足以下幾個條件:

1、開源

2、流行

3、相容性強

訊息佇列需要:

1、訊息的可靠傳遞:確保不丟訊息;

2、Cluster:支援叢集,確保不會因為某個節點當機導致服務不可用,當然也不能丟訊息;

3、效能:具備足夠好的效能,能滿足絕大多數場景的效能要求。

RabbitMQ

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

優點

1、RabbitMQ 的特點 Messaging that just works,“開箱即用的訊息佇列”。 RabbitMQ 是一個相對輕量的訊息佇列,非常容易部署和使用;

2、多種協議的支援:支援多種訊息佇列協議,算的上是最流行的訊息佇列之一;

3、靈活的路由配置,和其他訊息佇列不同的是,它在生產者 (Producer)和佇列(Queue)之間增加了一個Exchange模組,你可以理解為交換機。這個Exchange模組的作用和交換機也非常相似,根據配置的路由規則將生產者發出的訊息分發到不同的隊 列中。路由的規則也非常靈活,甚至你可以自己來實現路由規則。

4、健壯、穩定、易用、跨平臺、支援多種語言、文件齊全,RabbitMQ的客戶端支援的程式語言大概是所有訊息佇列中最多的;

5、管理介面較豐富,在網際網路公司也有較大規模的應用;

6、社群比較活躍。

缺點

1、RabbitMQ 對訊息堆積的處理不好,在它的設計理念裡面,訊息佇列是一個管道,大量的訊息積壓是一種不正常的情況,應當儘量去避免。當大量訊息積壓的時候,會導致RabbitMQ的效能急劇下降;

2、效能上有瓶頸,它大概每秒鐘可以處理幾萬到十幾萬條訊息,這個對於大多數場景足夠使用了,如果對需求對效能要求非常高,那麼就不太合適了。

3、RabbitMQ 使用 Erlang。開發,Erlang 的學習成本還是很高的,如果後期進行二次開發,就不太容易了。

RocketMQ

RocketMQ出自阿里公司的開源產品,用 Java 語言實現,在設計時參考了 Kafka,並做出了自己的一些改進,訊息可靠性上比 Kafka 更好。經歷過多次雙十一的考驗,效能和穩定性還是值得信賴的,RocketMQ在阿里集團被廣泛應用在訂單,交易,充值,流計算,訊息推送,日誌流式處理,binglog分發等場景。

優點

1、單機吞吐量:十萬級;

2、可用性:非常高,分散式架構;

3、訊息可靠性:經過引數優化配置,訊息可以做到0丟失,RocketMQ 的所有訊息都是持久化的,先寫入系統 PAGECACHE,然後刷盤,可以保證記憶體與磁碟都有一份資料;

4、功能支援:MQ功能較為完善,還是分散式的,擴充套件性好;

5、支援10億級別的訊息堆積,不會因為堆積導致效能下降;

6、原始碼是java,我們可以自己閱讀原始碼,定製自己公司的MQ,可以掌控。

缺點

1、支援的客戶端語言不多,目前是 java 及 c++,其中 c++ 不成熟;

2、社群活躍度一般,作為國產的訊息佇列,相比國外的比較流行的同類產品,在國際上還沒有那麼流行,與周邊生態系統的整合和相容程度要略遜一籌;

3、沒有在 mq 核心中去實現 JMS 等介面,有些系統要遷移需要修改大量程式碼。

Kafka

Apache Kafka是一個分散式訊息釋出訂閱系統。它最初由LinkedIn公司基於獨特的設計實現為一個分散式的提交日誌系統( a distributed commit log),之後成為Apache專案的一部分。

這是一款為大資料而生的訊息中介軟體,在資料採集、傳輸、儲存的過程中發揮著舉足輕重的作用。

優點

1、效能卓越,單機寫入TPS約在百萬條/秒,最大的優點,就是吞吐量高;

2、效能卓越,單機寫入TPS約在百萬條/秒,訊息大小10個位元組;

3、可用性:非常高,kafka是分散式的,一個資料多個副本,少數機器當機,不會丟失資料,不會導致不可用;

4、消費者採用Pull方式獲取訊息, 訊息有序, 通過控制能夠保證所有訊息被消費且僅被消費一次;

5、有優秀的第三方Kafka Web管理介面Kafka-Manager;

6、在日誌領域比較成熟,被多家公司和多個開源專案使用;

7、功能支援:功能較為簡單,主要支援簡單的MQ功能,在大資料領域的實時計算以及日誌採集被大規模使用

缺點

由於“攢一波再處理”導致延遲比較高

如何選擇合適的訊息佇列

如果對於訊息佇列的功能和效能要求不是很高,那麼RabbitMQ就夠了,開箱即用。

如果系統使用訊息佇列主要場景是處理線上業務,比如在交易系統中用訊息佇列傳遞訂單,RocketMQ 的低延遲和金融級的穩定性就可以滿足。

要處理海量的訊息,像收集日誌、監控資訊或是前端的埋點這類資料,或是你的應用場景大量使用 了大資料、流計算相關的開源產品,那 Kafka 就是最合適的了。

參考

【訊息佇列及常見訊息佇列介紹】https://cloud.tencent.com/developer/article/1006035
【訊息佇列高手課】https://time.geekbang.org/column/intro/100032301
【訊息佇列Kafka、RocketMQ、RabbitMQ的優劣勢比較】https://zhuanlan.zhihu.com/p/60288391
【Kafka】https://zh.wikipedia.org/wiki/Kafka
【RabbitMQ,RocketMQ,Kafka 幾種訊息佇列的對比】https://boilingfrog.github.io/2021/12/10/幾種常見的訊息佇列的對比/

相關文章