面試題1：說(shuō)說(shuō)你對(duì)消息隊(duì)列的理解，消息隊(duì)列為了解決什么問(wèn)題？

我們公司業(yè)務(wù)系統(tǒng)一開(kāi)始體量較小，很多組件都是單機(jī)版就足夠，后來(lái)隨著用戶量逐漸擴(kuò)大，我們程序也采用了微服務(wù)的設(shè)計(jì)思想，把很多服務(wù)進(jìn)行了拆分，但后來(lái)在一些秒殺搶票活動(dòng)或高頻業(yè)務(wù)中，服務(wù)依舊扛不住大量QPS，因此我們引入了消息隊(duì)列來(lái)優(yōu)化該類問(wèn)題。

消息隊(duì)列應(yīng)用的場(chǎng)景大致分為三類：解耦、異步、削峰。

解耦

消息隊(duì)列類似設(shè)計(jì)模式中的觀察者模式（Observer）或發(fā)布-訂閱模式（Pub-Sub）。生產(chǎn)者生成和發(fā)送消息到消息隊(duì)列，消費(fèi)者從消息隊(duì)列中取走消息進(jìn)行處理，稱為消費(fèi)，使用消息隊(duì)列將“生產(chǎn)者”和“消費(fèi)者”之間的操作關(guān)聯(lián)解耦，易于擴(kuò)展。

比如系統(tǒng)A為支付系統(tǒng)，一開(kāi)始用戶支付完調(diào)用日志記錄系統(tǒng)B記錄就完了，后來(lái)內(nèi)容越來(lái)越多，支付完成要調(diào)用加積分系統(tǒng)C、短信通知系統(tǒng)D、優(yōu)惠券系統(tǒng)E等等…

這個(gè)場(chǎng)景中，A 系統(tǒng)跟其它各種亂七八糟的系統(tǒng)嚴(yán)重耦合，A 系統(tǒng)產(chǎn)生一條支付成功的數(shù)據(jù)，很多系統(tǒng)接口都需要 A 系統(tǒng)調(diào)用把支付成功的數(shù)據(jù)發(fā)送過(guò)去。A 系統(tǒng)程序員要時(shí)刻考慮這些問(wèn)題：

• 其他系統(tǒng)如果掛了該咋辦？是不是直接程序拋異常了？
• 一天到晚加業(yè)務(wù)，每次都重新部署？領(lǐng)導(dǎo)是不是狗？

那如果引入 MQ，A 系統(tǒng)產(chǎn)生一條數(shù)據(jù)，發(fā)送到 MQ 里面去，每個(gè)子系統(tǒng)加上對(duì)消息隊(duì)列中支付成功消息的訂閱，持續(xù)監(jiān)聽(tīng)就可以了，哪個(gè)系統(tǒng)需要數(shù)據(jù)自己去 MQ 里面消費(fèi)。如果新系統(tǒng)需要數(shù)據(jù)，直接從 MQ 里消費(fèi)即可；如果某個(gè)系統(tǒng)不需要這條數(shù)據(jù)了，就取消對(duì) MQ 消息的消費(fèi)即可。

這樣下來(lái)，A系統(tǒng)壓根兒不需要去考慮要給誰(shuí)發(fā)送數(shù)據(jù)，不需要維護(hù)這個(gè)代碼，也不需要考慮人家是否調(diào)用成功、失敗超時(shí)等情況，我只負(fù)責(zé)把支付成功的信息放到MQ里就行了，至于能否正常加積分、能否正常短信通知，管我鳥(niǎo)事！~~可見(jiàn)，通過(guò)一個(gè) MQ，Pub/Sub 發(fā)布訂閱消息這么一個(gè)模型，A 系統(tǒng)就跟其它系統(tǒng)徹底解耦了。

面試官：哦，那我聽(tīng)出來(lái)了，你這是喜歡甩鍋??！來(lái)，簡(jiǎn)歷還你。

我：額。。不，我開(kāi)玩笑的，當(dāng)然不能這樣做，這里其實(shí)涉及到MQ在分布式事務(wù)中數(shù)據(jù)一致性的問(wèn)題；聽(tīng)我跟您解釋。

數(shù)據(jù)一致性

