一、生產者端防丟失

1. 發送方式選擇

• 同步發送：使用 send() 方法，等待 Broker 確認響應（SendResult），確保消息已成功發送。
• 異步發送：使用 sendAsync() 方法并設置回調函數，處理發送成功 / 失敗的邏輯。
• 單向發送：使用 sendOneway()，不等待響應（適用于允許少量丟失的場景）。

2. 重試機制

• 設置 maxRetryTimesWhenSendFailed：生產者自動重試次數（默認 2 次）。
• 自定義異常處理：捕獲 MQClientException 或 RemotingException，手動重試。

二、Broker 端防丟失

1.消息持久化

2.主從復制

Broker消息的零丟失方案：

• 同步刷盤：在返回應用寫成功狀態前，消息已經被寫入磁盤。
• 異步刷盤：消息可能只是被寫入了內存的PAGECACHE，寫操作的返回快，吞吐量大；當內存里的消息量積累到一定程度時，統一觸發寫磁盤操作，快速寫入
• 同步復制：等Master和Slave均寫成功后才反饋給客戶端寫成功狀態
• 異步復制：只要Master寫成功即可反饋給客戶端寫成功狀態

推薦：

• 刷盤方式

Master和Slave都設置成ASYNC_FLUSH的異步刷盤

• 復制方式

Master配置成SYNC_MASTER 同步復制

三：消費者端防丟失

1.廣播消費（BROADCASTING）

2.事務消息（半消息）

3.死信隊列

怎么保證不丟失？

• 生產者

• • 開啟confirm模式,重試的機制

• rocketMQ

• • 開啟持久化（增大 commitLog 刷盤間隔）

• 消費者

• • ack的機制

消息持久化機制：Broker接收到消息后，會立即將消息寫入磁盤，并返回確認信息給生產者。RocketMQ支持同步刷盤和異步刷盤兩種方式，其中同步刷盤方式在消息寫入磁盤后才返回確認，可靠性更高

消費失敗后的常見的處理方法：

• 方式 1：返回 Action.ReconsumeLater（推薦） 重試
• 方式 2：返回 Null
• 方式 3：拋出異常