消息隊列——經典5連問——你能抗幾道？

• 面試題1：說說你對消息隊列的理解，消息隊列爲了解決什麼問題？
• 追問1：消息隊列有什麼優缺點
• 面試題2：對於消息中間機，大家是怎麼作技術選型的？
• 面試題3：如何確保消息正確地發送至 RabbitMQ？如何確保消息接收方消費了消息？
• 追問1：如何保證MQ消息的可靠傳輸？

面試題1：說說你對消息隊列的理解，消息隊列爲了解決什麼問題？

咱們公司業務系統一開始體量較小，不少組件都是單機版就足夠，後來隨着用戶量逐漸擴大，咱們程序也採用了微服務的設計思想，把不少服務進行了拆分，但後來在一些秒殺搶票活動或高頻業務中，服務依舊扛不住大量QPS，所以咱們引入了消息隊列來優化該類問題。

消息隊列應用的場景大體分爲三類：解耦、異步、削峯。

解耦

消息隊列相似設計模式中的觀察者模式（Observer）或發佈-訂閱模式（Pub-Sub）。生產者生成和發送消息到消息隊列，消費者從消息隊列中取走消息進行處理，稱爲消費，使用消息隊列將「生產者」和「消費者」之間的操做關聯解耦，易於擴展。

好比系統A爲支付系統，一開始用戶支付完調用日誌記錄系統B記錄就完了，後來內容愈來愈多，支付完成要調用加積分系統C、短信通知系統D、優惠券系統E等等…

這個場景中，A 系統跟其它各類亂七八糟的系統嚴重耦合，A 系統產生一條支付成功的數據，不少系統接口都須要 A 系統調用把支付成功的數據發送過去。A 系統程序員要時刻考慮這些問題：

• 其餘系統若是掛了該咋辦？是否是直接程序拋異常了？
• 一天到晚加業務，每次都從新部署？領導是否是狗？

那若是引入 MQ，A 系統產生一條數據，發送到 MQ 裏面去，每一個子系統加上對消息隊列中支付成功消息的訂閱，持續監聽就能夠了，哪一個系統須要數據本身去 MQ 裏面消費。若是新系統須要數據，直接從 MQ 裏消費便可；若是某個系統不須要這條數據了，就取消對 MQ 消息的消費便可。

這樣下來，A系統壓根兒不須要去考慮要給誰發送數據，不須要維護這個代碼，也不須要考慮人家是否調用成功、失敗超時等狀況，我只負責把支付成功的信息放到MQ裏就好了，至於可否正常加積分、可否正常短信通知，管我鳥事！~~可見，經過一個 MQ，Pub/Sub 發佈訂閱消息這麼一個模型，A 系統就跟其它系統完全解耦了。

面試官：哦，那我聽出來了，你這是喜歡甩鍋啊！來，簡歷還你。

數據一致性

這個實際上是分佈式服務自己就存在的一個問題，不只僅是消息隊列的問題，可是放在這裏說是由於用了消息隊列這個問題會更明顯。

就像我們上面說的，你支付成功的服務本身保證本身的邏輯成功處理了，你成功發了消息，可是短信系統，積分系統等等這麼多系統，他們成功仍是失敗你就無論了？固然不行，這樣坑隊友的行爲，狄大人都幫不了你~

怎麼辦？那就把全部的服務都放到一個事務裏，全部都成功成功才能算這一次下單是成功的，要成功一塊兒成功，要失敗一塊兒失敗。

異步

A 系統接收一個請求，須要在本身本地寫庫，還須要在 BCD 三個系統寫庫，本身本地寫庫要 3ms，BCD 三個系統分別寫庫要 300ms、400ms、200ms。最終請求總延時是 3 + 300 + 400 + 200 = 903ms，接近 1秒，用戶感受搞個毛線？慢的一批。

通常互聯網類的企業，對於用戶直接的操做，通常要求是每一個請求都必須在 200 ms 之內完成，對用戶幾乎是無感知的，若是1秒足以說明該系統不可用，垃圾系統。

若是這裏使用了消息隊列，那麼 A 系統連續發送 3 條消息到 MQ 隊列中，假如耗時 5ms，A 系統從接受一個請求到返回響應給用戶，總時長是 3 + 5 = 8ms，對於用戶而言，其實感受上就是點個按鈕，8ms 之後就直接返回了，體驗感很好

削峯

好比咱們系統有代售搶票業務，平時天天QPS也就50左右，A 系統風平浪靜。結果每次一到春運搶票，每秒併發請求數量忽然會暴增到10000以上。可是系統是直接基於 MySQL 的，大量的請求直接打到 MySQL，好比通常MySQL能抗2000條請求，如今每秒10000 條 SQL，可能就直接把 MySQL 給打死了，致使系統崩潰。可是高峯期一過就又沒人了，QPS回到50，對整個系統幾乎沒有任何的壓力。

若是這裏使用 MQ，每秒 1w 個請求寫入 MQ，A 系統每秒鐘最多處理 2000 個請求，由於 MySQL 每秒鐘最多處理 2k 個。A 系統從 MQ 中慢慢拉取請求，每秒鐘就拉取 2k 個請求，不要超過本身每秒能處理的最大請求數量就 ok了，這樣下來，哪怕是高峯期的時候，A 系統也不會掛掉。固然了，用戶的響應時間確定會受影響，畢竟秒殺嘛，只要把前多少條請求處理好，其他的搶票失敗就好了。

