Kafka 消息不丢失：一次把话说清楚

一、Kafka 为啥会丢消息？

先泼一盆冷水：Kafka 本身不保证消息 100% 不丢。

丢不丢，取决于你怎么用它

• 你要是 acks=0，那就是“发出去就当成功”，消息随缘
• 你要是自动提交 Offset，那就是“吃没吃不重要，先结账”
• 你要是 ISR 副本只剩 Leader，那就是单点写入，翻车只差一次宕机

Kafka 给你的是工具箱，不是保险箱。

二、Kafka 的可靠性三板斧

1️⃣ 生产者：别太心急（acks=all）

acks = all

含义很朴素：

• acks=0：发完就跑 （最快，也最容易后悔）
• acks=1：Leader 说行就行 ️（Leader 一挂就凉）
• acks=all：ISR 集体通过 （最稳）

结论：要可靠，别犹豫，直接 acks=all。

2️⃣ Broker：设一道“安全底线”（min.insync.replicas ≥ 2）

min.insync.replicas = 2

这是 Kafka 的“保命配置”。

它的意思是：

️ 很多人踩过的坑：

• acks=all
• min.insync.replicas=1

这俩一搭配，效果等于：

正确姿势：

• acks=all
• min.insync.replicas ≥ 2

双保险，谁也别想偷懒。

3️⃣ 消费者：吃完再结账（手动提交 Offset）

enable.auto.commit = false

Kafka 的 Offset 提交，本质就是一句话：

如果你：

• 先提交 Offset
• 再处理业务

一旦中途宕机：

正确顺序永远是：

1. 拉消息
2. 执行业务逻辑
3. 确认成功
4. 手动提交 Offset

宁可重复消费，也不能直接丢。

三、ISR：Kafka 的“精英小群” ‍‍

ISR（In-Sync Replicas） 是 Kafka 里最容易被误解的概念。

它的规则很简单：

• Leader 永远在 ISR
• Follower 只要跟得上进度，就能进 ISR
• 跟不上（超过 replica.lag.time.max.ms）就被踢出去

重点来了：

所以 Kafka 才能又快又稳。

四、分区 vs 副本：一个管快，一个管命 ️

举个例子：

️ 记住一句铁律：

五、Kafka 的存储真相：一份数据，多组人看

Kafka 的磁盘上：

• 同一个 Topic 的数据只存一份
• 不会因为消费者组多就复制 N 份

那不同消费者怎么不冲突？

Offset 是消费者组自己的。

就像：

六、Rebalance：Kafka 最烦人的“集体开会”

Rebalance = 重新分配分区归属权。

触发条件很常见：

• 消费者上线 / 下线
• 分区数量变化
• 心跳超时

核心原则只有一条：

最佳实践：

• 消费者数量 ≈ 分区数量
• 稳定运行，少折腾

七、Leader 和 Follower 各司其职

• Leader：

  • 负责所有读写请求
  • 对外营业窗口

• Follower：

  • 只干一件事：同步 Leader
  • 不接客、不背锅

Leader 一旦宕机：

八、终极总结（一眼就够）

Kafka 不丢消息公式

acks = all
+ min.insync.replicas ≥ 2
+ 手动提交 Offset

Kafka 快的原因

分区并发 + 顺序写磁盘 + PageCache

Kafka 消费模型

一份数据 + 多组 Offset + 分区承包制