作者：江景行-645｜8 年全栈｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G，NVMe SSD）、Spring Kafka 3.1、Java 17、MySQL 8.0 兜底
一、现象：kill -9 之后，已 ack 的 2,347 条消息「蒸发」了
去年 8 月，我们给一个风控事件流接了 Kafka 3.5.1（KRaft 模式，3 broker，8C32G，NVMe SSD），topic risk-event，RF=3，min.insync.replicas=2，acks=all，日均 1.2 亿条，峰值 2.8 万 msg/s。
压测那天，运维做了一次「broker 宕机演练」：kill -9 了 broker-1（leader 所在节点）。预期是「leader 切到 broker-2，ISR 收缩到 2，producer 端最多短暂报 LeaderNotAvailable，数据不丢」。
结果：
- producer 端 0 条 NotEnoughReplicas、0 条 LeaderNotAvailable（因为 acks=all 在 ISR=2 时仍然合法）
- broker-2 接管 leader 后，
__consumer_offsets正常、消费组 lag 正常 - 但对账系统报了 2,347 条事件缺失（按 eventId 去重，下游业务库里查不到）
- 这些 eventId 对应的消息，producer 端都拿到了 success 回调（
RecordMetadata.offset()正常返回）
第一反应：「acks=all 怎么还可能丢？」排查了一圈 ISR、min.insync.replicas、unclean.leader.election，全都没问题。最后定位到：broker-1 的 page cache 里有 2,347 条消息还没 fsync 到 NVMe，kill -9 直接把这些 dirty page 冲掉了。
二、原理：acks 的语义是「写入 log」，不是「fsync」
把 Kafka 的写路径拆开看：
- producer 端
acks=all的等待对象：是「所有 ISR 内的 broker 都把消息写入了 log 文件」，不是「fsync 到磁盘」。 - broker 端「写入 log 文件」的真实动作：是
FileChannel.write()，数据进入 OS page cache，不触发 fsync。 - fsync 的触发时机：
log.flush.interval.messages（默认 10000）：0.8 之前的版本会在这个阈值触发 fsync，0.8+ 这个参数被标记为 deprecated，实际是 no-op（Kafka 源码里Log.flush()的注释明确说「this is a hint to the OS」）log.flush.scheduler.interval.ms（默认 1000ms）：同上，0.8+ 是 no-op- 真正的 fsync 时机由 OS 决定：Linux 的
dirty_writeback_centisecs（默认 500 = 5 秒）和dirty_ratio（默认 20%）
所以：acks=all 成功后，数据最坏情况下可能在 page cache 里停留 5 秒（或直到 dirty_ratio 触发）。在这 5 秒窗口内，broker 宕机（kill -9 / 断电 / OOM / kernel panic），已 ack 的消息就会丢。
这里有一个常见的误解：很多人把 acks=all 理解为「等所有副本都落盘」，实际上 Kafka 的「落盘」语义是「写入 log 文件（page cache）」，不是「fsync 到磁盘」。这是两个完全不同的概念。
三、具体做法：验证 + 兜底
1. 验证 fsync 频率（确认 page cache 语义）
# 在 broker 节点上，strace 跟踪 broker 进程的 fsync 调用
# 找到 broker 的 log 文件 fd（通常是 /var/lib/kafka-logs/ 下的 .log 文件）
strace -e trace=fsync,fsync2 -p <kafka_pid> -tt 2>&1 | grep -E '\.log'
预期看到：fsync 调用频率远低于消息写入频率，且间隔不规律（由 OS 决定）。如果看到 fsync 间隔在 1~5 秒之间波动，说明 page cache 语义成立。
2. 业务侧兜底（推荐）
既然 Kafka 的可靠性承诺是「至少一次」（at-least-once），不是「持久化」，业务侧必须：
- 幂等：消费端按 eventId 去重（唯一索引），重复消费无副作用
- 重放：producer 端保留 eventId + payload 的本地日志（至少 7 天），宕机后从日志重放
- 对账：T+1 对账系统按 eventId 全量比对，发现 gap 时从 producer 日志补发
3. 配置层面的「伪保证」（不推荐但常见）
# 这些配置在 0.8+ 基本无效，但很多人还在用
log.flush.interval.messages=1
log.flush.scheduler.interval.ms=1000
不要依赖这两个参数。Kafka 官方文档明确说：
"These settings are only hints to the OS, and the actual flush timing is determined by the OS."
4. 真正的「持久化」方案（如果业务要求）
- 改 Kafka 源码：在
Log.append()后加FileChannel.force(true)（O_DSYNC），代价是吞吐下降 50%+ - 用 SSD +
fsync触发策略：部分云厂商的 SSD 支持fsync在 1ms 内完成，但仍然是 OS 调度 - 用 RocksDB 后端：Kafka 3.6+ 支持 RocksDB 作为 log 后端，RocksDB 自带 WAL + fsync，但这是实验特性
四、踩过的坑
log.flush.interval.messages=1的「伪保证」：我们最初以为这个配置能保证「每条消息都 fsync」，结果压测里 kill -9 还是丢了 2,347 条。查源码才发现 0.8+ 这个参数是 no-op。strace的 fd 混淆：broker 进程同时打开 log 文件、socket、mmap 的 heap，strace 里 fsync 调用的 fd 需要和 log 文件的 fd 对应，否则会误判。- NVMe SSD 的「假持久化」：NVMe 的 page cache 在 OS 层，不是设备层。
kill -9冲掉的是 OS page cache，不是 NVMe 的 DRAM cache（NVMe 的 DRAM cache 有掉电保护，但 OS page cache 没有）。 - KRaft 模式的特殊性：KRaft 的 metadata log（
__cluster_metadata）同样走 page cache，controller 宕机时 metadata 也可能丢（虽然概率低，因为 metadata 写入频率低）。
五、结论与可复用清单
- Kafka 的可靠性承诺是「至少一次」，不是「持久化」。acks=all 只保证「写入 log 文件（page cache）」，不保证 fsync。
log.flush.interval.messages/log.flush.scheduler.interval.ms在 0.8+ 是 no-op，不要依赖。- 业务侧必须幂等 + 重放 + 对账，这是 Kafka 官方文档明确要求的。
- 压测时做
kill -9演练，验证「已 ack 的消息是否真的不丢」，别只在正常场景下测。 - 如果业务要求「持久化」，要么改 Kafka 源码加 O_DSYNC，要么用 RocksDB 后端（3.6+），要么接受「至少一次」+ 业务幂等。
补充一点：社区里已有两篇讲 acks=all 的丢失矩阵和 ISR 收缩静默窗口的文章，角度分别是「ISR 边界判定」和「rack-aware 故障下的静默窗口」，机制拆解都很清楚。我这篇是补一个更底层的视角：即使 ISR 完整、min.insync.replicas 满足、acks=all 成功，数据在 broker 的 page cache 里还没 fsync 时宕机，仍会丢。这是 Kafka 可靠性承诺的「最后一公里」，也是最容易被忽略的一层。