為什么使用MQ薄声？MQ的優(yōu)點(diǎn)

簡答

• 異步處理 - 相比于傳統(tǒng)的串行锡垄、并行方式，提高了系統(tǒng)吞吐量来破。
• 應(yīng)用解耦 - 系統(tǒng)間通過消息通信篮灼，不用關(guān)心其他系統(tǒng)的處理。
• 流量削鋒 - 可以通過消息隊(duì)列長度控制請求量徘禁；可以緩解短時(shí)間內(nèi)的高并發(fā)請求诅诱。
• 日志處理 - 解決大量日志傳輸。
• 消息通訊 - 消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制送朱，因此也可以用在純的消息通訊匠抗。比如實(shí)現(xiàn)點(diǎn)對點(diǎn)消息隊(duì)列臀晃，或者聊天室等养渴。

詳答

主要是：解耦敦第、異步、削峰回怜。

解耦：A 系統(tǒng)發(fā)送數(shù)據(jù)到 BCD 三個(gè)系統(tǒng)大年，通過接口調(diào)用發(fā)送。如果 E 系統(tǒng)也要這個(gè)數(shù)據(jù)呢玉雾？那如果 C 系統(tǒng)現(xiàn)在不需要了呢翔试？A 系統(tǒng)負(fù)責(zé)人幾乎崩潰…A 系統(tǒng)跟其它各種亂七八糟的系統(tǒng)嚴(yán)重耦合，A 系統(tǒng)產(chǎn)生一條比較關(guān)鍵的數(shù)據(jù)复旬，很多系統(tǒng)都需要 A 系統(tǒng)將這個(gè)數(shù)據(jù)發(fā)送過來垦缅。如果使用 MQ，A 系統(tǒng)產(chǎn)生一條數(shù)據(jù)赢底，發(fā)送到 MQ 里面去失都，哪個(gè)系統(tǒng)需要數(shù)據(jù)自己去 MQ 里面消費(fèi)柏蘑。如果新系統(tǒng)需要數(shù)據(jù)幸冻，直接從 MQ 里消費(fèi)即可；如果某個(gè)系統(tǒng)不需要這條數(shù)據(jù)了咳焚，就取消對 MQ 消息的消費(fèi)即可洽损。這樣下來，A 系統(tǒng)壓根兒不需要去考慮要給誰發(fā)送數(shù)據(jù)革半，不需要維護(hù)這個(gè)代碼碑定，也不需要考慮人家是否調(diào)用成功、失敗超時(shí)等情況又官。

就是一個(gè)系統(tǒng)或者一個(gè)模塊延刘，調(diào)用了多個(gè)系統(tǒng)或者模塊，互相之間的調(diào)用很復(fù)雜六敬，維護(hù)起來很麻煩碘赖。但是其實(shí)這個(gè)調(diào)用是不需要直接同步調(diào)用接口的，如果用 MQ 給它異步化解耦。

異步：A 系統(tǒng)接收一個(gè)請求普泡，需要在自己本地寫庫播掷，還需要在 BCD 三個(gè)系統(tǒng)寫庫，自己本地寫庫要 3ms撼班，BCD 三個(gè)系統(tǒng)分別寫庫要 300ms歧匈、450ms、200ms砰嘁。最終請求總延時(shí)是 3 + 300 + 450 + 200 = 953ms件炉，接近 1s，用戶感覺搞個(gè)什么東西般码，慢死了慢死了妻率。用戶通過瀏覽器發(fā)起請求。如果使用 MQ板祝，那么 A 系統(tǒng)連續(xù)發(fā)送 3 條消息到 MQ 隊(duì)列中宫静，假如耗時(shí) 5ms，A 系統(tǒng)從接受一個(gè)請求到返回響應(yīng)給用戶券时，總時(shí)長是 3 + 5 = 8ms孤里。

削峰：減少高峰時(shí)期對服務(wù)器壓力。

消息隊(duì)列有什么優(yōu)缺點(diǎn)橘洞？RabbitMQ有什么優(yōu)缺點(diǎn)捌袜？

優(yōu)點(diǎn)上面已經(jīng)說了，就是在特殊場景下有其對應(yīng)的好處炸枣，解耦虏等、異步、削峰适肠。

缺點(diǎn)有以下幾個(gè)：

系統(tǒng)可用性降低

本來系統(tǒng)運(yùn)行好好的霍衫，現(xiàn)在你非要加入個(gè)消息隊(duì)列進(jìn)去，那消息隊(duì)列掛了侯养，你的系統(tǒng)不是呵呵了敦跌。因此，系統(tǒng)可用性會(huì)降低逛揩；

系統(tǒng)復(fù)雜度提高

加入了消息隊(duì)列柠傍，要多考慮很多方面的問題，比如：一致性問題辩稽、如何保證消息不被重復(fù)消費(fèi)惧笛、如何保證消息可靠性傳輸?shù)取Ｒ虼顺研梗枰紤]的東西更多患整，復(fù)雜性增大静檬。

一致性問題

