Kafka 如何保证消息不丢失？

核心回答

Kafka 的消息可靠性要沿生产者 → Broker → 消费者逐段建立可靠交接，关键是消息不能在“上一环认为完成、下一环却没有接住”的窗口里消失。

• 生产端：检查异步发送结果，失败或结果不确定时按策略重试。重要业务先留下可恢复的待发记录，不能只把消息放进客户端内存缓冲就返回最终成功。使用 acks=all 并配合幂等生产者，降低确认不足和发送重试带来的风险。
• Broker 端：为分区配置适当副本，结合 min.insync.replicas 限制可接受写入的同步副本条件，并采用安全的选主策略。消息保留期和容量要覆盖允许的故障、消费延迟与恢复时间。
• 消费端：业务真正处理并提交成功后，再提交相应消费进度；不要拿到消息或扔进内存线程池就认为处理完成。提交前崩溃可能重放，所以消费动作还要幂等，失败消息要有可追踪的重试和补偿。

常见目标是至少一次交付配合业务幂等。副本、ACK 和提交时机要一起工作，单独打开某个参数并不能覆盖整条链路。

进一步解释

acks=0、1、all 分别确认到哪里？

以 Kafka 4.1 为例：

• acks=0：不等待服务端确认，不能据此判断消息是否到达 Broker。
• acks=1：Leader 写入本地日志后即可确认，不等待全部同步副本；若它此时故障而其他副本还没接到记录，就有丢失风险。
• acks=all：等待当前同步副本集合确认，不是等待集群所有机器或所有配置副本，也不等于每条消息都立即完成物理刷盘。

4.1 文档中 acks 默认是 all，幂等生产者在没有冲突配置时也默认启用；实际配置可以覆盖或影响这些行为。幂等还要求兼容的重试和在途请求配置，不能一边关闭必要条件，一边假定重试自动去重。

重试也受可重试错误类型、交付超时等条件限制。发送最终失败后，应保留记录、告警并进入可恢复流程，而不是忽略回调；超时也可能只是确认丢失，重新发送仍需考虑重复。

副本数和 min.insync.replicas 怎样配合？

例如配置 3 个副本、min.insync.replicas=2，并由生产者使用 acks=all：当 ISR 有 3 个成员时，需要它们都确认，并不是任意 2 个确认就行；ISR 只剩 2 个时，需要这 2 个确认；少于要求时，相应写入应失败，而不是悄悄按单副本成功返回。

还要关注选主资格和副本故障域。Kafka 4.1 新集群默认启用 ELR，可保留某些已退出当前 ISR、但仍具备安全选主资格的副本，因此不能把“只能从当前 ISR 选 Leader”当作所有新版本的固定规则。也不应通过不干净选主，随意让缺少已确认数据的副本接管。

Kafka 通常依赖复制和恢复协议提供可靠性，不要求每次写入都 fsync。要讨论的是能承受哪些节点、磁盘或故障域失效；若所有有效数据副本都丢失，副本协议不能凭空恢复消息。

业务数据库与 Kafka 之间的窗口怎么处理？

例如异步任务先写入 MySQL，再发送任务 ID。如果数据库已提交、进程却在发送前退出，Kafka 的 acks 配置帮不上这一段。

可以在同一数据库事务中写任务和 Outbox 待发记录，提交后由投递程序发送并重试；也可按场景使用 CDC 等可靠事件方案。消息只带任务 ID 时，完整任务数据和必要版本还应能从权威存储取得，不能依赖已经丢失的进程内对象。

Kafka 事务可以原子提交适用的输出消息和消费位移，配合消费者隔离设置实现相应 Kafka 内处理语义；它不会自动把外部数据库更新或第三方调用纳入同一个事务。

消费进度什么时候提交？

重点是提交位置不能越过尚未可靠完成的业务。常见做法是关闭自动提交，在处理成功后手动提交；自动提交并非天然必丢，关键仍是处理、再次 poll 和提交之间的实际顺序。

并行处理一批消息时，要按分区追踪已经连续完成的进度，不能因为后面的任务先结束，就提交一个越过前面未完成任务的位置。进度提交失败或重新均衡，也可能导致已经完成的动作再次执行，应通过稳定业务键、数据库约束或同事务消费记录实现幂等。

常见追问

关掉自动提交，就不会丢了吗？

还不够。先提交再落库、异常被吞掉、只投递到不持久的内存队列、手动跳过失败位移，仍可能让业务漏处理。失败消息如果转移到其他 Topic 或补偿存储，也要确认转移成功，不能只打印日志后继续提交。

消费者恢复后，为什么有些消息已经读不到？

Kafka 清理日志不以“每个消费者都处理完”为前提。超过保留期、容量清理或某些压缩策略下，历史记录可能不再完整。因此需要监控积压与最老未完成消息的年龄，保留策略和业务补偿来源一起设计。

参考资料