這個(gè)其實(shí)是分布式服務(wù)本身就存在的一個(gè)問(wèn)題，不僅僅是消息隊(duì)列的問(wèn)題，但是放在這里說(shuō)是因?yàn)橛昧讼㈥?duì)列這個(gè)問(wèn)題會(huì)更明顯。

就像咱們上面說(shuō)的，你支付成功的服務(wù)自己保證自己的邏輯成功處理了，你成功發(fā)了消息，但是短信系統(tǒng)，積分系統(tǒng)等等這么多系統(tǒng)，他們成功還是失敗你就不管了？當(dāng)然不行，這樣坑隊(duì)友的行為，狄大人都幫不了你~

怎么辦？那就把所有的服務(wù)都放到一個(gè)事務(wù)里，所有都成功成功才能算這一次下單是成功的，要成功一起成功，要失敗一起失敗。

異步

A 系統(tǒng)接收一個(gè)請(qǐng)求，需要在自己本地寫庫(kù)，還需要在 BCD 三個(gè)系統(tǒng)寫庫(kù)，自己本地寫庫(kù)要 3ms，BCD 三個(gè)系統(tǒng)分別寫庫(kù)要 300ms、400ms、200ms。最終請(qǐng)求總延時(shí)是 3 + 300 + 400 + 200 = 903ms，接近 1秒，用戶感覺(jué)搞個(gè)毛線？慢的一批。

一般互聯(lián)網(wǎng)類的企業(yè)，對(duì)于用戶直接的操作，一般要求是每個(gè)請(qǐng)求都必須在 200 ms 以內(nèi)完成，對(duì)用戶幾乎是無(wú)感知的，如果1秒足以說(shuō)明該系統(tǒng)不可用，垃圾系統(tǒng)。

如果這里使用了消息隊(duì)列，那么 A 系統(tǒng)連續(xù)發(fā)送 3 條消息到 MQ 隊(duì)列中，假如耗時(shí) 5ms，A 系統(tǒng)從接受一個(gè)請(qǐng)求到返回響應(yīng)給用戶，總時(shí)長(zhǎng)是 3 + 5 = 8ms，對(duì)于用戶而言，其實(shí)感覺(jué)上就是點(diǎn)個(gè)按鈕，8ms 以后就直接返回了，體驗(yàn)感很好

削峰

比如我們系統(tǒng)有代售搶票業(yè)務(wù)，平時(shí)每天QPS也就50左右，A 系統(tǒng)風(fēng)平浪靜。結(jié)果每次一到春運(yùn)搶票，每秒并發(fā)請(qǐng)求數(shù)量突然會(huì)暴增到10000以上。但是系統(tǒng)是直接基于 MySQL 的，大量的請(qǐng)求直接打到 MySQL，比如一般MySQL能抗2000條請(qǐng)求，現(xiàn)在每秒10000 條 SQL，可能就直接把 MySQL 給打死了，導(dǎo)致系統(tǒng)崩潰。但是高峰期一過(guò)就又沒(méi)人了，QPS回到50，對(duì)整個(gè)系統(tǒng)幾乎沒(méi)有任何的壓力。

如果這里使用 MQ，每秒 1w 個(gè)請(qǐng)求寫入 MQ，A 系統(tǒng)每秒鐘最多處理 2000 個(gè)請(qǐng)求，因?yàn)?MySQL 每秒鐘最多處理 2k 個(gè)。A 系統(tǒng)從 MQ 中慢慢拉取請(qǐng)求，每秒鐘就拉取 2k 個(gè)請(qǐng)求，不要超過(guò)自己每秒能處理的最大請(qǐng)求數(shù)量就 ok了，這樣下來(lái)，哪怕是高峰期的時(shí)候，A 系統(tǒng)也不會(huì)掛掉。當(dāng)然了，用戶的響應(yīng)時(shí)間肯定會(huì)受影響，畢竟秒殺嘛，只要把前多少條請(qǐng)求處理好，其余的搶票失敗就行了。

另外，MQ 每秒鐘 1w 個(gè)請(qǐng)求進(jìn)來(lái)，只處理 2k 個(gè)請(qǐng)求出去，結(jié)果會(huì)導(dǎo)致在中午高峰期，可能有幾十萬(wàn)甚至幾百萬(wàn)的請(qǐng)求積壓在 MQ 中。

