MQ為什么會丟消息？如何保證不丟失消息
本文轉載自微信公眾號「菜鳥飛呀飛」，作者劉進坤。轉載本文請聯系菜鳥飛呀飛公眾號。
一、前言
面大廠時，MQ 這一中間件基本都是必問的，本文是面試時被問到的其中一題的答案。
二、為什么丟消息
一條消息從產生到被消費，中間會經歷三個環節：生產者、MQ 內部、消費者，消息在這三個環節中均有可能出現丟失。
1. 在生產者環節丟失
當生產者往 MQ 中寫數據時，可能出現網絡故障，消息壓根就沒到達 MQ 內部，生產者端對這個異常沒有捕獲，不做任何處理，這種場景會導致消息丟失。
當消息達到 MQ 所在的機器，但是 MQ 出現了異常，返回異常給生產者端，生產者對異常沒做相應處理，導致消息丟失
2. 在 MQ 環節丟失
當消息達到 MQ 內部后，消息會先存于內存當中，然后再持久化到磁盤。如果在消息處于內存當中，還未來得及刷入磁盤時，MQ 所在機器宕機，此時，消息會丟失。
即使消息持久化到磁盤了，但當前機器的磁盤發生損壞，消息依舊會丟失。
3. 在消費者環節丟失消息
- 當消息達到消費者端時，如果消費者開啟了 Auto ACK，那么消費者消費到消息后，就會自動提交 offset 到 MQ，如果此時消費者還沒來得及處理消息對應的業務邏輯，機器宕機了或者被新手 kill -9 pid 了，此時消息也就被丟失了。即使機器重新恢復后，由于已經提交了之前消息的 offset，所以 MQ 不會再將之前的消息推送給消費者，因此這條消息丟失。(這也是很多文章都說不準使用 kill -9 pid 的其中原因之一)
- 消費者沒有開啟 Auto ACK，但是消費者消費到消息后，將消息扔到了線程池，然后提交 offset，讓線程池異步去處理消息。如果線程池中的任務還沒處理完，機器宕機或者 OOM 等異常，這也將導致消息沒被處理，從而丟失。
三、如何保證不丟消息
消息在上述三個環節均有可能出現丟失，因此需要保證上述這三個環節均不出現丟數據的可能，才能完全保證消息不丟失。
1. 生產者
當往 MQ 中寫消息出現異常時，采用 try...catch... 捕獲異常，在異常代碼塊中重試。
如果是 RocketMQ，可以直接使用 RokcetMQ 的事務消息，來保證消息不丟失。至于為什么 RocketMQ 為什么能保證消息不丟失。
2. MQ
對于 MQ 而言，要保證消息不丟失，一方面是要保證消息要持久化到磁盤，另一方面是需要保證消息有多個副本。在不同的 MQ 中，對這兩點的處理方式均不太一樣，下面主要以 kafka 和 RocketMQ 為例說明。
對于 kafka 而言，需要保證如下三點：
- 要求每個 partition 的副本數大于 1(replication factor > 1)
- 要求 kafka 服務端設置 broker.insync.replicas 參數的值大于 1，它的意思是要求至少有一個 flower 在和 leader 同步
- 將 acks=all，在寫數據時，要求消息寫到所有的 leader 和 flower 之后，才認為消息寫成功。
對于 RocketMQ 而言，需要保證以下幾點：
- 基于 Dledger 的 broker 主從架構，每個主 broker 需要掛至少 2 個 slave broker。
- 采用同步刷盤策略。
同步刷盤指的是 MQ 接收到生產的消息時，將消息先寫入到 OS cache 中，然后再將 OS cache 刷入到磁盤后，才返回 success 給生產者;與之對應的是異步刷盤，異步刷盤指的是將將消息寫入到 OS cache 中后就返回 success 給生產者，然后由操作系統決定 OS cache 中的數據什么時候刷入到磁盤。顯然，同步刷盤雖然能保證數據不丟失，但是性能會比較低，同步刷盤時，MQ 的吞吐量沒有異步刷盤高。
3. 消費者
關閉 Auto ACK。消費到消息后，處理完業務邏輯后再手動提交 offset。
不使用異步線程池處理消息。
四、總結
保證消息不丟失是一個非常苛刻的要求，要保證消息不丟失就需要犧牲系統的性能(生產者的處理邏輯變復雜，MQ 的吞吐量降低，消費者消費速度下降等)，所以需要結合具體的業務場景來決定是不是需要百分百保證消息不丟失。通常而言，對于核心鏈路：如訂單、交易等相關的業務，基本都需要保證保證消息百分百不丟失。
