在高并發(fā)業(yè)務(wù)場(chǎng)景下俄烁，典型的阿里雙11秒殺等業(yè)務(wù)，消息隊(duì)列中間件在流量削峰级野、解耦上有不可替代的作用页屠。

之前介紹了《MQ消息隊(duì)列的12點(diǎn)核心原理總結(jié)》，以及《如何從0到1設(shè)計(jì)一個(gè)MQ消息隊(duì)列》蓖柔，以及《RPC遠(yuǎn)程調(diào)用和消息隊(duì)列MQ的區(qū)別》辰企。

今天我們一起來探討：

全量的消息隊(duì)列究竟有哪些？ Kafka况鸣、RocketMQ牢贸、RabbitMQ的優(yōu)劣勢(shì)比較，以及消息隊(duì)列的選型

最全MQ消息隊(duì)列有哪些镐捧？

那么目前在業(yè)界有哪些比較知名的消息引擎呢潜索？如下圖所示

這里面幾乎完全列舉了當(dāng)下比較知名的消息引擎，包括：

ZeroMQ

推特的Distributedlog

ActiveMQ：Apache旗下的老牌消息引擎

RabbitMQ懂酱、Kafka：AMQP的默認(rèn)實(shí)現(xiàn)竹习。

RocketMQ

Artemis：Apache的ActiveMQ下的子項(xiàng)目

Apollo：同樣為Apache的ActiveMQ的子項(xiàng)目的號(hào)稱下一代消息引擎

商業(yè)化的消息引擎IronMQ

以及實(shí)現(xiàn)了JMS(Java Message Service)標(biāo)準(zhǔn)的OpenMQ。

MQ消息隊(duì)列的技術(shù)應(yīng)用

1.解耦

解耦是消息隊(duì)列要解決的最本質(zhì)問題列牺。

2.最終一致性

最終一致性指的是兩個(gè)系統(tǒng)的狀態(tài)保持一致整陌，要么都成功，要么都失敗。

最終一致性不是消息隊(duì)列的必備特性泌辫，但確實(shí)可以依靠消息隊(duì)列來做最終一致性的事情随夸。

2.廣播

消息隊(duì)列的基本功能之一是進(jìn)行廣播。

有了消息隊(duì)列震放，我們只需要關(guān)心消息是否送達(dá)了隊(duì)列宾毒，至于誰希望訂閱，是下游的事情澜搅，無疑極大地減少了開發(fā)和聯(lián)調(diào)的工作量伍俘。

3.錯(cuò)峰與流控

典型的使用場(chǎng)景就是秒殺業(yè)務(wù)用于流量削峰場(chǎng)景。

由于篇幅的關(guān)系勉躺，本文重點(diǎn)介紹消息隊(duì)列比較，詳細(xì)應(yīng)用場(chǎng)景請(qǐng)參考：《什么是流量削峰觅丰？如何解決秒殺業(yè)務(wù)的削峰場(chǎng)景》饵溅。

Kafka、RocketMQ妇萄、RabbitMQ比較

1.ActiveMQ

優(yōu)點(diǎn)

單機(jī)吞吐量：萬級(jí)

topic數(shù)量都吞吐量的影響：

時(shí)效性：ms級(jí)

可用性：高蜕企，基于主從架構(gòu)實(shí)現(xiàn)高可用性

消息可靠性：有較低的概率丟失數(shù)據(jù)

功能支持：MQ領(lǐng)域的功能極其完備

缺點(diǎn):

官方社區(qū)現(xiàn)在對(duì)ActiveMQ 5.x維護(hù)越來越少，較少在大規(guī)模吞吐的場(chǎng)景中使用冠句。

2.Kafka

號(hào)稱大數(shù)據(jù)的殺手锏轻掩，談到大數(shù)據(jù)領(lǐng)域內(nèi)的消息傳輸，則繞不開Kafka懦底，這款為大數(shù)據(jù)而生的消息中間件唇牧，以其百萬級(jí)TPS的吞吐量名聲大噪，迅速成為大數(shù)據(jù)領(lǐng)域的寵兒聚唐，在數(shù)據(jù)采集丐重、傳輸、存儲(chǔ)的過程中發(fā)揮著舉足輕重的作用杆查。