這個(gè)短暫的高峰期積壓是 ok 的，因?yàn)楦叻迤谶^(guò)了之后，每秒鐘就 50 個(gè)請(qǐng)求進(jìn) MQ，但是A 系統(tǒng)依然會(huì)按照每秒 2k 個(gè)請(qǐng)求的速度在處理。所以說(shuō)，只要高峰期一過(guò)，A 系統(tǒng)就會(huì)快速將積壓的消息給消費(fèi)掉。

追問(wèn)1：消息隊(duì)列有什么優(yōu)缺點(diǎn)

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

系統(tǒng)引入的外部依賴越多，越容易掛掉。本來(lái)你就是 A 系統(tǒng)調(diào)用 BCD 三個(gè)系統(tǒng)的接口就好了，人 ABCD 四個(gè)系統(tǒng)好好的，沒(méi)啥問(wèn)題，你偏加個(gè) MQ 進(jìn)來(lái)，萬(wàn)一 MQ 掛了咋整，MQ 一掛，整套系統(tǒng)崩潰的，你不就完了？如何保證消息隊(duì)列的高可用？

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

硬生生加個(gè) MQ 進(jìn)來(lái)，你怎么保證消息一定被消費(fèi)？如何避免消息重復(fù)投遞或重復(fù)消費(fèi)？數(shù)據(jù)丟失怎么辦？怎么保證消息傳遞的順序性？

• 一致性問(wèn)題

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

面試題2：對(duì)于消息中間機(jī)，你們是怎么做技術(shù)選型的？

目前市面上比較主流的消息隊(duì)列中間件主要有，Kafka、ActiveMQ、RabbitMQ、RocketMQ 等。

ActiveMQ和RabbitMQ這兩由于吞吐量的原因，只有業(yè)務(wù)體量一般的公司在用，RabbitMQ由于是erlang語(yǔ)言開(kāi)發(fā)的，我們都不了解，因此擴(kuò)展和維護(hù)成本都很高，查個(gè)問(wèn)題都頭疼。

Kafka和RocketMQ一直在各自擅長(zhǎng)的領(lǐng)域發(fā)光發(fā)亮，兩者的吞吐量、可靠性、時(shí)效性等都很可觀。

我們通過(guò)圖表看看這幾個(gè)消息中間機(jī)的對(duì)比：

大家其實(shí)一下子就能看到差距了，就拿吞吐量來(lái)說(shuō)，早期比較活躍的ActiveMQ 和RabbitMQ基本上不是后兩者的對(duì)手了，在現(xiàn)在這樣大數(shù)據(jù)的年代吞吐量是真的很重要。

面試題3：如何確保消息正確地發(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（not acknowledged，未確認(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ā)來(lái)處理確認(rèn)消息。

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

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

這里并沒(méi)有用到超時(shí)機(jī)制，RabbitMQ僅通過(guò)Consumer的連接中斷來(lái)確認(rèn)是否需要重新發(fā)送消息。也就是說(shuō)，只要連接不中斷，RabbitMQ給了Consumer足夠長(zhǎng)的時(shí)間來(lái)處理消息。保證數(shù)據(jù)的最終一致性；

追問(wèn)1：如何保證MQ消息的可靠傳輸？

以我們常用的RabbitMQ為例，消息不可靠的情況可能是消息丟失，劫持等原因；

丟失又分為：生產(chǎn)者丟失消息、消息隊(duì)列丟失消息、消費(fèi)者丟失消息；

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

confirm模式用的居多：一旦channel進(jìn)入confirm模式，所有在該信道上發(fā)布的消息都將會(huì)被指派一個(gè)唯一的ID（從1開(kāi)始），一旦消息被投遞到所有匹配的隊(duì)列之后；RabbitMQ就會(huì)發(fā)送一個(gè)ACK給生產(chǎn)者（包含消息的唯一ID），這就使得生產(chǎn)者知道消息已經(jīng)正確到達(dá)目的隊(duì)列了；

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

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

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

持久化配置和confirm機(jī)制配合使用，在消息持久化磁盤后，再給生產(chǎn)者發(fā)送一個(gè)Ack信號(hào)。

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

總結(jié)

本篇文章就到這里了，希望能給你帶來(lái)幫助，也希望您關(guān)注腳本之家的更多內(nèi)容！

最新評(píng)論