A 系統(tǒng)處理完了直接返回成功了，人都以為你這個(gè)請求就成功了并级；但是問題是拂檩，要是 BCD 三個(gè)系統(tǒng)那里，BD 兩個(gè)系統(tǒng)寫庫成功了嘲碧，結(jié)果 C 系統(tǒng)寫庫失敗了稻励，咋整？你這數(shù)據(jù)就不一致了愈涩。

所以消息隊(duì)列實(shí)際是一種非常復(fù)雜的架構(gòu)望抽，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術(shù)方案和架構(gòu)來規(guī)避掉履婉，做好之后煤篙，你會(huì)發(fā)現(xiàn)，媽呀毁腿，系統(tǒng)復(fù)雜度提升了一個(gè)數(shù)量級辑奈，也許是復(fù)雜了 10 倍已烤。但是關(guān)鍵時(shí)刻鸠窗，用，還是得用的胯究。

你們公司生產(chǎn)環(huán)境用的是什么消息中間件稍计？

這個(gè)首先你可以說下你們公司選用的是什么消息中間件，比如用的是RabbitMQ裕循，然后可以初步給一些你對不同MQ中間件技術(shù)的選型分析臣嚣。

舉個(gè)例子：比如說ActiveMQ是老牌的消息中間件，國內(nèi)很多公司過去運(yùn)用的還是非常廣泛的剥哑，功能很強(qiáng)大硅则。

但是問題在于沒法確認(rèn)ActiveMQ可以支撐互聯(lián)網(wǎng)公司的高并發(fā)、高負(fù)載以及高吞吐的復(fù)雜場景星持，在國內(nèi)互聯(lián)網(wǎng)公司落地較少抢埋。而且使用較多的是一些傳統(tǒng)企業(yè)弹灭，用ActiveMQ做異步調(diào)用和系統(tǒng)解耦督暂。

然后你可以說說RabbitMQ，他的好處在于可以支撐高并發(fā)穷吮、高吞吐逻翁、性能很高，同時(shí)有非常完善便捷的后臺(tái)管理界面可以使用捡鱼。

另外八回，他還支持集群化、高可用部署架構(gòu)、消息高可靠支持缠诅，功能較為完善溶浴。

而且經(jīng)過調(diào)研，國內(nèi)各大互聯(lián)網(wǎng)公司落地大規(guī)模RabbitMQ集群支撐自身業(yè)務(wù)的case較多管引，國內(nèi)各種中小型互聯(lián)網(wǎng)公司使用RabbitMQ的實(shí)踐也比較多士败。

除此之外，RabbitMQ的開源社區(qū)很活躍褥伴，較高頻率的迭代版本谅将，來修復(fù)發(fā)現(xiàn)的bug以及進(jìn)行各種優(yōu)化，因此綜合考慮過后重慢，公司采取了RabbitMQ饥臂。

但是RabbitMQ也有一點(diǎn)缺陷，就是他自身是基于erlang語言開發(fā)的似踱，所以導(dǎo)致較為難以分析里面的源碼隅熙，也較難進(jìn)行深層次的源碼定制和改造，畢竟需要較為扎實(shí)的erlang語言功底才可以核芽。

然后可以聊聊RocketMQ猛们，是阿里開源的，經(jīng)過阿里的生產(chǎn)環(huán)境的超高并發(fā)狞洋、高吞吐的考驗(yàn)弯淘，性能卓越，同時(shí)還支持分布式事務(wù)等特殊場景吉懊。

而且RocketMQ是基于Java語言開發(fā)的庐橙，適合深入閱讀源碼，有需要可以站在源碼層面解決線上生產(chǎn)問題借嗽，包括源碼的二次開發(fā)和改造态鳖。

另外就是Kafka。Kafka提供的消息中間件的功能明顯較少一些恶导，相對上述幾款MQ中間件要少很多浆竭。

但是Kafka的優(yōu)勢在于專為超高吞吐量的實(shí)時(shí)日志采集、實(shí)時(shí)數(shù)據(jù)同步惨寿、實(shí)時(shí)數(shù)據(jù)計(jì)算等場景來設(shè)計(jì)邦泄。

因此Kafka在大數(shù)據(jù)領(lǐng)域中配合實(shí)時(shí)計(jì)算技術(shù)（比如Spark Streaming、Storm裂垦、Flink）使用的較多顺囊。但是在傳統(tǒng)的MQ中間件使用場景中較少采用。

Kafka蕉拢、ActiveMQ特碳、RabbitMQ诚亚、RocketMQ 有什么優(yōu)缺點(diǎn)？

綜上耳鸯，各種對比之后，有如下建議：

一般的業(yè)務(wù)系統(tǒng)要引入 MQ膀曾，最早大家都用 ActiveMQ县爬，但是現(xiàn)在確實(shí)大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗(yàn)證添谊，社區(qū)也不是很活躍财喳，所以大家還是算了吧，我個(gè)人不推薦用這個(gè)了斩狱；

后來大家開始用 RabbitMQ耳高，但是確實(shí) erlang 語言阻止了大量的 Java 工程師去深入研究和掌控它，對公司而言所踊，幾乎處于不可控的狀態(tài)泌枪，但是確實(shí)人家是開源的，比較穩(wěn)定的支持秕岛，活躍度也高碌燕；

