[[385981]]

本文轉(zhuǎn)載自微信公眾號(hào)「菜鳥(niǎo)飛呀飛」，作者劉進(jìn)坤。轉(zhuǎn)載本文請(qǐng)聯(lián)系菜鳥(niǎo)飛呀飛公眾號(hào)。

一、前言

面大廠(chǎng)時(shí)，MQ 這一中間件基本都是必問(wèn)的，本文是面試時(shí)被問(wèn)到的其中一題的答案。

二、為什么丟消息

一條消息從產(chǎn)生到被消費(fèi)，中間會(huì)經(jīng)歷三個(gè)環(huán)節(jié)：生產(chǎn)者、MQ 內(nèi)部、消費(fèi)者，消息在這三個(gè)環(huán)節(jié)中均有可能出現(xiàn)丟失。

1. 在生產(chǎn)者環(huán)節(jié)丟失

當(dāng)生產(chǎn)者往 MQ 中寫(xiě)數(shù)據(jù)時(shí)，可能出現(xiàn)網(wǎng)絡(luò)故障，消息壓根就沒(méi)到達(dá) MQ 內(nèi)部，生產(chǎn)者端對(duì)這個(gè)異常沒(méi)有捕獲，不做任何處理，這種場(chǎng)景會(huì)導(dǎo)致消息丟失。

當(dāng)消息達(dá)到 MQ 所在的機(jī)器，但是 MQ 出現(xiàn)了異常，返回異常給生產(chǎn)者端，生產(chǎn)者對(duì)異常沒(méi)做相應(yīng)處理，導(dǎo)致消息丟失

2. 在 MQ 環(huán)節(jié)丟失

當(dāng)消息達(dá)到 MQ 內(nèi)部后，消息會(huì)先存于內(nèi)存當(dāng)中，然后再持久化到磁盤(pán)。如果在消息處于內(nèi)存當(dāng)中，還未來(lái)得及刷入磁盤(pán)時(shí)，MQ 所在機(jī)器宕機(jī)，此時(shí)，消息會(huì)丟失。

即使消息持久化到磁盤(pán)了，但當(dāng)前機(jī)器的磁盤(pán)發(fā)生損壞，消息依舊會(huì)丟失。

3. 在消費(fèi)者環(huán)節(jié)丟失消息

• 當(dāng)消息達(dá)到消費(fèi)者端時(shí)，如果消費(fèi)者開(kāi)啟了 Auto ACK，那么消費(fèi)者消費(fèi)到消息后，就會(huì)自動(dòng)提交 offset 到 MQ，如果此時(shí)消費(fèi)者還沒(méi)來(lái)得及處理消息對(duì)應(yīng)的業(yè)務(wù)邏輯，機(jī)器宕機(jī)了或者被新手 kill -9 pid 了，此時(shí)消息也就被丟失了。即使機(jī)器重新恢復(fù)后，由于已經(jīng)提交了之前消息的 offset，所以 MQ 不會(huì)再將之前的消息推送給消費(fèi)者，因此這條消息丟失。(這也是很多文章都說(shuō)不準(zhǔn)使用 kill -9 pid 的其中原因之一)
• 消費(fèi)者沒(méi)有開(kāi)啟 Auto ACK，但是消費(fèi)者消費(fèi)到消息后，將消息扔到了線(xiàn)程池，然后提交 offset，讓線(xiàn)程池異步去處理消息。如果線(xiàn)程池中的任務(wù)還沒(méi)處理完，機(jī)器宕機(jī)或者 OOM 等異常，這也將導(dǎo)致消息沒(méi)被處理，從而丟失。

三、如何保證不丟消息

消息在上述三個(gè)環(huán)節(jié)均有可能出現(xiàn)丟失，因此需要保證上述這三個(gè)環(huán)節(jié)均不出現(xiàn)丟數(shù)據(jù)的可能，才能完全保證消息不丟失。

1. 生產(chǎn)者

當(dāng)往 MQ 中寫(xiě)消息出現(xiàn)異常時(shí)，采用 try...catch... 捕獲異常，在異常代碼塊中重試。

如果是 RocketMQ，可以直接使用 RokcetMQ 的事務(wù)消息，來(lái)保證消息不丟失。至于為什么 RocketMQ 為什么能保證消息不丟失。

2. MQ

對(duì)于 MQ 而言，要保證消息不丟失，一方面是要保證消息要持久化到磁盤(pán)，另一方面是需要保證消息有多個(gè)副本。在不同的 MQ 中，對(duì)這兩點(diǎn)的處理方式均不太一樣，下面主要以 kafka 和 RocketMQ 為例說(shuō)明。

對(duì)于 kafka 而言，需要保證如下三點(diǎn)：

1. 要求每個(gè) partition 的副本數(shù)大于 1(replication factor > 1)
2. 要求 kafka 服務(wù)端設(shè)置 broker.insync.replicas 參數(shù)的值大于 1，它的意思是要求至少有一個(gè) flower 在和 leader 同步
3. 將 acks=all，在寫(xiě)數(shù)據(jù)時(shí)，要求消息寫(xiě)到所有的 leader 和 flower 之后，才認(rèn)為消息寫(xiě)成功。

對(duì)于 RocketMQ 而言，需要保證以下幾點(diǎn)：

1. 基于 Dledger 的 broker 主從架構(gòu)，每個(gè)主 broker 需要掛至少 2 個(gè) slave broker。
2. 采用同步刷盤(pán)策略。

同步刷盤(pán)指的是 MQ 接收到生產(chǎn)的消息時(shí)，將消息先寫(xiě)入到 OS cache 中，然后再將 OS cache 刷入到磁盤(pán)后，才返回 success 給生產(chǎn)者;與之對(duì)應(yīng)的是異步刷盤(pán)，異步刷盤(pán)指的是將將消息寫(xiě)入到 OS cache 中后就返回 success 給生產(chǎn)者，然后由操作系統(tǒng)決定 OS cache 中的數(shù)據(jù)什么時(shí)候刷入到磁盤(pán)。顯然，同步刷盤(pán)雖然能保證數(shù)據(jù)不丟失，但是性能會(huì)比較低，同步刷盤(pán)時(shí)，MQ 的吞吐量沒(méi)有異步刷盤(pán)高。

3. 消費(fèi)者

關(guān)閉 Auto ACK。消費(fèi)到消息后，處理完業(yè)務(wù)邏輯后再手動(dòng)提交 offset。

不使用異步線(xiàn)程池處理消息。

四、總結(jié)

保證消息不丟失是一個(gè)非常苛刻的要求，要保證消息不丟失就需要犧牲系統(tǒng)的性能(生產(chǎn)者的處理邏輯變復(fù)雜，MQ 的吞吐量降低，消費(fèi)者消費(fèi)速度下降等)，所以需要結(jié)合具體的業(yè)務(wù)場(chǎng)景來(lái)決定是不是需要百分百保證消息不丟失。通常而言，對(duì)于核心鏈路：如訂單、交易等相關(guān)的業(yè)務(wù)，基本都需要保證保證消息百分百不丟失。