存储引擎:日志分段,索引,零拷贝

为什么 Kafka 把消息放磁盘

直觉上磁盘慢.一块机械盘随机写 4KB 只有 100 次/s 左右,算下来约 0.4MB/s,所以大多数消息中间件把队列放内存,磁盘只做持久化兜底.

Kafka 反其道而行:所有消息一进来就落磁盘,吞吐反而甩开内存型中间件.原因在于磁盘的两种用法差距悬殊:

4KB 随机写:100 IOPS × 4KB ≈ 0.4 MB/s
顺序写:一次寻道后持续写,HDD 也能到 100+ MB/s

差距:两个数量级

消息队列的负载特征天然适合顺序写:写是追加,读大多是顺序消费.Kafka 把这一特征用到了极致.

传统数据库为什么不行?MySQL 用 B+ 树组织数据,写一条消息 = 定位叶子页(随机 IO)+ 更新索引(更多随机 IO).在"追加日志"这个场景里,B+ 树的结构维护全是浪费.

Kafka 官方早期的基准测试:3 台廉价服务器,200 万次写入/s,300 万次读取/s.支撑这个数字的是本篇要拆的三个机制:日志分段、稀疏索引、零拷贝.

Partition 目录:日志分段

日志分段(Log Segment):Partition 在磁盘上不是一个无限增长的文件,而是按固定大小切成的一段段文件,每段有一个 base offset.

第 02 篇说过 Partition 是 append-only log.落在磁盘上,一个 Partition 是一个目录(log.dirs 下),目录里是若干组段文件:

/bitnami/kafka/data/order-events-0/            ← 一个 Partition 一个目录
├── 00000000000000000000.log                   ← 段 1,base offset 0
├── 00000000000000000000.index                 ← 段 1 的偏移量索引
├── 00000000000000000000.timeindex             ← 段 1 的时间索引
├── 00000000000000942650.log                   ← 段 2,base offset 942650
├── 00000000000000942650.index
├── 00000000000000942650.timeindex
├── partition.metadata                         ← 分区元数据(KRaft)
└── leader-epoch-checkpoint                    ← leader 任期检查点

为什么要分段

单文件无限追加有三个问题:

分段后,正在写入的只有最后一个段(active segment),其余段全部只读.删除、归档、索引加载都只发生在旧段上,不碰写入路径.

段的命名与滚动

• 文件名是段的 base offset(该段第一条消息的 offset),20 位补零
• 写满 log.segment.bytes(默认 1GB)或到达 log.segment.ms(默认 7 天)就滚动,开新段
• 段内 offset 用相对值编号:段的 base offset 记作 0

动手验证:拆开一个 Partition 目录

第 07 篇的 docker-compose 集群数据在容器的 /bitnami/kafka/data.直接进去看:

docker compose exec kafka-0 bash

# 如果 order-events 还没建,按第 07 篇的步骤先创建
# 造点数据(交互式,回车即发一条,Ctrl+C 退出)
kafka-console-producer.sh --topic order-events \
  --property "parse.key=true" --property "key.separator=:" \
  --bootstrap-server localhost:19092
# 输入几十条: user-1:{"action":"purchase"}

# 退出 producer 后看分区目录
ls -lh /bitnami/kafka/data/order-events-0/

输出类似:

-rw-r--r-- 1 1001 root 7.6K ... 00000000000000000000.index
-rw-r--r-- 1 1001 root  12K ... 00000000000000000000.log
-rw-r--r-- 1 1001 root  12K ... 00000000000000000000.timeindex
-rw-r--r-- 1 1001 root  74B ... leader-epoch-checkpoint
-rw-r--r-- 1 1001 root  78B ... partition.metadata

只有一组段文件,因为数据量远没到 1GB,还在第一个段里.如果用过幂等 Producer,还会有 .snapshot 文件(生产者状态).

用 kafka-dump-log.sh 看段内容:

kafka-dump-log.sh --files /bitnami/kafka/data/order-events-0/00000000000000000000.log \
  --print-data-log | head -5

baseOffset: 0 lastOffset: 0 ... position: 0   CreateTime: 1725468000000 ... isvalid: true
baseOffset: 1 lastOffset: 1 ... position: 356 CreateTime: 1725468012000 ... isvalid: true
baseOffset: 2 lastOffset: 2 ... position: 712 CreateTime: 1725468024000 ... isvalid: true

baseOffset 是逻辑序号,position 是消息在 .log 文件里的物理字节位置.索引做的事就是在这两者之间搭桥.

再看索引文件:

kafka-dump-log.sh --files /bitnami/kafka/data/order-events-0/00000000000000000000.index

offset: 0 position: 0
offset: 3 position: 1068
offset: 6 position: 2136

索引条目远少于消息条数(每隔若干 KB 才记一条),这就是稀疏索引的设计.

稀疏索引:从 Offset 到物理位置

Consumer 发来 FetchRequest(offset=5),Broker 怎么知道这条消息在文件哪个字节?

查找流程

