MQ那點破事，訊息丟失、重復消費、消費順序、堆積、事務、高可用....

精彩文章匯總 GitHub https://github.com/aalansehaiyang/technology-talk ，Star 12K
匯總java生態圈常用技術框架、開源中間件，系統架構、資料庫、大公司架構案例、常用三方類別庫、專案管理、線上問題排查、個人成長、思考等知識

大家好，我是Tom哥~

阿里P7技術專家，一個不喜歡內卷的程式員~

馬上要開啟國慶小長假了，祝大家節日快樂，吃喝玩樂走起~

為了便于大家查找問題，了解全貌，整理個目錄，我們可以快速全域了解關于訊息佇列，面試官一般會問哪些問題，

本篇文章的目錄：

訊息佇列的應用場景？

答案：1、異步處理 2、流量削峰填谷 3、應用解耦 4、訊息通訊

• 異步處理，將一個請求鏈路中的非核心流程，拆分出來，異步處理，減少主流程鏈路的處理邏輯，縮短RT，提升吞吐量，如：注冊新用戶發短信通知，

• 削峰填谷，避免流量暴漲，打垮下游系統，前面會加個訊息佇列，平滑流量沖擊，比如：秒殺活動，生活中像電源配接器也是這個原理，

• 應用解耦，兩個應用，通過訊息系統間接建立關系，避免一個系統宕機后對另一個系統的影響，提升系統的可用性，如：下單異步扣減庫存

• 訊息通訊，內置了高效的通信機制，可用于訊息通訊，如：點對點訊息佇列、聊天室，

常用的訊息框架有哪些？

答案：ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaQ，RocketMQ、Pulsar 等

MQ技術選型？

答案：對比了 Kafka、RocketMQ 、Pulsar 三個框架，時耗、吞吐量、可靠性、事務、副本同步策略、多租戶、動態擴容、故障恢復等評估指標，詳細內容，參考 為什么放棄Kafka，選擇Pulsar?

訊息模型有哪些？

答案：1、點對點模式 2、發布/訂閱模式

如何保證 MQ 訊息不丟失？

答案：在了解訊息中間件的運作模式后，主要從三個方面來考慮這個問題：

• 1、生產端，不丟失訊息

• 2、MQ服務端，存盤本身不丟失訊息

• 3、消費端，不丟失訊息

• 詳細內容，參考 硬核 | Kafka 如何解決訊息不丟失？

如何解決訊息的重復消費？

答案：生產端為了保證訊息發送成功，可能會重復推送（直到收到成功ACK），會產生重復訊息，但是一個成熟的MQ Server框架一般會想辦法解決，避免存盤重復訊息（比如：空間換時間，存盤已處理過的message_id），給生產端提供一個冪等性的發送訊息介面，

但是消費端卻無法根本解決這個問題，在高并發標準要求下，拉取訊息+業務處理+提交消費位移需要做事務處理，另外消費端服務可能宕機，很可能會拉取到重復訊息，

所以，只能業務端自己做控制，對于已經消費成功的訊息，本地資料庫表或Redis快取業務標識，每次處理前先進行校驗，保證冪等，

如何保證 MQ訊息是有序的？

答案：有些業務有背景關系要求，比如：電商行業的下單、付款、發貨、確認識訓，每個環節都會發送訊息，而消費端拉取并消費訊息時，也是希望按正常的狀態機流程進行，所以對訊息就有了順序要求，解決思路：

• 1、該topic強制采用一個磁區，所有訊息放到一個佇列里，這樣能達到全域順序性，但是會損失高并發特性，

• 2、區域有序，采用路由機制，將同一個訂單的不同狀態訊息存盤在一個磁區partition，單執行緒消費，比如Kafka就提供了一個介面擴展org.apache.kafka.clients.Partitioner，方便開發人員按照自己的業務場景來定制路由規則，

• 詳細內容，參考 面試官問：如何保證 MQ訊息是有序的？

訊息堆積如何處理？

答案：主要是訊息的消費速度跟不上生產速度，從而導致訊息堆積，解決思路：

• 1、可能是剛上線的業務，或者大促活動，流量評估不到位，這時需要增加消費組的機器數量，提升整體消費能力