不過現(xiàn)在確實(shí)越來越多的公司會(huì)去用 RocketMQ，確實(shí)很不錯(cuò)继薛，畢竟是阿里出品修壕，但社區(qū)可能有突然黃掉的風(fēng)險(xiǎn)（目前 RocketMQ 已捐給 Apache，但 GitHub 上的活躍度其實(shí)不算高）對自己公司技術(shù)實(shí)力有絕對自信的惋增，推薦用 RocketMQ叠殷，否則回去老老實(shí)實(shí)用 RabbitMQ 吧改鲫，人家有活躍的開源社區(qū)诈皿，絕對不會(huì)黃林束。

所以中小型公司，技術(shù)實(shí)力較為一般稽亏，技術(shù)挑戰(zhàn)不是特別高壶冒，用 RabbitMQ 是不錯(cuò)的選擇；大型公司截歉，基礎(chǔ)架構(gòu)研發(fā)實(shí)力較強(qiáng)胖腾，用 RocketMQ 是很好的選擇。

如果是大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算瘪松、日志采集等場景咸作，用 Kafka 是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對沒問題宵睦，社區(qū)活躍度很高记罚，絕對不會(huì)黃，何況幾乎是全世界這個(gè)領(lǐng)域的事實(shí)性規(guī)范壳嚎。

MQ 有哪些常見問題桐智？如何解決這些問題？

MQ 的常見問題有：

1. 消息的順序問題
2. 消息的重復(fù)問題

消息的順序問題

消息有序指的是可以按照消息的發(fā)送順序來消費(fèi)烟馅。

假如生產(chǎn)者產(chǎn)生了 2 條消息：M1说庭、M2，假定 M1 發(fā)送到 S1郑趁，M2 發(fā)送到 S2刊驴，如果要保證 M1 先于 M2 被消費(fèi)，怎么做寡润？

img

解決方案：

（1）保證生產(chǎn)者 - MQServer - 消費(fèi)者是一對一對一的關(guān)系

img

缺陷：

• 并行度就會(huì)成為消息系統(tǒng)的瓶頸（吞吐量不夠）
• 更多的異常處理缺脉，比如：只要消費(fèi)端出現(xiàn)問題，就會(huì)導(dǎo)致整個(gè)處理流程阻塞悦穿，我們不得不花費(fèi)更多的精力來解決阻塞的問題攻礼。 （2）通過合理的設(shè)計(jì)或者將問題分解來規(guī)避。
• 不關(guān)注亂序的應(yīng)用實(shí)際大量存在
• 隊(duì)列無序并不意味著消息無序 所以從業(yè)務(wù)層面來保證消息的順序而不僅僅是依賴于消息系統(tǒng)栗柒，是一種更合理的方式礁扮。

消息的重復(fù)問題

造成消息重復(fù)的根本原因是：網(wǎng)絡(luò)不可達(dá)。

所以解決這個(gè)問題的辦法就是繞過這個(gè)問題瞬沦。那么問題就變成了：如果消費(fèi)端收到兩條一樣的消息太伊，應(yīng)該怎樣處理？

消費(fèi)端處理消息的業(yè)務(wù)邏輯保持冪等性逛钻。只要保持冪等性僚焦，不管來多少條重復(fù)消息，最后處理的結(jié)果都一樣曙痘。保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時(shí)出現(xiàn)芳悲。利用一張日志表來記錄已經(jīng)處理成功的消息的 ID立肘，如果新到的消息 ID 已經(jīng)在日志表中，那么就不再處理這條消息名扛。

什么是RabbitMQ谅年？

RabbitMQ是一款開源的，Erlang編寫的肮韧，基于AMQP協(xié)議的消息中間件

rabbitmq 的使用場景

（1）服務(wù)間異步通信

（2）順序消費(fèi)

（3）定時(shí)任務(wù)

（4）請求削峰

RabbitMQ基本概念

• Broker： 簡單來說就是消息隊(duì)列服務(wù)器實(shí)體
• Exchange： 消息交換機(jī)融蹂，它指定消息按什么規(guī)則，路由到哪個(gè)隊(duì)列
• Queue： 消息隊(duì)列載體弄企，每個(gè)消息都會(huì)被投入到一個(gè)或多個(gè)隊(duì)列
• Binding： 綁定超燃，它的作用就是把exchange和queue按照路由規(guī)則綁定起來
• Routing Key： 路由關(guān)鍵字，exchange根據(jù)這個(gè)關(guān)鍵字進(jìn)行消息投遞
• VHost： vhost 可以理解為虛擬 broker 拘领，即 mini-RabbitMQ server淋纲。其內(nèi)部均含有獨(dú)立的 queue、exchange 和 binding 等院究，但最最重要的是洽瞬，其擁有獨(dú)立的權(quán)限系統(tǒng)，可以做到 vhost 范圍的用戶控制业汰。當(dāng)然伙窃，從 RabbitMQ 的全局角度，vhost 可以作為不同權(quán)限隔離的手段（一個(gè)典型的例子就是不同的應(yīng)用可以跑在不同的 vhost 中）样漆。
• Producer： 消息生產(chǎn)者为障，就是投遞消息的程序
• Consumer： 消息消費(fèi)者，就是接受消息的程序
• Channel： 消息通道放祟，在客戶端的每個(gè)連接里鳍怨，可建立多個(gè)channel，每個(gè)channel代表一個(gè)會(huì)話任務(wù)