FetchRequest offset=5
        │
        ▼
 1. 定位段:内存中的段列表按 base offset 有序,二分找到包含 offset=5 的段
        │     (段 0 的区间是 [0, 942650) → 命中段 0)
        ▼
 2. 查偏移索引:二分查找 ≤ 5 的最大条目 → offset=3, position=1068
        │
        ▼
 3. 顺序扫:从 position=1068 往后读,跳过 offset 3, 4,停在 5

索引文件是 mmap 进内存的,二分查找只读内存,不发起磁盘 IO.找到 position 后最多顺序扫 log.index.interval.bytes(默认 4KB)的数据量.

为什么索引是稀疏的

条目格式:relativeOffset(4 字节) + position(4 字节),8 字节一条.relativeOffset 是相对段 base offset 的差值,绝对值不重复占位.1GB 的段,索引文件才 2MB 左右,可以整个 mmap 到内存.

时间索引:按时间找 Offset

.timeindex 存的是 timestamp(8 字节)+ relativeOffset(4 字节),同样稀疏.

它服务的是"按时间定位"的场景.第 07 篇用过的 --to-datetime 重置 offset,原理就是二分时间索引找到该时间点最近的 offset,再重置.

写入路径与读取路径

存储引擎的两条核心路径,决定了吞吐的上限.

写入:顺序追加 + Page Cache

Broker 收到 ProduceRequest 后:

Producer batch ──► Broker 网络线程
                       │
                       ▼
             active segment 末尾追加(顺序写)
                       │
                       ▼
             Linux Page Cache(内存)   ← 到这里就返回 ack 给 Producer
                       │
                       ▼
               后台异步:OS 按水位刷盘;副本同步(下一篇讲)

三个关键点:

1. 写入只到 page cache 就返回.Kafka 默认不主动 fsync(log.flush.interval.messages / log.flush.interval.ms 默认不限制),刷盘时机交给操作系统.内存写入的延迟是微秒级.
2. 顺序追加没有寻道.写磁头几乎不用移动,HDD 也能跑满带宽.
3. 单写者模型.每个 Partition 同一时刻只有 leader 一个写入者,没有并发写竞争,不需要加锁和随机定位.

那"写 page cache 就返回"是不是不可靠?单机看是的,但 Kafka 的可靠性模型建立在跨机器副本上(第 06 篇的 acks=all 链条):Leader 内存里的数据同时抄给了 Follower,一台机器断电,副本顶上.对每条消息都 fsync 会摧毁吞吐,只有少数强一致性场景才开 flush.messages=1.

读取:零拷贝

Consumer 拉取时,Broker 用上一节的索引定位后,大头是传输:一次 fetch 动辄几 MB.传统网络服务的读取路径:

传统路径:read() + write(),4 次拷贝,4 次上下文切换

  磁盘 ──DMA──► 内核 page cache ──CPU──► 用户态 buffer ──CPU──► socket buffer ──DMA──► 网卡

  数据必须进用户态,应用才能操作;再拷回内核,才能发出去

Kafka Broker 只是"转发",不解包消息内容(压缩 batch 原样转发),数据根本没必要进用户态:

sendfile 路径:2 次拷贝,2 次上下文切换

  磁盘 ──DMA──► 内核 page cache ──DMA(scatter-gather)──► 网卡

  数据全程在内核态流动,应用只调一次 sendfile(),不参与搬运

Java 里对应 FileChannel.transferTo,底层就是 Linux 的 sendfile.效果对比:

消息不经过 JVM 堆,不产生 GC 压力,CPU 只负责调度和网络栈.这就是"3 台机器 300 万次读取/s"的来源.

日志清理:Retention 与 Compaction

消息不会永久保留.清理有两种策略,由 Topic 的 cleanup.policy 决定.

delete:按时间/大小整段删(默认)

segment 0                  segment 1                  segment 2(active)
base=0,最后写入 8 天前      base=942650,3 天前          base=1885300,正在写
      │                           │                           │
      ▼                           ▼                           ▼
  整段删除,文件 unlink          保留                        保留

• 判断依据是段的最后一条消息时间戳(超过 log.retention.hours 默认 7 天)或总大小超过 log.retention.bytes
• 删除粒度是整段,一个 unlink 系统调用,成本极低
• 正在写的 active segment 永远不会被删
• 后台线程每 log.retention.check.interval.ms(默认 5 分钟)检查一次

compact:按 Key 保留最新值

cleanup.policy=compact 时,Broker 定期重写旧段,每个 Key 只留最后一条消息:

重写前:offset 0  key=user-1  value=v1
       offset 1  key=user-2  value=v1
       offset 2  key=user-1  value=v2     ← 旧值
       offset 3  key=user-1  value=v3     ← 最新,保留

重写后:offset 1  key=user-2  value=v1
       offset 3  key=user-1  value=v3

compact 后消息仍然有序,但 offset 出现空洞(第 02 篇提过"offset 不连续也合法").__consumer_offsets 用的就是 compact 策略(第 04 篇).

选型:事件流、审计日志用 delete;状态表、offset 存储用 compact.

生产注意事项

下一篇进入副本机制与 ISR:leader/follower 怎么同步,什么时候消息才算"已提交",ISR 为什么缩容.