Kafka 如何保证消息不丢失？（Producer + Broker + Consumer 全链路解析）

在使用 Kafka 构建消息系统时，一个非常关键的问题是：

Kafka 如何保证消息不丢失？

如果消息系统出现丢数据的问题，可能会带来严重后果，例如：

• 订单消息丢失
• 支付结果丢失
• 用户行为日志不完整

Kafka 通过 Producer 发送确认机制 + Broker 副本机制 + Consumer 位移管理 等多层设计来保证消息可靠性。

本文从三个维度系统分析：

1. 生产者端如何保证消息发送可靠
2. Broker 端如何保证数据存储可靠
3. 消费者端如何保证消息被正确消费

---

一、生产者端：通过 acks 参数保障发送可靠性

Kafka 生产者通过 acks 参数控制消息确认机制，不同配置对应不同的可靠性等级。

1 acks = 0（最低可靠性）

acks=0

含义：

• 生产者发送消息后 不等待 Broker 响应
• 直接认为发送成功

特点：

• 发送效率最高
• 可能丢失消息

可能发生的情况：

• 网络抖动
• Broker 未成功写入消息
• Producer 已经认为发送成功

因此：

生产环境几乎不会使用 acks=0

适用场景：

• 对数据丢失不敏感的日志系统

---

2 acks = 1（默认配置）

acks=1

含义：

• Producer 只需要等待 Leader 副本写入成功并返回 ACK

流程：

Producer
   ↓
Leader Broker 写入日志
   ↓
返回 ACK

特点：

• 可靠性：中等
• 性能：中等

风险：

如果 Leader 写入成功后宕机，而 Follower 还未同步数据，新的 Leader 可能没有这条消息。

因此：

仍然存在少量消息丢失的风险。

适用场景：

• 日志系统
• 用户行为数据
• 允许少量数据丢失

---

3 acks = -1（或 acks = all，最高可靠性）

acks=-1
或
acks=all

含义：

Producer 需要等待：

Leader + ISR 中所有 Follower 副本都写入成功

才会返回 ACK。

流程：

Producer
   ↓
Leader 写入
   ↓
Follower 同步数据
   ↓
ISR 副本全部确认
   ↓
返回 ACK

特点：

• 可靠性：最高
• 性能：最低

适用场景：

• 金融系统
• 订单系统
• 支付系统

即：

对数据绝对不能丢失的业务场景。

---

二、Broker 端：通过副本机制保障数据可靠

Kafka 通过 副本（Replica）机制保证数据不会因为 Broker 故障而丢失。

每个 Topic 的分区都会有多个副本：

Leader 副本
Follower 副本

• Leader：负责读写
• Follower：负责同步数据

---

1 副本因子（replication.factor）

推荐配置：

replication.factor >= 3

示例：

Partition 0

Leader      Broker1
Follower    Broker2
Follower    Broker3

优点：

• 一个 Broker 宕机仍可正常工作
• 两个 Broker 宕机仍有数据副本

---

2 ISR 同步副本列表

Kafka 维护一个 ISR（In-Sync Replicas）列表：

ISR = 与 Leader 保持同步的副本

只有 同步状态的副本 才会进入 ISR。

---

3 min.insync.replicas

关键参数：

min.insync.replicas

示例配置：

min.insync.replicas = 2

含义：

当 Producer 使用：acks = all时，

ISR 中 至少需要 2 个副本成功写入，消息才算成功。

如果 ISR 副本数量不足：

Kafka 会 拒绝生产者写入请求。

好处：

避免数据只写入一个副本而导致丢失。

---

4 禁用非同步副本选举

关键配置：

unclean.leader.election.enable = false

含义：

当 Leader 宕机时：

• 只允许 ISR 中的副本被选举为新的 Leader
• 不允许 落后副本成为 Leader

如果开启该机制：

unclean.leader.election.enable = true

可能发生：

旧 Leader 有新数据
↓
Follower 没同步
↓
Follower 成为 Leader
↓
数据丢失

因此生产环境一般：

unclean.leader.election.enable = false

---

5 副本同步超时

参数：

replica.lag.time.max.ms

默认：

10s

含义：

如果 Follower 副本 10 秒内没有同步 Leader 数据：

• 会被踢出 ISR 列表

作用：

• 保证 ISR 中副本始终保持同步状态

---

三、Consumer 端：通过 Offset 管理保证消息不丢失

Kafka 消费者通过 Offset（位移）机制记录消息消费进度。

Offset 本质上就是：

消费者消费到哪个位置的标记

例如：

Topic: order-topic

offset 0
offset 1
offset 2
offset 3
offset 4

如果消费者已经消费到 offset=3，则表示：

0、1、2 已消费
3、4 未消费

---

1 自动提交 Offset

Kafka 默认配置：

enable.auto.commit = true

含义：

消费者会 定期自动提交 Offset。

优点：

• 使用简单
• 不需要手动管理

缺点：

可能导致 消息丢失或重复消费。

例如：

拉取消息
↓
自动提交 offset
↓
业务还没处理
↓
程序宕机

结果：

消息已经被标记为消费，但业务没处理 → 数据丢失

---

2 手动提交 Offset（推荐）

生产环境通常使用：

enable.auto.commit = false

消费流程：

拉取消息
↓
业务处理
↓
手动提交 offset

示例流程：

poll()
↓
处理业务逻辑
↓
commitSync()

这样可以保证：

只有业务处理成功后才提交 offset

如果程序宕机：

Kafka 会重新消费未提交的消息。

---

3 防止消息重复消费

Kafka 默认语义是：

At-Least-Once

即：

至少消费一次

可能会出现：

重复消费

常见解决方案：

1 幂等设计

例如数据库：

订单ID唯一

即使重复消费：

INSERT IGNORE

也不会产生错误。

---

2 去重表

业务系统维护：

message_id

消费前判断是否已经处理。

---

四、Kafka 保证消息不丢失的核心配置总结

层级	关键参数	作用
Producer	acks=all	确保所有副本写入成功
Broker	replication.factor=3	保证数据有多个副本
Broker	min.insync.replicas=2	保证至少两个副本同步
Broker	unclean.leader.election=false	防止落后副本成为 Leader
Consumer	enable.auto.commit=false	防止提前提交 offset

---

五、生产环境推荐配置

如果业务 绝对不能丢数据，通常建议：

acks=all
replication.factor=3
min.insync.replicas=2
unclean.leader.election.enable=false
enable.auto.commit=false

这样可以最大程度保证：

Kafka 在 Producer、Broker、Consumer 三个阶段都不会丢失消息。

---

六、总结

Kafka 通过三层机制保证消息可靠性：

1 Producer

通过 acks 机制确保消息成功写入 Broker。

2 Broker

通过 副本 + ISR + Leader 选举机制保证数据不丢。

3 Consumer

通过 Offset 管理 + 手动提交机制保证消息被正确消费。

因此完整链路是：

Producer
↓
Broker（副本存储）
↓
Consumer（Offset 管理）

理解这三个阶段，就可以完整回答一个经典面试问题：

Kafka 如何保证消息不丢失？

如果你正在准备后端面试，还可以继续深入 Kafka 相关问题：

• Kafka 如何保证消息顺序？
• Kafka 如何实现高吞吐？
• Kafka 如何实现 Exactly Once？

欢迎在评论区交流你在 Kafka 或消息队列使用中遇到的问题。