Apache Kafka它最初由LinkedIn公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個(gè)分布式的提交日志系統(tǒng)( a distributed commit log)扮惦，之后成為Apache項(xiàng)目的一部分。

目前已經(jīng)被LinkedIn亲桦，Uber, Twitter, Netflix等大公司所采納崖蜜。

優(yōu)點(diǎn)

性能卓越，單機(jī)寫入TPS約在百萬條/秒客峭，最大的優(yōu)點(diǎn)豫领，就是吞吐量高。

時(shí)效性：ms級(jí)

可用性：非常高桃笙，kafka是分布式的氏堤，一個(gè)數(shù)據(jù)多個(gè)副本，少數(shù)機(jī)器宕機(jī)，不會(huì)丟失數(shù)據(jù)鼠锈，不會(huì)導(dǎo)致不可用

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

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

在日志領(lǐng)域比較成熟，被多家公司和多個(gè)開源項(xiàng)目使用购笆；

功能支持：功能較為簡(jiǎn)單粗悯，主要支持簡(jiǎn)單的MQ功能，在大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算以及日志采集被大規(guī)模使用

缺點(diǎn)：

Kafka單機(jī)超過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ū)更新較慢蚊荣；

3.RabbitMQ

RabbitMQ 2007年發(fā)布，是一個(gè)在AMQP(高級(jí)消息隊(duì)列協(xié)議)基礎(chǔ)上完成的莫杈，可復(fù)用的企業(yè)消息系統(tǒng)互例，是當(dāng)前最主流的消息中間件之一。

RabbitMQ優(yōu)點(diǎn)：

由于erlang語言的特性筝闹，mq 性能較好媳叨，高并發(fā)；

吞吐量到萬級(jí)丁存，MQ功能比較完備

健壯肩杈、穩(wěn)定、易用解寝、跨平臺(tái)扩然、支持多種語言、文檔齊全聋伦；

開源提供的管理界面非常棒夫偶，用起來很好用

社區(qū)活躍度高；

RabbitMQ缺點(diǎn)：

erlang開發(fā)觉增，很難去看懂源碼兵拢，基本職能依賴于開源社區(qū)的快速維護(hù)和修復(fù)bug，不利于做二次開發(fā)和維護(hù)逾礁。

RabbitMQ確實(shí)吞吐量會(huì)低一些顽爹，這是因?yàn)樗龅膶?shí)現(xiàn)機(jī)制比較重。

需要學(xué)習(xí)比較復(fù)雜的接口和協(xié)議个少，學(xué)習(xí)和維護(hù)成本較高惯吕。

4.RocketMQ

RocketMQ出自 阿里公司的開源產(chǎn)品循狰，用 Java 語言實(shí)現(xiàn)，在設(shè)計(jì)時(shí)參考了 Kafka，并做出了自己的一些改進(jìn)。

RocketMQ在阿里集團(tuán)被廣泛應(yīng)用在訂單窒篱，交易，充值舶沿，流計(jì)算墙杯，消息推送，日志流式處理括荡，binglog分發(fā)等場(chǎng)景高镐。

RocketMQ優(yōu)點(diǎn)：

單機(jī)吞吐量：十萬級(jí)

可用性：非常高，分布式架構(gòu)

消息可靠性：經(jīng)過參數(shù)優(yōu)化配置畸冲，消息可以做到0丟失

功能支持：MQ功能較為完善避消，還是分布式的，擴(kuò)展性好

支持10億級(jí)別的消息堆積召夹，不會(huì)因?yàn)槎逊e導(dǎo)致性能下降

源碼是java，我們可以自己閱讀源碼恕沫，定制自己公司的MQ监憎，可以掌控

RocketMQ缺點(diǎn)：

