MQ為什么會丟消息?如何保證不丟失消息
一、前言
面大廠時，MQ 這一中間件基本都是必問的，本文是面試時被問到的其中一題的答案。
關(guān)于大廠面經(jīng)，請看：美團(tuán)、字節(jié)、阿里、騰訊面經(jīng) (「本人面試經(jīng)歷，非廣告」)
?PS：字節(jié)跳動飛書后端內(nèi)推，Base 深圳，組內(nèi)直招，10 個 HC，所以機(jī)會比較大，有意向的同學(xué)請?jiān)诠娞栔新?lián)系我或者文末掃碼投遞。
?
二、為什么丟消息
一條消息從產(chǎn)生到被消費(fèi)，中間會經(jīng)歷三個環(huán)節(jié)：生產(chǎn)者、MQ 內(nèi)部、消費(fèi)者，消息在這三個環(huán)節(jié)中均有可能出現(xiàn)丟失。
1. 在生產(chǎn)者環(huán)節(jié)丟失
- 當(dāng)生產(chǎn)者往 MQ 中寫數(shù)據(jù)時，可能出現(xiàn)網(wǎng)絡(luò)故障，消息壓根就沒到達(dá) MQ 內(nèi)部，生產(chǎn)者端對這個異常沒有捕獲，不做任何處理，這種場景會導(dǎo)致消息丟失。
- 當(dāng)消息達(dá)到 MQ 所在的機(jī)器，但是 MQ 出現(xiàn)了異常，返回異常給生產(chǎn)者端，生產(chǎn)者對異常沒做相應(yīng)處理，導(dǎo)致消息丟失
2. 在 MQ 環(huán)節(jié)丟失
- 當(dāng)消息達(dá)到 MQ 內(nèi)部后，消息會先存于內(nèi)存當(dāng)中，然后再持久化到磁盤。如果在消息處于內(nèi)存當(dāng)中，還未來得及刷入磁盤時，MQ 所在機(jī)器宕機(jī)，此時，消息會丟失。
- 即使消息持久化到磁盤了，但當(dāng)前機(jī)器的磁盤發(fā)生損壞，消息依舊會丟失。
3. 在消費(fèi)者環(huán)節(jié)丟失消息
- 當(dāng)消息達(dá)到消費(fèi)者端時，如果消費(fèi)者開啟了 Auto ACK，那么消費(fèi)者消費(fèi)到消息后，就會自動提交 offset 到 MQ，如果此時消費(fèi)者還沒來得及處理消息對應(yīng)的業(yè)務(wù)邏輯，機(jī)器宕機(jī)了或者被新手 kill -9 pid 了，此時消息也就被丟失了。即使機(jī)器重新恢復(fù)后，由于已經(jīng)提交了之前消息的 offset，所以 MQ 不會再將之前的消息推送給消費(fèi)者，因此這條消息丟失。(這也是很多文章都說不準(zhǔn)使用 kill -9 pid 的其中原因之一)
- 消費(fèi)者沒有開啟 Auto ACK，但是消費(fèi)者消費(fèi)到消息后，將消息扔到了線程池，然后提交 offset，讓線程池異步去處理消息。如果線程池中的任務(wù)還沒處理完，機(jī)器宕機(jī)或者 OOM 等異常，這也將導(dǎo)致消息沒被處理，從而丟失。
三、如何保證不丟消息
消息在上述三個環(huán)節(jié)均有可能出現(xiàn)丟失，因此需要保證上述這三個環(huán)節(jié)均不出現(xiàn)丟數(shù)據(jù)的可能，才能完全保證消息不丟失。
1. 生產(chǎn)者
- 當(dāng)往 MQ 中寫消息出現(xiàn)異常時，采用 try...catch... 捕獲異常，在異常代碼塊中重試。
- 如果是 RocketMQ，可以直接使用 RokcetMQ 的事務(wù)消息，來保證消息不丟失。至于為什么 RocketMQ 為什么能保證消息不丟失，可以閱讀這篇文章：「RocketMQ 事務(wù)消息如何保證數(shù)據(jù)的最終一致性」
2. MQ
對于 MQ 而言，要保證消息不丟失，一方面是要保證消息要持久化到磁盤，另一方面是需要保證消息有多個副本。在不同的 MQ 中，對這兩點(diǎn)的處理方式均不太一樣，下面主要以 kafka 和 RocketMQ 為例說明。
對于 kafka 而言，需要保證如下三點(diǎn)：
- 要求每個 partition 的副本數(shù)大于 1（replication factor > 1）
- 要求 kafka 服務(wù)端設(shè)置 broker.insync.replicas 參數(shù)的值大于 1，它的意思是要求至少有一個 flower 在和 leader 同步
- 將 acks=all，在寫數(shù)據(jù)時，要求消息寫到所有的 leader 和 flower 之后，才認(rèn)為消息寫成功。
對于 RocketMQ 而言，需要保證以下幾點(diǎn)：
- 基于 Dledger 的 broker 主從架構(gòu)，每個主 broker 需要掛至少 2 個 slave broker。
- 采用同步刷盤策略。
?
同步刷盤指的是 MQ 接收到生產(chǎn)的消息時，將消息先寫入到 OS cache 中，然后再將 OS cache 刷入到磁盤后，才返回 success 給生產(chǎn)者；與之對應(yīng)的是異步刷盤，異步刷盤指的是將將消息寫入到 OS cache 中后就返回 success 給生產(chǎn)者，然后由操作系統(tǒng)決定 OS cache 中的數(shù)據(jù)什么時候刷入到磁盤。顯然，同步刷盤雖然能保證數(shù)據(jù)不丟失，但是性能會比較低，同步刷盤時，MQ 的吞吐量沒有異步刷盤高。
?
3. 消費(fèi)者
- 關(guān)閉 Auto ACK。消費(fèi)到消息后，處理完業(yè)務(wù)邏輯后再手動提交 offset。
- 不使用異步線程池處理消息。
四、總結(jié)
保證消息不丟失是一個非常苛刻的要求，要保證消息不丟失就需要犧牲系統(tǒng)的性能(生產(chǎn)者的處理邏輯變復(fù)雜，MQ 的吞吐量降低，消費(fèi)者消費(fèi)速度下降等)，所以需要結(jié)合具體的業(yè)務(wù)場景來決定是不是需要百分百保證消息不丟失。通常而言，對于核心鏈路：如訂單、交易等相關(guān)的業(yè)務(wù)，基本都需要保證保證消息百分百不丟失。
大廠相關(guān)面經(jīng)
- 金三銀四跳槽季，美團(tuán)、字節(jié)、阿里、騰訊面經(jīng)
- 阿里面試題：線上接口變慢，如何排查
- 面試題：Zookeeper 實(shí)現(xiàn)分布式鎖的原理
- RocketMQ 事務(wù)消息如何保證數(shù)據(jù)的最終一致性