一、概念
圖片
消息中間件MQ（Message Queue）是一種常用的異步通信技術(shù)，它通過(guò)將消息存儲(chǔ)在隊(duì)列中，實(shí)現(xiàn)生產(chǎn)者和消費(fèi)者之間的解耦。MQ的主要作用是保證消息的可靠傳輸和冪等性。本質(zhì)是隊(duì)列，遵循FIFO先進(jìn)先出原則。只不過(guò)隊(duì)列中存放的內(nèi)容是message而已，還是一種跨進(jìn)程的通信機(jī)制，用于上下游傳遞消息。在互聯(lián)網(wǎng)架構(gòu)中，MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的消息通信服務(wù)。使用了MQ之后，消息發(fā)送上游只需要依賴MQ，不用依賴其他服務(wù)。
主要是利用高效可靠的消息傳遞機(jī)制進(jìn)行與平臺(tái)無(wú)關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來(lái)進(jìn)行分布式系統(tǒng)的集成。
圖片
二、常見的消息隊(duì)列
當(dāng)前業(yè)界比較流行的開源消息中間件包括:ActiveMQ、RabbitMQ、RocketMQ、Kafka、 ZeroMQ等，其中應(yīng)用最為廣泛的要數(shù)RabbitMQ、RocketMQ、Kafka這三款。
三、優(yōu)缺點(diǎn)對(duì)比
3.1、RabbitMQ
RabbitMQ是一套開源（MPL）的消息隊(duì)列服務(wù)軟件，是由 LShift 提供的一個(gè) Advanced Message Queuing Protocol (AMQP) 的開源實(shí)現(xiàn)，由以高性能、健壯以及可伸縮性出名的 Erlang 寫成。
優(yōu)點(diǎn)：
erlang語(yǔ)言開發(fā)，性能極其好，延時(shí)很低；
吞吐量到萬(wàn)級(jí)，MQ功能比較完備；
健壯、穩(wěn)定、易用、跨平臺(tái)、支持多種語(yǔ)言、文檔齊全；
有消息確認(rèn)機(jī)制和持久化機(jī)制，可靠性高；
高度可定制的路由；
管理界面較豐富，在互聯(lián)網(wǎng)公司也有較大規(guī)模的應(yīng)用；
社區(qū)活躍度高，幾乎每個(gè)月都發(fā)布幾個(gè)版本。
缺點(diǎn)：
實(shí)現(xiàn)了代理架構(gòu)，意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點(diǎn)上排隊(duì)。此特性使得RabbitMQ易于使用和部署，但是使得其運(yùn)行速度較慢，因?yàn)橹醒牍?jié)點(diǎn)增加了延遲，消息封裝后也比較大。
erlang語(yǔ)言開發(fā)，很難看懂源碼，無(wú)法進(jìn)行源碼級(jí)別的研究和定制，不利于二次維護(hù)和開發(fā)。
rabbitmq集群動(dòng)態(tài)擴(kuò)展比較麻煩。
3.2、RocketMQ
RocketMQ 出自 阿里公司的開源產(chǎn)品，用 JAVA 語(yǔ)言實(shí)現(xiàn)，在設(shè)計(jì)時(shí)參考了 Kafka，并做出了自己的一些改進(jìn)，消息可靠性上比 Kafka 更好。RocketMQ在阿里集團(tuán)被廣泛應(yīng)用在訂單，交易，充值，流計(jì)算，消息推送，日志流式處理，binglog分發(fā)等場(chǎng)景。
優(yōu)點(diǎn)：
- 單機(jī)支持 1 萬(wàn)以上持久化隊(duì)列；
- RocketMQ 的所有消息都是持久化的，先寫入系統(tǒng) PAGECACHE，然后刷盤，可以保證內(nèi)存與磁盤都有一份數(shù)據(jù)，訪問(wèn)時(shí)，直接從內(nèi)存讀?。?/li>
- 模型簡(jiǎn)單，接口易用（JMS 的接口很多場(chǎng)合并不太實(shí)用）；
- 性能非常好，可以大量堆積消息在broker中；
- 支持多種消費(fèi)，包括集群消費(fèi)、廣播消費(fèi)等；
- 各個(gè)環(huán)節(jié)分布式擴(kuò)展設(shè)計(jì)，主從HA；
- 開發(fā)度較活躍，版本更新很快。
缺點(diǎn)：
- 支持的客戶端語(yǔ)言不多，目前是java及c++，其中c++不成熟；
- RocketMQ社區(qū)關(guān)注度及成熟度也不及前兩者；
- 沒(méi)有web管理界面，提供了一個(gè)CLI(命令行界面)管理工具帶來(lái)查詢、管理和診斷各種問(wèn)題；
- 沒(méi)有在 mq 核心中去實(shí)現(xiàn)JMS等接口。
3.3、Kafka
Apache Kafka是一個(gè)分布式消息發(fā)布訂閱系統(tǒng)。它最初由LinkedIn公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個(gè)分布式的提交日志系統(tǒng)( a distributed commit log)，，之后成為Apache項(xiàng)目的一部分。Kafka系統(tǒng)快速、可擴(kuò)展并且可持久化。它的分區(qū)特性，可復(fù)制和可容錯(cuò)都是其不錯(cuò)的特性。
圖片
優(yōu)點(diǎn)：
客戶端語(yǔ)言豐富，支持java、.NET、php、ruby、Python/ target=_blank class=infotextkey>Python、go等多種語(yǔ)言；
性能卓越，單機(jī)寫入TPS約在百萬(wàn)條/秒，消息大小10個(gè)字節(jié)；
提供完全分布式架構(gòu), 并有replica機(jī)制, 擁有較高的可用性和可靠性, 理論上支持消息無(wú)限堆積；
支持批量操作；
消費(fèi)者采用Pull方式獲取消息, 消息有序, 通過(guò)控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次;
有優(yōu)秀的第三方Kafka Web管理界面Kafka-Manager；
在日志領(lǐng)域比較成熟，被多家公司和多個(gè)開源項(xiàng)目使用。
缺點(diǎn)：
Kafka單機(jī)超過(guò)64個(gè)隊(duì)列/分區(qū)，Load會(huì)發(fā)生明顯的飆高現(xiàn)象，隊(duì)列越多，load越高，發(fā)送消息響應(yīng)時(shí)間變長(zhǎng)；
使用短輪詢方式，實(shí)時(shí)性取決于輪詢間隔時(shí)間；
消費(fèi)失敗不支持重試；
支持消息順序，但是一臺(tái)代理宕機(jī)后，就會(huì)產(chǎn)生消息亂序；
社區(qū)更新較慢。
四、主要應(yīng)用場(chǎng)景
4.1、流量削峰
圖片
常用于高并發(fā)場(chǎng)景，進(jìn)行削峰。例如：現(xiàn)在有一個(gè)訂單系統(tǒng)，高峰期訂單量過(guò)多，而系統(tǒng)最多只能處理1w次/s。此時(shí)可以通過(guò)消息隊(duì)列使得這些超出處理能力的下單請(qǐng)求處于隊(duì)列中進(jìn)行等待，而不至于將所有的請(qǐng)求全部一次性打到訂單系統(tǒng)中，造成訂單系統(tǒng)宕機(jī)。這就相當(dāng)于將實(shí)際一秒鐘內(nèi)的訂單拆分成多個(gè)段來(lái)進(jìn)行處理，這樣的處理方式雖然加長(zhǎng)了等待時(shí)間，但是有缺點(diǎn)總比不能用好。這樣可以緩解業(yè)務(wù)量對(duì)系統(tǒng)帶來(lái)的沖擊，避免系統(tǒng)宕機(jī)而造成不能使用。
redis緩存預(yù)熱。緩存預(yù)熱實(shí)際上是將熱點(diǎn)數(shù)據(jù)提前緩存到Redis中進(jìn)行儲(chǔ)存，避免高峰期數(shù)據(jù)請(qǐng)求直接下達(dá)到數(shù)據(jù)庫(kù)造成數(shù)據(jù)庫(kù)崩潰。同樣流量消峰，也是達(dá)到此效果，只不過(guò)一個(gè)針對(duì)的是數(shù)據(jù)庫(kù)方面，一個(gè)針對(duì)的是服務(wù)層的請(qǐng)求。
參考案例：springBoot對(duì)接kafka,批量、并發(fā)、異步獲取消息,并動(dòng)態(tài)、批量插入庫(kù)表
4.2、應(yīng)用解耦
圖片
若訂單系統(tǒng)耦合調(diào)用支付系統(tǒng)、庫(kù)存系統(tǒng)或者物流系統(tǒng)，一旦這三個(gè)系統(tǒng)發(fā)生故障，訂單系統(tǒng)就會(huì)處于不可用的狀態(tài)。如果轉(zhuǎn)變?yōu)橛孟㈥?duì)列處理調(diào)用請(qǐng)求，可以減少很多問(wèn)題。當(dāng)故障發(fā)生時(shí)，子系統(tǒng)要處理的內(nèi)存會(huì)被緩存在消息隊(duì)列中，而用戶的下單操作還是可以正常完成；故障處理完之后，再處理用戶的訂單信息即可。整個(gè)過(guò)程中的故障對(duì)于用戶來(lái)說(shuō)是無(wú)感的，可以提高系統(tǒng)的可用性。
4.3、異步處理
圖片
當(dāng)A需要調(diào)用B，B需要花很長(zhǎng)時(shí)間來(lái)處理調(diào)用，A需要得知B何時(shí)處理完畢?？梢詫?shí)現(xiàn)的方式很多，但是很不方便。使用消息隊(duì)列可以很輕松實(shí)現(xiàn)。只需要監(jiān)聽B處理完成的消息即可，當(dāng)B處理完畢，將處理完畢的信息發(fā)送給消息隊(duì)列，之后消息隊(duì)列將消息反饋給A即可。這樣的方式，A既不用循環(huán)調(diào)用B的查詢API，也不需要B提供callback API(回調(diào)API)，同時(shí)B也不用完成這些操作；A還能及時(shí)得到B服務(wù)處理完成的信息。
參考案例：springBoot對(duì)接kafka,批量、并發(fā)、異步獲取消息,并動(dòng)態(tài)、批量插入庫(kù)表
五、選哪一種中間件？
圖片
個(gè)人建議：對(duì)于大部分公司，可以優(yōu)選選擇使用RabbitMQ，其次選擇Kafka，相比Kafka，RabbitMQ適合對(duì)數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場(chǎng)景，有消息確認(rèn)機(jī)制和持久化機(jī)制，可靠性非常高。
六、詳細(xì)對(duì)比參數(shù)
圖片
