在构建高可靠分布式系统时，确保业务数据库与消息队列（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事务补偿
- 稳定可靠性：本地磁盘可控性强，适合高并发大流量
- 可扩展可观测：异步线程、人工巡检、状态文件清晰明了
可广泛应用于 金融、订单、库存、电商、支付等高可靠性场景。