• 2、也可能是消費端的問題，正常情況，一條訊息處理需要10ms，但是優化不到位或者線上bug，現在要500ms，那么消費端的整體處理速度會下降50倍，這時，我們就要針對性的排查業務代碼，Tom哥之前帶的團隊就有小伙伴出現這個問題，當時是資料庫的一條sql沒有命中索引，導致單條訊息處理耗時拉長，進而導致訊息堆積，線上報警，不過憑我們豐富的經驗，很快就定位解決了，

如何保證資料一致性問題？

答案：為了解耦，引入異步訊息機制，先進行本地資料庫操作，處理成功后，再發送MQ訊息，由消費端進行后續操作，比如：電商訂單下單成功后，要通知扣減庫存，

這兩者一定要保證事務操作，否則就會出現資料不一致問題，這時候，我們就需要引入事務訊息來解決這個問題，

另外，在消費環節，也可能出現資料不一致情況，我們可以采用最終一致性原則，增加重試機制，

事務訊息是如何實作？

答案：

• 1、生產者先發送一條半事務訊息到MQ

• 2、MQ收到訊息后回傳ack確認

• 3、生產者開始執行本地事務

• 4、if 本地事務執行成功，發送commit到MQ；失敗，發送rollback

• 5、如果MQ?時間未收到生產者的二次確認commit或rollback，MQ對生產者發起反向回查

• 6、生產者查詢事務執行最終狀態

• 7、根據查詢事務狀態，再次提交二次確認

關于分布式事務問題，除了事務訊息，還有哪些解決方案？

MQ框架 如何實作高吞吐量？

答案：

• 1、訊息的批量處理

• 2、訊息壓縮，節省傳輸帶寬和存盤空間

• 3、零拷貝

• 4、磁盤的順序寫入

• 5、page cache 頁快取，由作業系統異步將快取中的資料刷到磁盤，以及高效的記憶體讀取

• 6、磁區設計，一個邏輯topic下面掛載N個磁區，每個磁區可以對應不同的機器消費訊息，并發設計，

Kafka 為什么不支持讀寫分離？

答案：我們知道，生產端寫入訊息、消費端拉取訊息都是與leader 副本互動的，并沒有像mysql資料庫那樣，master負責寫，slave負責讀，

這種設計主要是從兩個方面考慮：

• 1、資料一致性，一主多從，leader副本的資料同步到follower副本有一定的延時，因此每個follower副本的訊息位移也不一樣，而消費端是通過消費位移來控制訊息拉取進度，多個副本間要維護同一個消費位移的一致性，如果引入分布式鎖，保證并發安全，非常耗費性能，

• 2、實時性，leader副本的資料同步到follower副本有一定的延時，如果網路較差，延遲會很嚴重，無法滿足實時性業務需求，

綜上考慮，讀寫操作都是針對 leader 副本進行的，而 follower 副本主要是用于資料的備份，

MQ框架如何做到高可用性？

答案：以Kafka框架為例，其他的MQ框架原理類似，

Kafka 由多個 broker 組成，每個 broker 是一個節點，你創建一個 topic，這個 topic 可以劃分為多個 partition，每個 partition 存放在不同的 broker 上，每個 partition 存放一部分資料，每個 partition 有多個 replica 副本，

寫的時候，leader 會負責把資料同步到所有 follower 上去，讀的時候就直接讀 leader 上的資料即可，

如果某個 broker 宕機了，沒事兒，那個 broker 上面的 partition 在其他機器上都有副本，此時會從 follower 中重新選舉一個新的 leader 出來，大家繼續讀寫那個新的 leader 即可，這就是所謂的高可用性，

更多內容，可以參考 關于訊息佇列，面試官一般都會問哪些？

關于Kafka，面試官一般喜歡考察哪些問題？

答案：

• 訊息壓縮

• 訊息解壓縮

• 磁區策略

• 生產者如何實作冪等、事務

• Kafka Broker 是如何存盤資料？備份機制

• 為什么要引入消費組？

• 詳細內容，參考之前寫的 聊聊 Kafka 那點破事！

最后給大家送點福利，已經幫助身邊很多小伙伴進入位元組、阿里等一線大廠，一位Google大神總結的演算法筆記，幫助你打通LeetCode的任督二脈

谷歌大佬總結LeetCode刷題筆記

也歡迎小伙伴掃下面的公眾號關注我，找Tom哥嘮嗑聊天， 技術交流，圍觀朋友圈，人生打怪不再寂寞