[[426772]]

本文轉載自微信公眾號「微觀技術」，作者 微觀技術。轉載本文請聯系微觀技術公眾號。

大家好，我是 Tom哥~

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

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

本篇文章的目錄：

消息隊列的應用場景?

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

• 異步處理。將一個請求鏈路中的非核心流程，拆分出來，異步處理，減少主流程鏈路的處理邏輯，縮短RT，提升吞吐量。如：注冊新用戶發短信通知。
• 削峰填谷。避免流量暴漲，打垮下游系統，前面會加個消息隊列，平滑流量沖擊。比如：秒殺活動。生活中像電源適配器也是這個原理。
• 應用解耦。兩個應用，通過消息系統間接建立關系，避免一個系統宕機后對另一個系統的影響，提升系統的可用性。如：下單異步扣減庫存
• 消息通訊。內置了高效的通信機制，可用于消息通訊。如：點對點消息隊列、聊天室。

常用的消息框架有哪些?

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

MQ技術選型?

答案：對比了 Kafka、RocketMQ 、Pulsar 三個框架，時耗、吞吐量、可靠性、事務、副本同步策略、多租戶、動態擴容、故障恢復等評估指標。

消息模型有哪些?

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

如何保證 MQ 消息不丟失?

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

1、生產端，不丟失消息

2、MQ服務端，存儲本身不丟失消息

3、消費端，不丟失消息

如何解決消息的重復消費?

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

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

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

如何保證 MQ消息是有序的?

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

1、該topic強制采用一個分區，所有消息放到一個隊列里，這樣能達到全局順序性。但是會損失高并發特性。

2、局部有序，采用路由機制，將同一個訂單的不同狀態消息存儲在一個分區partition，單線程消費。比如Kafka就提供了一個接口擴展org.apache.kafka.clients.Partitioner，方便開發人員按照自己的業務場景來定制路由規則。

消息堆積如何處理?

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

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 是如何存儲數據?備份機制
• 為什么要引入消費組?