由Exchange跪妥、Queue鞋喇、RoutingKey三個(gè)才能決定一個(gè)從Exchange到Queue的唯一的線路。

RabbitMQ的工作模式

一.simple模式（即最簡單的收發(fā)模式）

img

1.消息產(chǎn)生消息眉撵，將消息放入隊(duì)列

2.消息的消費(fèi)者(consumer) 監(jiān)聽 消息隊(duì)列,如果隊(duì)列中有消息,就消費(fèi)掉,消息被拿走后,自動(dòng)從隊(duì)列中刪除(隱患 消息可能沒有被消費(fèi)者正確處理,已經(jīng)從隊(duì)列中消失了,造成消息的丟失侦香，這里可以設(shè)置成手動(dòng)的ack,但如果設(shè)置成手動(dòng)ack，處理完后要及時(shí)發(fā)送ack消息給隊(duì)列纽疟，否則會(huì)造成內(nèi)存溢出)罐韩。

二.work工作模式(資源的競爭)

img

1.消息產(chǎn)生者將消息放入隊(duì)列消費(fèi)者可以有多個(gè),消費(fèi)者1,消費(fèi)者2同時(shí)監(jiān)聽同一個(gè)隊(duì)列,消息被消費(fèi)。C1 C2共同爭搶當(dāng)前的消息隊(duì)列內(nèi)容,誰先拿到誰負(fù)責(zé)消費(fèi)消息(隱患：高并發(fā)情況下,默認(rèn)會(huì)產(chǎn)生某一個(gè)消息被多個(gè)消費(fèi)者共同使用,可以設(shè)置一個(gè)開關(guān)(syncronize) 保證一條消息只能被一個(gè)消費(fèi)者使用)污朽。

三.publish/subscribe發(fā)布訂閱(共享資源)

img

1散吵、每個(gè)消費(fèi)者監(jiān)聽自己的隊(duì)列；

2、生產(chǎn)者將消息發(fā)給broker矾睦，由交換機(jī)將消息轉(zhuǎn)發(fā)到綁定此交換機(jī)的每個(gè)隊(duì)列晦款，每個(gè)綁定交換機(jī)的隊(duì)列都將接收到消息。

四.routing路由模式

img

1.消息生產(chǎn)者將消息發(fā)送給交換機(jī)按照路由判斷,路由是字符串(info) 當(dāng)前產(chǎn)生的消息攜帶路由字符(對象的方法),交換機(jī)根據(jù)路由的key,只能匹配上路由key對應(yīng)的消息隊(duì)列,對應(yīng)的消費(fèi)者才能消費(fèi)消息;

2.根據(jù)業(yè)務(wù)功能定義路由字符串

3.從系統(tǒng)的代碼邏輯中獲取對應(yīng)的功能字符串,將消息任務(wù)扔到對應(yīng)的隊(duì)列中顷锰。

4.業(yè)務(wù)場景:error 通知;EXCEPTION;錯(cuò)誤通知的功能;傳統(tǒng)意義的錯(cuò)誤通知;客戶通知;利用key路由,可以將程序中的錯(cuò)誤封裝成消息傳入到消息隊(duì)列中,開發(fā)者可以自定義消費(fèi)者,實(shí)時(shí)接收錯(cuò)誤;

五.topic 主題模式(路由模式的一種)

img

1.星號井號代表通配符

2.星號代表多個(gè)單詞,井號代表一個(gè)單詞

3.路由功能添加模糊匹配

4.消息產(chǎn)生者產(chǎn)生消息,把消息交給交換機(jī)

5.交換機(jī)根據(jù)key的規(guī)則模糊匹配到對應(yīng)的隊(duì)列,由隊(duì)列的監(jiān)聽消費(fèi)者接收消息消費(fèi)

（在我的理解看來就是routing查詢的一種模糊匹配柬赐，就類似sql的模糊查詢方式）

如何保證RabbitMQ消息的順序性亡问？

拆分多個(gè) queue官紫，每個(gè) queue 一個(gè) consumer，就是多一些 queue 而已州藕，確實(shí)是麻煩點(diǎn)束世；或者就一個(gè) queue 但是對應(yīng)一個(gè) consumer，然后這個(gè) consumer 內(nèi)部用內(nèi)存隊(duì)列做排隊(duì)床玻，然后分發(fā)給底層不同的 worker 來處理毁涉。

消息如何分發(fā)？

若該隊(duì)列至少有一個(gè)消費(fèi)者訂閱锈死，消息將以循環(huán)（round-robin）的方式發(fā)送給消費(fèi)者贫堰。每條消息只會(huì)分發(fā)給一個(gè)訂閱的消費(fèi)者（前提是消費(fèi)者能夠正常處理消息并進(jìn)行確認(rèn)）。通過路由可實(shí)現(xiàn)多消費(fèi)的功能

消息怎么路由待牵？