支持的客戶端語言不多，目前是java及c++婶溯，其中c++不成熟鲸阔；

社區(qū)活躍度一般

沒有在 mq 核心中去實(shí)現(xiàn)JMS等接口，有些系統(tǒng)要遷移需要修改大量代碼

消息隊(duì)列選擇建議

1.Kafka

Kafka主要特點(diǎn)是基于Pull的模式來處理消息消費(fèi)迄委，追求高吞吐量褐筛，一開始的目的就是用于日志收集和傳輸，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)叙身。

大型公司建議可以選用渔扎，如果有日志采集功能，肯定是首選kafka了信轿。

2.RocketMQ

天生為金融互聯(lián)網(wǎng)領(lǐng)域而生晃痴，對(duì)于可靠性要求很高的場(chǎng)景，尤其是電商里面的訂單扣款财忽，以及業(yè)務(wù)削峰倘核，在大量交易涌入時(shí)，后端可能無法及時(shí)處理的情況即彪。

RoketMQ在穩(wěn)定性上可能更值得信賴紧唱，這些業(yè)務(wù)場(chǎng)景在阿里雙11已經(jīng)經(jīng)歷了多次考驗(yàn)，如果你的業(yè)務(wù)有上述并發(fā)場(chǎng)景，建議可以選擇RocketMQ漏益。

3.RabbitMQ

RabbitMQ :結(jié)合erlang語言本身的并發(fā)優(yōu)勢(shì)蛹锰，性能較好，社區(qū)活躍度也比較高遭庶，但是不利于做二次開發(fā)和維護(hù)宁仔。不過，RabbitMQ的社區(qū)十分活躍峦睡，可以解決開發(fā)過程中遇到的bug翎苫。

如果你的數(shù)據(jù)量沒有那么大，小公司優(yōu)先選擇功能比較完備的RabbitMQ榨了。

作者：MikeChen架構(gòu)筆記
鏈接：http://www.reibang.com/p/fec054f3e496
來源：簡(jiǎn)書
著作權(quán)歸作者所有煎谍。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處龙屉。

補(bǔ)充

1.1 特性
RocketMQ：

NameServer:整個(gè)MQ集群提供服務(wù)協(xié)調(diào)與治理呐粘，具體就是記錄維護(hù)Topic、Broker的信息转捕，及監(jiān)控Broker的運(yùn)行狀態(tài)作岖，Name Server是一個(gè)幾乎無狀態(tài)節(jié)點(diǎn)，可集群部署五芝，節(jié)點(diǎn)之間無任何信息同步痘儡，相當(dāng)于注冊(cè)中心.
Broker:消息服務(wù)器，作為server提供消息核心服務(wù)枢步，每個(gè)Broker與Name Server集群中的所有節(jié)點(diǎn)建立長(zhǎng)連接沉删，定時(shí)注冊(cè)Topic信息到所有Name Server；
Producer:消息生產(chǎn)者醉途，業(yè)務(wù)的發(fā)起方矾瑰，負(fù)責(zé)生產(chǎn)消息傳輸給broker.
Consumer:消息消費(fèi)者，業(yè)務(wù)的處理方隘擎，負(fù)責(zé)從broker獲取消息并進(jìn)行業(yè)務(wù)邏輯處理
RabbitMQ:

