聊聊消息中間件MQ

作者：程序猿羊 2023-10-24 07:50:18

當前業界比較流行的開源消息中間件包括:ActiveMQ、RabbitMQ、RocketMQ、Kafka、 ZeroMQ等，其中應用最為廣泛的要數RabbitMQ、RocketMQ、Kafka這三款。

一、概念

圖片

消息中間件MQ（Message Queue）是一種常用的異步通信技術，它通過將消息存儲在隊列中，實現生產者和消費者之間的解耦。MQ的主要作用是保證消息的可靠傳輸和冪等性。本質是隊列，遵循FIFO先進先出原則。只不過隊列中存放的內容是message而已，還是一種跨進程的通信機制，用于上下游傳遞消息。在互聯網架構中，MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的消息通信服務。使用了MQ之后，消息發送上游只需要依賴MQ，不用依賴其他服務。

主要是利用高效可靠的消息傳遞機制進行與平臺無關的數據交流，并基于數據通信來進行分布式系統的集成。

圖片

二、常見的消息隊列

當前業界比較流行的開源消息中間件包括:ActiveMQ、RabbitMQ、RocketMQ、Kafka、 ZeroMQ等，其中應用最為廣泛的要數RabbitMQ、RocketMQ、Kafka這三款。

三、優缺點對比

3.1、RabbitMQ

RabbitMQ是一套開源（MPL）的消息隊列服務軟件，是由 LShift 提供的一個 Advanced Message Queuing Protocol (AMQP) 的開源實現，由以高性能、健壯以及可伸縮性出名的 Erlang 寫成。

優點：

erlang語言開發，性能極其好，延時很低；

吞吐量到萬級，MQ功能比較完備；

健壯、穩定、易用、跨平臺、支持多種語言、文檔齊全；

有消息確認機制和持久化機制，可靠性高；

高度可定制的路由；

管理界面較豐富，在互聯網公司也有較大規模的應用；

社區活躍度高，幾乎每個月都發布幾個版本。

缺點：

實現了代理架構，意味著消息在發送到客戶端之前可以在中央節點上排隊。此特性使得RabbitMQ易于使用和部署，但是使得其運行速度較慢，因為中央節點增加了延遲，消息封裝后也比較大。

erlang語言開發，很難看懂源碼，無法進行源碼級別的研究和定制，不利于二次維護和開發。

rabbitmq集群動態擴展比較麻煩。

3.2、RocketMQ

RocketMQ 出自阿里公司的開源產品，用 Java 語言實現，在設計時參考了 Kafka，并做出了自己的一些改進，消息可靠性上比 Kafka 更好。RocketMQ在阿里集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發等場景。

優點：

單機支持 1 萬以上持久化隊列；
RocketMQ 的所有消息都是持久化的，先寫入系統 PAGECACHE，然后刷盤，可以保證內存與磁盤都有一份數據，訪問時，直接從內存讀取；
模型簡單，接口易用（JMS 的接口很多場合并不太實用）；
性能非常好，可以大量堆積消息在broker中；
支持多種消費，包括集群消費、廣播消費等；
各個環節分布式擴展設計，主從HA；
開發度較活躍，版本更新很快。

缺點：

支持的客戶端語言不多，目前是java及c++，其中c++不成熟；
RocketMQ社區關注度及成熟度也不及前兩者；
沒有web管理界面，提供了一個CLI(命令行界面)管理工具帶來查詢、管理和診斷各種問題；
沒有在 mq 核心中去實現JMS等接口。

3.3、Kafka

Apache Kafka是一個分布式消息發布訂閱系統。它最初由LinkedIn公司基于獨特的設計實現為一個分布式的提交日志系統( a distributed commit log)，，之后成為Apache項目的一部分。Kafka系統快速、可擴展并且可持久化。它的分區特性，可復制和可容錯都是其不錯的特性。

圖片

優點：

客戶端語言豐富，支持java、.net、php、ruby、python、go等多種語言；

性能卓越，單機寫入TPS約在百萬條/秒，消息大小10個字節；

提供完全分布式架構, 并有replica機制, 擁有較高的可用性和可靠性, 理論上支持消息無限堆積；

支持批量操作；

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

有優秀的第三方Kafka Web管理界面Kafka-Manager；

在日志領域比較成熟，被多家公司和多個開源項目使用。

缺點：

Kafka單機超過64個隊列/分區，Load會發生明顯的飆高現象，隊列越多，load越高，發送消息響應時間變長；

使用短輪詢方式，實時性取決于輪詢間隔時間；

消費失敗不支持重試；

支持消息順序，但是一臺代理宕機后，就會產生消息亂序；

社區更新較慢。

四、主要應用場景

4.1、流量削峰

圖片

常用于高并發場景，進行削峰。例如：現在有一個訂單系統，高峰期訂單量過多，而系統最多只能處理1w次/s。此時可以通過消息隊列使得這些超出處理能力的下單請求處于隊列中進行等待，而不至于將所有的請求全部一次性打到訂單系統中，造成訂單系統宕機。這就相當于將實際一秒鐘內的訂單拆分成多個段來進行處理，這樣的處理方式雖然加長了等待時間，但是有缺點總比不能用好。這樣可以緩解業務量對系統帶來的沖擊，避免系統宕機而造成不能使用。

Redis緩存預熱。緩存預熱實際上是將熱點數據提前緩存到Redis中進行儲存，避免高峰期數據請求直接下達到數據庫造成數據庫崩潰。同樣流量消峰，也是達到此效果，只不過一個針對的是數據庫方面，一個針對的是服務層的請求。

參考案例：springBoot對接kafka,批量、并發、異步獲取消息,并動態、批量插入庫表

4.2、應用解耦

圖片

若訂單系統耦合調用支付系統、庫存系統或者物流系統，一旦這三個系統發生故障，訂單系統就會處于不可用的狀態。如果轉變為用消息隊列處理調用請求，可以減少很多問題。當故障發生時，子系統要處理的內存會被緩存在消息隊列中，而用戶的下單操作還是可以正常完成；故障處理完之后，再處理用戶的訂單信息即可。整個過程中的故障對于用戶來說是無感的，可以提高系統的可用性。

4.3、異步處理

圖片

當A需要調用B，B需要花很長時間來處理調用，A需要得知B何時處理完畢。可以實現的方式很多，但是很不方便。使用消息隊列可以很輕松實現。只需要監聽B處理完成的消息即可，當B處理完畢，將處理完畢的信息發送給消息隊列，之后消息隊列將消息反饋給A即可。這樣的方式，A既不用循環調用B的查詢API，也不需要B提供callback API(回調API)，同時B也不用完成這些操作；A還能及時得到B服務處理完成的信息。