消息提供方->路由->一至多個(gè)隊(duì)列消息發(fā)布到交換器時(shí)其屏，消息將擁有一個(gè)路由鍵（routing key），在消息創(chuàng)建時(shí)設(shè)定缨该。通過隊(duì)列路由鍵偎行，可以把隊(duì)列綁定到交換器上。消息到達(dá)交換器后贰拿，RabbitMQ 會(huì)將消息的路由鍵與隊(duì)列的路由鍵進(jìn)行匹配（針對不同的交換器有不同的路由規(guī)則）蛤袒；

常用的交換器主要分為一下三種：

fanout：如果交換器收到消息，將會(huì)廣播到所有綁定的隊(duì)列上

direct：如果路由鍵完全匹配膨更，消息就被投遞到相應(yīng)的隊(duì)列

topic：可以使來自不同源頭的消息能夠到達(dá)同一個(gè)隊(duì)列妙真。 使用 topic 交換器時(shí)，可以使用通配符

消息基于什么傳輸荚守？

由于 TCP 連接的創(chuàng)建和銷毀開銷較大隐孽，且并發(fā)數(shù)受系統(tǒng)資源限制，會(huì)造成性能瓶頸健蕊。RabbitMQ 使用信道的方式來傳輸數(shù)據(jù)菱阵。信道是建立在真實(shí)的 TCP 連接內(nèi)的虛擬連接，且每條 TCP 連接上的信道數(shù)量沒有限制缩功。

如何保證消息不被重復(fù)消費(fèi)晴及？或者說，如何保證消息消費(fèi)時(shí)的冪等性嫡锌？

先說為什么會(huì)重復(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)者且改。

針對以上問題验烧，一個(gè)解決思路是：保證消息的唯一性，就算是多次傳輸又跛，不要讓消息的多次消費(fèi)帶來影響碍拆；保證消息等冪性；

比如：在寫入消息隊(duì)列的數(shù)據(jù)做唯一標(biāo)示慨蓝，消費(fèi)消息時(shí)感混，根據(jù)唯一標(biāo)識判斷是否消費(fèi)過；

假設(shè)你有個(gè)系統(tǒng)礼烈，消費(fèi)一條消息就往數(shù)據(jù)庫里插入一條數(shù)據(jù)弧满，要是你一個(gè)消息重復(fù)兩次，你不就插入了兩條济丘，這數(shù)據(jù)不就錯(cuò)了谱秽？但是你要是消費(fèi)到第二次的時(shí)候，自己判斷一下是否已經(jīng)消費(fèi)過了摹迷，若是就直接扔了疟赊，這樣不就保留了一條數(shù)據(jù)，從而保證了數(shù)據(jù)的正確性峡碉。

如何確保消息正確地發(fā)送至 RabbitMQ近哟？ 如何確保消息接收方消費(fèi)了消息？

發(fā)送方確認(rèn)模式

將信道設(shè)置成 confirm 模式（發(fā)送方確認(rèn)模式）鲫寄，則所有在信道上發(fā)布的消息都會(huì)被指派一個(gè)唯一的 ID吉执。

一旦消息被投遞到目的隊(duì)列后，或者消息被寫入磁盤后（可持久化的消息）地来，信道會(huì)發(fā)送一個(gè)確認(rèn)給生產(chǎn)者（包含消息唯一 ID）戳玫。

如果 RabbitMQ 發(fā)生內(nèi)部錯(cuò)誤從而導(dǎo)致消息丟失，會(huì)發(fā)送一條 nack（notacknowledged未斑，未確認(rèn)）消息咕宿。

發(fā)送方確認(rèn)模式是異步的，生產(chǎn)者應(yīng)用程序在等待確認(rèn)的同時(shí)，可以繼續(xù)發(fā)送消息府阀。當(dāng)確認(rèn)消息到達(dá)生產(chǎn)者應(yīng)用程序缆镣，生產(chǎn)者應(yīng)用程序的回調(diào)方法就會(huì)被觸發(fā)來處理確認(rèn)消息。

接收方確認(rèn)機(jī)制

消費(fèi)者接收每一條消息后都必須進(jìn)行確認(rèn)（消息接收和消息確認(rèn)是兩個(gè)不同操作）试浙。只有消費(fèi)者確認(rèn)了消息董瞻，RabbitMQ 才能安全地把消息從隊(duì)列中刪除。

這里并沒有用到超時(shí)機(jī)制田巴，RabbitMQ 僅通過 Consumer 的連接中斷來確認(rèn)是否需要重新發(fā)送消息钠糊。也就是說，只要連接不中斷固额，RabbitMQ 給了 Consumer 足夠長的時(shí)間來處理消息眠蚂。保證數(shù)據(jù)的最終一致性煞聪；

下面羅列幾種特殊情況

• 如果消費(fèi)者接收到消息斗躏，在確認(rèn)之前斷開了連接或取消訂閱，RabbitMQ 會(huì)認(rèn)為消息沒有被分發(fā)昔脯，然后重新分發(fā)給下一個(gè)訂閱的消費(fèi)者啄糙。（可能存在消息重復(fù)消費(fèi)的隱患，需要去重）
• 如果消費(fèi)者接收到消息卻沒有確認(rèn)消息云稚，連接也未斷開隧饼，則 RabbitMQ 認(rèn)為該消費(fèi)者繁忙，將不會(huì)給該消費(fèi)者分發(fā)更多的消息静陈。

