一、概念

圖片

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

    主要是利用高效可靠的消息傳遞機制進行與平臺無關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成。

圖片

二、常見的消息隊列

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

三、優(yōu)缺點對比

3.1、RabbitMQ

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

優(yōu)點：

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

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

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

有消息確認(rèn)機制和持久化機制，可靠性高；

高度可定制的路由；

管理界面較豐富，在互聯(lián)網(wǎng)公司也有較大規(guī)模的應(yīng)用；

社區(qū)活躍度高，幾乎每個月都發(fā)布幾個版本。

缺點：

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

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

rabbitmq集群動態(tài)擴展比較麻煩。

3.2、RocketMQ

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

優(yōu)點：

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

缺點：

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

3.3、Kafka

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

圖片

優(yōu)點：

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

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

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

支持批量操作；

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

有優(yōu)秀的第三方Kafka Web管理界面Kafka-Manager；

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

缺點：

Kafka單機超過64個隊列/分區(qū)，Load會發(fā)生明顯的飆高現(xiàn)象，隊列越多，load越高，發(fā)送消息響應(yīng)時間變長；

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

消費失敗不支持重試；

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

社區(qū)更新較慢。

四、主要應(yīng)用場景

4.1、流量削峰

圖片

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

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

參考案例：springBoot對接kafka,批量、并發(fā)、異步獲取消息,并動態(tài)、批量插入庫表

4.2、應(yīng)用解耦

圖片

    若訂單系統(tǒng)耦合調(diào)用支付系統(tǒng)、庫存系統(tǒng)或者物流系統(tǒng)，一旦這三個系統(tǒng)發(fā)生故障，訂單系統(tǒng)就會處于不可用的狀態(tài)。如果轉(zhuǎn)變?yōu)橛孟㈥犃刑幚碚{(diào)用請求，可以減少很多問題。當(dāng)故障發(fā)生時，子系統(tǒng)要處理的內(nèi)存會被緩存在消息隊列中，而用戶的下單操作還是可以正常完成；故障處理完之后，再處理用戶的訂單信息即可。整個過程中的故障對于用戶來說是無感的，可以提高系統(tǒng)的可用性。

4.3、異步處理

圖片

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

參考案例：springBoot對接kafka,批量、并發(fā)、異步獲取消息,并動態(tài)、批量插入庫表

五、選哪一種中間件？

圖片

個人建議：對于大部分公司，可以優(yōu)選選擇使用RabbitMQ，其次選擇Kafka，相比Kafka，RabbitMQ適合對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景，有消息確認(rèn)機制和持久化機制，可靠性非常高。

六、詳細(xì)對比參數(shù)

圖片