Exchange:交換機(jī)的作用就是根據(jù)路由規(guī)則殴穴，將消息轉(zhuǎn)發(fā)到對(duì)應(yīng)的隊(duì)列上。.
Broker:消息服務(wù)器嵌屎，作為server提供消息核心服務(wù)
Channel:信道是建立在真實(shí)的TCP連接內(nèi)的虛擬連接.
Routing key:生產(chǎn)者將消息發(fā)送到交換機(jī)時(shí)推正，會(huì)在消息頭上攜帶一個(gè) key，這個(gè) key就是routing key宝惰，來指定這個(gè)消息的路由規(guī)則植榕。
Binding key:在綁定Exchange與Queue時(shí)，一般會(huì)指定一個(gè)binding key尼夺，生產(chǎn)者將消息發(fā)送給Exchange時(shí)尊残，消息頭上會(huì)攜帶一個(gè)routing key炒瘸，當(dāng)binding key與routing key相匹配時(shí)，消息將會(huì)被路由到對(duì)應(yīng)的Queue中寝衫。
1.2 重復(fù)消費(fèi)
正常情況下顷扩，消費(fèi)者在消費(fèi)消息的時(shí)候，消費(fèi)完畢后慰毅，會(huì)發(fā)送一個(gè)確認(rèn)消息給消息隊(duì)列隘截，消息隊(duì)列就知道該消息被消費(fèi)了，就會(huì)將該消息從消息隊(duì)列中刪除汹胃； 但是因?yàn)榫W(wǎng)絡(luò)傳輸?shù)鹊裙收仙舭牛_認(rèn)信息沒有傳送到消息隊(duì)列，導(dǎo)致消息隊(duì)列不知道自己已經(jīng)消費(fèi)過該消息了着饥，再次將消息分發(fā)給其他的消費(fèi)者犀农。

保證消息的唯一性，就算是多次傳輸宰掉，不要讓消息的多次消費(fèi)帶來影響呵哨；保證消息等冪性；

1.3 丟失數(shù)據(jù)
RocketMQ：

生產(chǎn)者丟數(shù)據(jù)：（1）采取send()同步發(fā)消息轨奄，發(fā)送結(jié)果是同步感知的孟害。發(fā)送失敗后可以重試，設(shè)置重試次數(shù)挪拟。默認(rèn)3次纹坐。（2）發(fā)送失敗的消息會(huì)存儲(chǔ)在Commitlog中。
消息隊(duì)列丟數(shù)據(jù)：（1）消息支持持久化到Commitlog里面舞丛，即使宕機(jī)后重啟，未消費(fèi)的消息也是可以加載出來的果漾；（2）Broker自身支持同步刷盤球切、異步刷盤的策略，可以保證接收到的消息一定存儲(chǔ)在本地的內(nèi)存中绒障；（3）Broker集群支持 1主N從的策略吨凑，支持同步復(fù)制和異步復(fù)制的方式，同步復(fù)制可以保證即使Master 磁盤崩潰户辱，消息仍然不會(huì)丟失
消費(fèi)者丟失數(shù)據(jù)：（1）完全成功后發(fā)送ACK鸵钝；（2）維護(hù)一個(gè)持久化的offset
RabbitMQ:

生產(chǎn)者丟數(shù)據(jù)：RabbitMQ提供transaction（事務(wù)，支持回滾）和confirm模式（ACK給生產(chǎn)者）來確保生產(chǎn)者不丟消息庐镐；
消息隊(duì)列丟數(shù)據(jù)：開啟rabbitmq的持久化恩商，就是消息寫入之后會(huì)持久化到磁盤，持久化可以跟生產(chǎn)者那邊的confirm機(jī)制配合起來必逆，只有消息被持久化到磁盤之后怠堪，才會(huì)通知生產(chǎn)者ack揽乱。
消費(fèi)者丟失數(shù)據(jù)：消費(fèi)者丟數(shù)據(jù)一般是因?yàn)椴捎昧俗詣?dòng)確認(rèn)消息模式，改為手動(dòng)確認(rèn)消息粟矿，處理消息成功后凰棉，手動(dòng)回復(fù)確認(rèn)消息。
1.4 消費(fèi)順序
主要思路有兩種：1陌粹、單線程消費(fèi)來保證消息的順序性撒犀；2、對(duì)消息進(jìn)行編號(hào)掏秩，消費(fèi)者處理時(shí)根據(jù)編號(hào)判斷順序或舞。

每個(gè)queue的數(shù)據(jù)本身就是有序的，只要消費(fèi)者這邊有序消費(fèi)哗讥，那么可以保證數(shù)據(jù)被順序消費(fèi)嚷那。如果是多線程消費(fèi)，就要consumer內(nèi)部用內(nèi)存隊(duì)列做排隊(duì)杆煞。