另外，MQ 每秒鐘 1w 個請求進來，只處理 2k 個請求出去，結果會致使在中午高峯期，可能有幾十萬甚至幾百萬的請求積壓在 MQ 中。

這個短暫的高峯期積壓是 ok 的，由於高峯期過了以後，每秒鐘就 50 個請求進 MQ，可是A 系統依然會按照每秒 2k 個請求的速度在處理。因此說，只要高峯期一過，A 系統就會快速將積壓的消息給消費掉。

追問1：消息隊列有什麼優缺點

• 系統可用性下降

系統引入的外部依賴越多，越容易掛掉。原本你就是 A 系統調用 BCD 三個系統的接口就行了，人 ABCD 四個系統好好的，沒啥問題，你偏加個 MQ 進來，萬一 MQ 掛了咋整，MQ 一掛，整套系統崩潰的，你不就完了？如何保證消息隊列的高可用？

• 系統複雜度提升

硬生生加個 MQ 進來，你怎麼保證消息必定被消費？如何避免消息重複投遞或重複消費？數據丟失怎麼辦？怎麼保證消息傳遞的順序性？

• 一致性問題

A 系統處理完了直接返回成功了，人都覺得你這個請求就成功了；可是問題是，要是 BCD 三個系統那裏，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致了。

面試題2：對於消息中間機，大家是怎麼作技術選型的？

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

ActiveMQ和RabbitMQ這兩因爲吞吐量的緣由，只有業務體量通常的公司在用，RabbitMQ因爲是erlang語言開發的，咱們都不瞭解，所以擴展和維護成本都很高，查個問題都頭疼。

Kafka和RocketMQ一直在各自擅長的領域發光發亮，二者的吞吐量、可靠性、時效性等都很可觀。

咱們經過圖表看看這幾個消息中間機的對比：

你們其實一會兒就能看到差距了，就拿吞吐量來講，早期比較活躍的ActiveMQ 和RabbitMQ基本上不是後二者的對手了，在如今這樣大數據的年代吞吐量是真的很重要。

面試題3：如何確保消息正確地發送至 RabbitMQ？如何確保消息接收方消費了消息？

發送方確認模式

將信道設置成confirm模式（發送方確認模式），則全部在信道上發佈的消息都會被指派一個惟一的ID。

一旦消息被投遞到目的隊列後，或者消息被寫入磁盤後（可持久化的消息），信道會發送一個確認給生產者（包含消息惟一ID）。

若是RabbitMQ發生內部錯誤從而致使消息丟失，會發送一條Nack（not acknowledged，未確認）消息。

發送方確認模式是異步的，生產者應用程序在等待確認的同時，能夠繼續發送消息。當確認消息到達生產者應用程序，生產者應用程序的回調方法就會被觸發來處理確認消息。

接收方確認機制

消費者接收每一條消息後都必須進行確認（消息接收和消息確認是兩個不一樣操做）。只有消費者確認了消息，RabbitMQ才能安全地把消息從隊列中刪除。

這裏並無用到超時機制，RabbitMQ僅經過Consumer的鏈接中斷來確認是否須要從新發送消息。也就是說，只要鏈接不中斷，RabbitMQ給了Consumer足夠長的時間來處理消息。保證數據的最終一致性；

追問1：如何保證MQ消息的可靠傳輸？

以咱們經常使用的RabbitMQ爲例，消息不可靠的狀況多是消息丟失，劫持等緣由；

丟失又分爲：生產者丟失消息、消息隊列丟失消息、消費者丟失消息；

生產者丟失消息：從生產者弄丟數據這個角度來看，RabbitMQ提供confirm模式來確保生產者不丟消息；

confirm模式用的居多：一旦channel進入confirm模式，全部在該信道上發佈的消息都將會被指派一個惟一的ID（從1開始），一旦消息被投遞到全部匹配的隊列以後；RabbitMQ就會發送一個ACK給生產者（包含消息的惟一ID），這就使得生產者知道消息已經正確到達目的隊列了；

若是rabbitMQ沒能處理該消息，則會發送一個Nack消息給你，你能夠進行重試操做。

消息隊列丟數據：消息持久化。

處理消息隊列丟數據的狀況，通常是開啓持久化磁盤的配置。

持久化配置和confirm機制配合使用，在消息持久化磁盤後，再給生產者發送一個Ack信號。

這樣，若是消息持久化磁盤以前，rabbitMQ陣亡了，那麼生產者收不到Ack信號，生產者會自動重發。

面試官：那你說說如何避免消息重複投遞或重複消費？消息是基於什麼傳輸的？
我：今天累了，不想說了，下次吧~
面試官：？？？
我：對了，簡歷給我來。
面試官：嘶~
我：怎麼，玩不起了？

 

累了，不想說了，下次吧~面試官：？？？我：對了，簡歷給我來。面試官：嘶~我：怎麼，玩不起了？