这是 Kafka 面试必问 + 生产必踩的核心问题，我用最清晰、最落地的方式讲透：为什么会丢消息/重复？怎么彻底解决？
一、先明确核心结论
Kafka 本身不保证绝对不丢、绝对不重复，它只保证 At-Least-Once（至少投递一次）。
- 至少投递一次 = 可能重复，不会丢失
- 想要不重复 = 业务自己做幂等
- 想要不丢失 = 配置 + 机制配合
第一部分：Kafka 消息丢失（3 个场景 + 解决方案）
消息丢失只会发生在 3 个环节：
- 生产者 → Broker
- Broker 自身
- Broker → 消费者
1. 生产者丢消息（最常见）
原因
生产者发送消息后没收到ACK，以为发送失败，却没重试，消息就丢了。
Kafka 默认是异步发送，不等待确认。
解决方案
# 必须等待所有副本同步成功才确认
acks=all# 发送失败无限重试（生产推荐）
retries=Integer.MAX_VALUE# 重试时保证消息顺序（重要）
max.in.flight.requests.per.connection=1# 开启生产者幂等（自动去重，防止重试导致重复）
enable.idempotence=true
2. Broker 丢消息
原因
- 消息刚写入 PageCache，Broker 宕机 → 数据丢失
- 副本没同步完，Leader 挂了 → 数据丢失
解决方案
# 主题必须至少 2 个副本
replication.factor=3# 至少 2 个副本同步成功才算写入成功
min.insync.replicas=2# 关闭异步刷盘，强制同步刷盘（生产不推荐，影响性能）
# log.flush.interval.messages=1
# log.flush.interval.ms=1000
最佳实践：不靠刷盘，靠多副本保证不丢。
3. 消费者丢消息（最容易踩坑）
原因
先提交偏移量，再处理消息 → 处理失败时，消息永远丢失。
解决方案
必须：先处理消息 → 成功后再提交偏移量
# 关闭自动提交
enable.auto.commit=false
消费逻辑：
while(true){拉取消息处理业务（入库/发请求）手动提交 offset
}
第二部分：Kafka 消息重复（3 个场景 + 解决方案）
重复比丢失更常见，无法完全避免，只能靠业务幂等解决。
重复的 3 个原因
- 生产者重试发送
- 消费者处理完没提交 offset 就宕机，重启后重复消费
- 重平衡（Rebalance）导致重复拉取
终极解决方案：业务幂等（唯一键去重）
方案 1：数据库唯一键（最简单）
- 每条消息生成 唯一消息ID
- 消费时：
INSERT ON DUPLICATE KEY UPDATE
方案 2：分布式锁（Redis）
- 消息ID 作为 key
- 消费前加锁，消费后释放
- 重复消息直接跳过
方案 3：Kafka 原生幂等 + 事务（精准一次）
# 生产者幂等
enable.idempotence=true# 生产者事务（跨分区有序）
transactional.id=order-123
注意：Kafka 事务只能保证 Kafka 内部不重复，无法保证业务不重复，最终还是要靠业务幂等。
第三部分：终极配置（生产直接复制）
生产者（不丢 + 不重复）
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
enable.idempotence=true
linger.ms=5
batch.size=16384
compression.type=lz4
消费者（不丢 + 可控重复）
enable.auto.commit=false
auto.offset.reset=earliest
max.poll.records=500
Broker（不丢）
min.insync.replicas=2
unclean.leader.election.enable=false
第四部分：一句话总结
消息丢失怎么处理？
- 生产者：acks=all + 重试 + 幂等
- Broker：多副本 + ISR 最小副本数
- 消费者：关闭自动提交，先消费后提交
消息重复怎么处理？
Kafka 无法杜绝重复，业务必须做幂等：
- DB 唯一键
- Redis 分布式锁
- 状态机判断
总结
- 丢失：配置可彻底解决
- 重复：配置只能减少，必须业务幂等
- Kafka 最佳可靠性：生产者幂等 + 多副本 + 手动提交偏移量 + 业务幂等