在構建高可靠分布式系統時，確保業務數據庫與消息隊列（MQ）之間的一致性是一項核心挑戰。尤其當使用 Kafka 作為消息隊列中間件時，如何避免“數據庫寫入成功，但消息發送失敗”或“消息重復發送”等問題，成為系統架構必須解決的問題。
本文通過本地持久化 + 異步補償 + 冪等性控制，建立一套穩定、可觀測、可容災的消息保障機制。從設計與實現兩個角度保障生產者端消息不丟失。
一、Kafka 客戶端與服務端配置
為保障 Kafka 消息可靠性，需對客戶端與服務端分別進行關鍵參數配置。
1、Kafka 客戶端配置（Producer）
| 參數配置項 | 推薦值 | 說明 |
|---|---|---|
acks | all | 等待所有副本確認，確保寫入可靠性 |
enable.idempotence | true | 開啟冪等性保障，避免重復投遞 |
retries | 10 或更大 | 出現暫時性異常時自動重試 |
transactional.id | 必填（示例：tx-001） | 開啟事務消息發送功能，唯一標識 |
max.in.flight.requests.per.connection | 1~5（強烈推薦不超過5） | 控制并發發送請求數量，配合冪等性使用，避免亂序 |
2、Kafka 服務端配置（Broker）
| 參數配置項 | 推薦值 | 說明 |
|---|---|---|
replication.factor | 3 | 消息副本數，保障持久化可靠性 |
min.insync.replicas | 2 | 寫入至少需要的活躍副本數 |
unclean.leader.election.enable | false | 禁止選舉未同步的副本作為 leader，防止數據丟失 |
二、Java 程序端控制邏輯
為實現最終一致性，Kafka 消息發送與數據庫操作解耦，并通過本地持久化文件中轉，采用“同步寫業務 + 異步投遞消息”的策略。目錄結構設計如下：
1、文件目錄結構
| 目錄 | 用途說明 |
|---|---|
tmp/ | 臨時目錄，數據庫事務提交前的消息文件 |
pending/ | 已提交數據庫事務，待異步發送消息 |
sending/ | 正在處理中的消息 |
success/ | 發送成功的消息文件 |
failed/ | 超過最大重試次數的失敗消息文件 |
2、生成本地消息文件（同步流程）
此流程在主業務線程中執行，確保在數據庫操作成功的前提下生成消息。
2.1、開啟數據庫事務
- 啟動數據庫事務，確保業務數據變更與消息生成的原子性。
2.2、執行業務邏輯 + 寫入臨時消息文件
- 執行數據庫 insert/update 等操作。
- 同時將待發 Kafka 消息內容寫入
tmp/目錄。
2.3、提交數據庫事務
- 數據庫操作無異常，提交事務，確保業務數據持久化。
2.4、原子移動文件至 pending/
- 將
tmp/文件原子性移動至pending/，避免處理未完成數據。
3、異步掃描并發送 Kafka 消息（異步流程）
異步線程或定時任務不斷掃描 pending/ 目錄，處理待發消息，確保最終一致性。
3.1、準備階段
a. 掃描 pending/ 目錄，按時間順序選取文件。
b. 原子性將文件移動至 sending/，鎖定處理權限。
c. 讀取文件內容，提取 messageId、topic 等。
3.2、預校驗階段
a. 檢查重試次數是否超限
- 若超限，文件移動至
failed/，記錄失敗信息。 - 若未超限，繼續后續流程。
b. 執行冪等性判斷
- 若 messageId 已被處理，直接將文件移動至
success/，跳過投遞。 - 否則，繼續發送。
3.3、Kafka 消息發送階段
a. 開啟 Kafka 事務（KafkaProducer.beginTransaction）
b. 執行 send 操作將消息發送到 Kafka
c. 若成功，提交事務（KafkaProducer.commitTransaction）
3.4、狀態持久化階段
a. 發送成功后，將文件從 sending/ 移動至 success/，歸檔處理。
b. 若發送失敗，Kafka 回滾事務，并記錄重試次數，待下輪重試。
三、人工定期巡檢機制
為進一步提升系統穩定性與可觀測性，建議運維或監控團隊定期檢查以下目錄狀態：
| 檢查對象 | 檢查內容說明 |
|---|---|
pending/ | 是否存在長時間未處理的消息文件 |
sending/ | 是否存在卡死、長時間未移動的消息文件 |
failed/ | 是否出現大量失敗文件，需分析失敗原因 |
| 磁盤容量 | 監控磁盤是否存滿，避免寫入失敗 |
| 文件異常格式 | 是否存在不完整或格式異常的消息文件 |
可配合 ELK、Prometheus、Grafana 等工具，實時采集告警指標。
四、方案選型解析
為什么選擇本地文件作為中間狀態存儲？
| 對比 | 落數據庫消息表 | 落本地文件 |
|---|---|---|
| 寫入性能 | 網絡 + SQL + I/O，慢 | 本地寫入，極快（一次磁盤IO操作） |
| 系統解耦 | 耦合數據庫事務 | 解耦業務邏輯 |
| 容錯能力 | 依賴數據庫高可用 | 磁盤寫入可恢復 |
| 恢復能力 | 數據難提取排查 | 文件可查、易追蹤 |
結論： 本地文件方案具備更高的吞吐、更小的耦合度和更強的可控性，更適合用于消息可靠性極致要求場景。
五、容錯機制總結表
| 異常場景 | 處理機制 |
|---|---|
| 數據庫事務失敗 | 臨時文件未移動，消息不會被投遞 |
| 寫入本地文件失敗 | 事務未提交，整體失敗 |
| Kafka send 異常 | Kafka事務回滾，重試 |
| Kafka事務提交失敗 | 消息文件未進入 success，重試 |
| 異步線程宕機 | 任務下次自動拉起時繼續掃描處理 |
| 機器宕機 | 文件持久化保存，重啟后自動恢復 |
| 達到重試上限 | 進入 failed/，等待人工干預 |
六、總結
本方案以本地文件系統為核心緩沖機制，結合 Kafka 原生事務、冪等性保障機制及 Java 程序控制能力，實現了生產端消息“必達”保障體系。具備如下特性：
- 強一致性保障：業務與消息兩階段提交，天然避免消息丟失
- 最終一致性：異步重試機制 + Kafka事務補償
- 穩定可靠性：本地磁盤可控性強，適合高并發大流量
- 可擴展可觀測：異步線程、人工巡檢、狀態文件清晰明了
可廣泛應用于 金融、訂單、庫存、電商、支付等高可靠性場景。