1.5 高可用
RocketMQ：

多Master：配置簡(jiǎn)單魏宽，性能最高，但可能會(huì)有少量消息丟失（配置相關(guān)）决乎，單臺(tái)機(jī)器重啟或宕機(jī)期間队询，該機(jī)器下未被消費(fèi)的消息在機(jī)器恢復(fù)前不可訂閱，影響消息實(shí)時(shí)性
多Master多Slave異步模式：每個(gè)Master配一個(gè)Slave构诚，有多對(duì)Master-Slave蚌斩，消息寫入全部是發(fā)送到Master Broker的，獲取消息也可以Master獲取范嘱，少了Slave Broker送膳，會(huì)導(dǎo)致所有讀寫壓力都集中在Master Broker，集群采用異步復(fù)制方式丑蛤，主備有短暫消息延遲叠聋，毫秒級(jí)；性能同多Master幾乎一樣受裹，實(shí)時(shí)性高碌补，主備間切換對(duì)應(yīng)用透明，不需人工干預(yù)棉饶，但Master宕機(jī)或磁盤損壞時(shí)會(huì)有少量消息丟失厦章；
多Master多Slave同步模式：每個(gè)Master配一個(gè)Slave，有多對(duì)Master-Slave照藻，消息寫入全部是發(fā)送到Master Broker的袜啃，獲取消息也可以Master獲取，少了Slave Broker幸缕，會(huì)導(dǎo)致所有讀寫壓力都集中在Master Broker囊骤，集群采用同步雙寫方式晃择，主備都寫成功，向應(yīng)用返回成功也物；優(yōu)點(diǎn)是服務(wù)可用性與數(shù)據(jù)可用性非常高宫屠；缺點(diǎn)是性能比異步集群略低，當(dāng)前版本主宕備不能自動(dòng)切換為主滑蚯。
RabbitMQ:

普通集群模式：多臺(tái)機(jī)器上啟動(dòng)多個(gè)rabbitmq實(shí)例浪蹂，每個(gè)機(jī)器啟動(dòng)一個(gè)。但是你創(chuàng)建的queue告材，只會(huì)放在一個(gè)rabbtimq實(shí)例上坤次，但是每個(gè)實(shí)例都同步queue的元數(shù)據(jù)。完了你消費(fèi)的時(shí)候斥赋，實(shí)際上如果連接到了另外一個(gè)實(shí)例缰猴，那么那個(gè)實(shí)例會(huì)從queue所在實(shí)例上拉取數(shù)據(jù)過來。如果那個(gè)放queue的實(shí)例宕機(jī)了疤剑，會(huì)導(dǎo)致接下來其他實(shí)例就無法從那個(gè)實(shí)例拉取滑绒，如果你開啟了消息持久化，讓rabbitmq落地存儲(chǔ)消息的話隘膘，消息不一定會(huì)丟疑故，得等這個(gè)實(shí)例恢復(fù)了，然后才可以繼續(xù)從這個(gè)queue拉取數(shù)據(jù)弯菊。
鏡像集群模式：創(chuàng)建的queue纵势，無論元數(shù)據(jù)還是queue里的消息都會(huì)存在于多個(gè)實(shí)例上，然后每次寫消息到queue的時(shí)候管钳，都會(huì)自動(dòng)把消息到多個(gè)實(shí)例的queue里進(jìn)行消息同步钦铁。缺點(diǎn):（1）性能開銷大，因?yàn)樾枰M(jìn)行整個(gè)集群內(nèi)部所有實(shí)例的數(shù)據(jù)同步才漆；（2）無法線性擴(kuò)容: 因?yàn)槊恳粋€(gè)服務(wù)器中都包含整個(gè)集群服務(wù)節(jié)點(diǎn)中的所有數(shù)據(jù), 這樣如果一旦單個(gè)服務(wù)器節(jié)點(diǎn)的容量無法容納了育瓜。