如何保證RabbitMQ消息的可靠傳輸燕雁？

消息不可靠的情況可能是消息丟失，劫持等原因鲸拥；

丟失又分為：生產(chǎn)者丟失消息拐格、消息列表丟失消息、消費(fèi)者丟失消息刑赶；

生產(chǎn)者丟失消息：從生產(chǎn)者弄丟數(shù)據(jù)這個(gè)角度來看捏浊，RabbitMQ提供transaction和confirm模式來確保生產(chǎn)者不丟消息；

transaction機(jī)制就是說：發(fā)送消息前撞叨，開啟事務(wù)（channel.txSelect()）,然后發(fā)送消息金踪，如果發(fā)送過程中出現(xiàn)什么異常，事務(wù)就會(huì)回滾（channel.txRollback()）,如果發(fā)送成功則提交事務(wù)（channel.txCommit()）牵敷。然而胡岔，這種方式有個(gè)缺點(diǎn)：吞吐量下降；

confirm模式用的居多：一旦channel進(jìn)入confirm模式枷餐，所有在該信道上發(fā)布的消息都將會(huì)被指派一個(gè)唯一的ID（從1開始）靶瘸，一旦消息被投遞到所有匹配的隊(duì)列之后；

rabbitMQ就會(huì)發(fā)送一個(gè)ACK給生產(chǎn)者（包含消息的唯一ID），這就使得生產(chǎn)者知道消息已經(jīng)正確到達(dá)目的隊(duì)列了奕锌；

如果rabbitMQ沒能處理該消息著觉，則會(huì)發(fā)送一個(gè)Nack消息給你，你可以進(jìn)行重試操作惊暴。

消息隊(duì)列丟數(shù)據(jù)：消息持久化饼丘。

處理消息隊(duì)列丟數(shù)據(jù)的情況，一般是開啟持久化磁盤的配置辽话。

這個(gè)持久化配置可以和confirm機(jī)制配合使用肄鸽，你可以在消息持久化磁盤后，再給生產(chǎn)者發(fā)送一個(gè)Ack信號油啤。

這樣典徘，如果消息持久化磁盤之前，rabbitMQ陣亡了益咬，那么生產(chǎn)者收不到Ack信號逮诲，生產(chǎn)者會(huì)自動(dòng)重發(fā)。

那么如何持久化呢幽告？

這里順便說一下吧梅鹦，其實(shí)也很容易，就下面兩步

1. 將queue的持久化標(biāo)識durable設(shè)置為true,則代表是一個(gè)持久的隊(duì)列
2. 發(fā)送消息的時(shí)候?qū)eliveryMode=2

這樣設(shè)置以后冗锁，即使rabbitMQ掛了齐唆，重啟后也能恢復(fù)數(shù)據(jù)

消費(fèi)者丟失消息：消費(fèi)者丟數(shù)據(jù)一般是因?yàn)椴捎昧俗詣?dòng)確認(rèn)消息模式，改為手動(dòng)確認(rèn)消息即可冻河！

消費(fèi)者在收到消息之后箍邮，處理消息之前，會(huì)自動(dòng)回復(fù)RabbitMQ已收到消息叨叙；

如果這時(shí)處理消息失敗锭弊，就會(huì)丟失該消息；

解決方案：處理消息成功后摔敛，手動(dòng)回復(fù)確認(rèn)消息廷蓉。

為什么不應(yīng)該對所有的 message 都使用持久化機(jī)制？

首先马昙，必然導(dǎo)致性能的下降桃犬，因?yàn)閷懘疟P比寫 RAM 慢的多，message 的吞吐量可能有 10 倍的差距行楞。

其次攒暇，message 的持久化機(jī)制用在 RabbitMQ 的內(nèi)置 cluster 方案時(shí)會(huì)出現(xiàn)“坑爹”問題。矛盾點(diǎn)在于子房，若 message 設(shè)置了 persistent 屬性形用，但 queue 未設(shè)置 durable 屬性就轧，那么當(dāng)該 queue 的 owner node 出現(xiàn)異常后，在未重建該 queue 前田度，發(fā)往該 queue 的 message 將被 blackholed 妒御；若 message 設(shè)置了 persistent 屬性，同時(shí) queue 也設(shè)置了 durable 屬性镇饺，那么當(dāng) queue 的 owner node 異常且無法重啟的情況下乎莉，則該 queue 無法在其他 node 上重建，只能等待其 owner node 重啟后奸笤，才能恢復(fù)該 queue 的使用惋啃，而在這段時(shí)間內(nèi)發(fā)送給該 queue 的 message 將被 blackholed 。

所以监右，是否要對 message 進(jìn)行持久化边灭，需要綜合考慮性能需要，以及可能遇到的問題健盒。若想達(dá)到 100,000 條/秒以上的消息吞吐量（單 RabbitMQ 服務(wù)器）绒瘦，則要么使用其他的方式來確保 message 的可靠 delivery ，要么使用非澄堕唬快速的存儲(chǔ)系統(tǒng)以支持全持久化（例如使用 SSD）椭坚。另外一種處理原則是：僅對關(guān)鍵消息作持久化處理（根據(jù)業(yè)務(wù)重要程度）予跌，且應(yīng)該保證關(guān)鍵消息的量不會(huì)導(dǎo)致性能瓶頸搏色。

如何保證高可用的？RabbitMQ 的集群

RabbitMQ 是比較有代表性的券册，因?yàn)槭腔谥鲝模ǚ欠植际剑┳龈呖捎眯缘钠到危覀兙鸵?RabbitMQ 為例子講解第一種 MQ 的高可用性怎么實(shí)現(xiàn)。RabbitMQ 有三種模式：單機(jī)模式烁焙、普通集群模式航邢、鏡像集群模式。

單機(jī)模式骄蝇，就是 Demo 級別的膳殷，一般就是你本地啟動(dòng)了玩玩兒的?，沒人生產(chǎn)用單機(jī)模式

普通集群模式九火，意思就是在多臺(tái)機(jī)器上啟動(dòng)多個(gè) RabbitMQ 實(shí)例赚窃，每個(gè)機(jī)器啟動(dòng)一個(gè)。你創(chuàng)建的 queue岔激，只會(huì)放在一個(gè) RabbitMQ 實(shí)例上勒极，但是每個(gè)實(shí)例都同步 queue 的元數(shù)據(jù)（元數(shù)據(jù)可以認(rèn)為是 queue 的一些配置信息，通過元數(shù)據(jù)虑鼎，可以找到 queue 所在實(shí)例）辱匿。你消費(fèi)的時(shí)候键痛，實(shí)際上如果連接到了另外一個(gè)實(shí)例，那么那個(gè)實(shí)例會(huì)從 queue 所在實(shí)例上拉取數(shù)據(jù)過來匾七。這方案主要是提高吞吐量的絮短，就是說讓集群中多個(gè)節(jié)點(diǎn)來服務(wù)某個(gè) queue 的讀寫操作。

鏡像集群模式：這種模式昨忆，才是所謂的 RabbitMQ 的高可用模式戚丸。跟普通集群模式不一樣的是，在鏡像集群模式下扔嵌，你創(chuàng)建的 queue限府，無論元數(shù)據(jù)還是 queue 里的消息都會(huì)存在于多個(gè)實(shí)例上，就是說痢缎，每個(gè) RabbitMQ 節(jié)點(diǎn)都有這個(gè) queue 的一個(gè)完整鏡像胁勺，包含 queue 的全部數(shù)據(jù)的意思。然后每次你寫消息到 queue 的時(shí)候独旷，都會(huì)自動(dòng)把消息同步到多個(gè)實(shí)例的 queue 上署穗。RabbitMQ 有很好的管理控制臺(tái)，就是在后臺(tái)新增一個(gè)策略嵌洼，這個(gè)策略是鏡像集群模式的策略案疲，指定的時(shí)候是可以要求數(shù)據(jù)同步到所有節(jié)點(diǎn)的，也可以要求同步到指定數(shù)量的節(jié)點(diǎn)麻养，再次創(chuàng)建 queue 的時(shí)候褐啡，應(yīng)用這個(gè)策略，就會(huì)自動(dòng)將數(shù)據(jù)同步到其他的節(jié)點(diǎn)上去了鳖昌。這樣的話备畦，好處在于，你任何一個(gè)機(jī)器宕機(jī)了许昨，沒事兒懂盐，其它機(jī)器（節(jié)點(diǎn)）還包含了這個(gè) queue 的完整數(shù)據(jù)，別的 consumer 都可以到其它節(jié)點(diǎn)上去消費(fèi)數(shù)據(jù)糕档。壞處在于莉恼，第一，這個(gè)性能開銷也太大了吧速那，消息需要同步到所有機(jī)器上俐银，導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重！RabbitMQ 一個(gè) queue 的數(shù)據(jù)都是放在一個(gè)節(jié)點(diǎn)里的琅坡，鏡像集群下悉患，也是每個(gè)節(jié)點(diǎn)都放這個(gè) queue 的完整數(shù)據(jù)。

如何解決消息隊(duì)列的延時(shí)以及過期失效問題榆俺？消息隊(duì)列滿了以后該怎么處理售躁？有幾百萬消息持續(xù)積壓幾小時(shí)坞淮，說說怎么解決？

消息積壓處理辦法：臨時(shí)緊急擴(kuò)容：

先修復(fù) consumer 的問題陪捷，確保其恢復(fù)消費(fèi)速度回窘，然后將現(xiàn)有 cnosumer 都停掉。
新建一個(gè) topic市袖，partition 是原來的 10 倍啡直，臨時(shí)建立好原先 10 倍的 queue 數(shù)量。
然后寫一個(gè)臨時(shí)的分發(fā)數(shù)據(jù)的 consumer 程序苍碟，這個(gè)程序部署上去消費(fèi)積壓的數(shù)據(jù)酒觅，消費(fèi)之后不做耗時(shí)的處理，直接均勻輪詢寫入臨時(shí)建立好的 10 倍數(shù)量的 queue微峰。
接著臨時(shí)征用 10 倍的機(jī)器來部署 consumer舷丹，每一批 consumer 消費(fèi)一個(gè)臨時(shí) queue 的數(shù)據(jù)。這種做法相當(dāng)于是臨時(shí)將 queue 資源和 consumer 資源擴(kuò)大 10 倍，以正常的 10 倍速度來消費(fèi)數(shù)據(jù)。
等快速消費(fèi)完積壓數(shù)據(jù)之后坟桅，得恢復(fù)原先部署的架構(gòu)，重新用原先的 consumer 機(jī)器來消費(fèi)消息艺配。
MQ中消息失效：假設(shè)你用的是 RabbitMQ，RabbtiMQ 是可以設(shè)置過期時(shí)間的，也就是 TTL。如果消息在 queue 中積壓超過一定的時(shí)間就會(huì)被 RabbitMQ 給清理掉彼城，這個(gè)數(shù)據(jù)就沒了。那這就是第二個(gè)坑了逼友。這就不是說數(shù)據(jù)會(huì)大量積壓在 mq 里精肃，而是大量的數(shù)據(jù)會(huì)直接搞丟。我們可以采取一個(gè)方案帜乞，就是批量重導(dǎo)，這個(gè)我們之前線上也有類似的場景干過筐眷。就是大量積壓的時(shí)候黎烈，我們當(dāng)時(shí)就直接丟棄數(shù)據(jù)了，然后等過了高峰期以后匀谣，比如大家一起喝咖啡熬夜到晚上12點(diǎn)以后照棋，用戶都睡覺了。這個(gè)時(shí)候我們就開始寫程序武翎，將丟失的那批數(shù)據(jù)烈炭，寫個(gè)臨時(shí)程序，一點(diǎn)一點(diǎn)的查出來宝恶，然后重新灌入 mq 里面去符隙，把白天丟的數(shù)據(jù)給他補(bǔ)回來趴捅。也只能是這樣了。假設(shè) 1 萬個(gè)訂單積壓在 mq 里面霹疫，沒有處理拱绑，其中 1000 個(gè)訂單都丟了，你只能手動(dòng)寫程序把那 1000 個(gè)訂單給查出來丽蝎，手動(dòng)發(fā)到 mq 里去再補(bǔ)一次猎拨。

mq消息隊(duì)列塊滿了：如果消息積壓在 mq 里，你很長時(shí)間都沒有處理掉屠阻，此時(shí)導(dǎo)致 mq 都快寫滿了红省，咋辦？這個(gè)還有別的辦法嗎国觉？沒有类腮，誰讓你第一個(gè)方案執(zhí)行的太慢了，你臨時(shí)寫程序蛉加，接入數(shù)據(jù)來消費(fèi)蚜枢，消費(fèi)一個(gè)丟棄一個(gè)，都不要了针饥，快速消費(fèi)掉所有的消息厂抽。然后走第二個(gè)方案，到了晚上再補(bǔ)數(shù)據(jù)吧丁眼。

設(shè)計(jì)MQ思路

比如說這個(gè)消息隊(duì)列系統(tǒng)筷凤，我們從以下幾個(gè)角度來考慮一下：

首先這個(gè) mq 得支持可伸縮性吧，就是需要的時(shí)候快速擴(kuò)容苞七，就可以增加吞吐量和容量藐守，那怎么搞？設(shè)計(jì)個(gè)分布式的系統(tǒng)唄蹂风，參照一下 kafka 的設(shè)計(jì)理念卢厂，broker -> topic -> partition，每個(gè) partition 放一個(gè)機(jī)器惠啄，就存一部分?jǐn)?shù)據(jù)慎恒。如果現(xiàn)在資源不夠了，簡單啊撵渡，給 topic 增加 partition融柬，然后做數(shù)據(jù)遷移，增加機(jī)器趋距，不就可以存放更多數(shù)據(jù)粒氧，提供更高的吞吐量了？

其次你得考慮一下這個(gè) mq 的數(shù)據(jù)要不要落地磁盤吧节腐？那肯定要了外盯，落磁盤才能保證別進(jìn)程掛了數(shù)據(jù)就丟了摘盆。那落磁盤的時(shí)候怎么落啊门怪？順序?qū)懧獬海@樣就沒有磁盤隨機(jī)讀寫的尋址開銷，磁盤順序讀寫的性能是很高的掷空，這就是 kafka 的思路肋殴。

其次你考慮一下你的 mq 的可用性啊坦弟？這個(gè)事兒护锤，具體參考之前可用性那個(gè)環(huán)節(jié)講解的 kafka 的高可用保障機(jī)制。多副本 -> leader & follower -> broker 掛了重新選舉 leader 即可對外服務(wù)酿傍。

能不能支持?jǐn)?shù)據(jù) 0 丟失袄优场？可以的赤炒，參考我們之前說的那個(gè) kafka 數(shù)據(jù)零丟失方案氯析。

作者：ThinkWon
來源：https://thinkwon.blog.csdn.net/article/details/104588612

本文首發(fā)于公眾號：Java版web項(xiàng)目，歡迎關(guān)注獲取更多精彩內(nèi)容