Kafka 存储内核：日志段、留存策略与日志压缩

Kafka 的「日志」不是打印的日志，而是追加式写的分片文件——它是 Kafka 高性能的物理基础，也是磁盘消耗与维护的源头。本文深入存储层：日志段怎么组织、留存怎么回收、Compact 主题怎么压缩，以及磁盘问题怎么排查。

1. 日志段的物理结构

1.1 LogSegment 与三类文件

Kafka 把一个主题分区的数据按**日志段（LogSegment）**组织。每个段包含三个配套文件：

# 一个日志段的文件组成
# xxx.log      实际消息数据（追加写）
# xxx.index    稀疏偏移量索引（offset → 物理位置）
# xxx.timeindex 时间戳索引（timestamp → 偏移量）
# 段命名: 以段内第一条消息的 offset 命名（如 00000000000000000000.log）

• .log：消息按 offset 递增顺序追加。消费顺序 = 文件顺序读，顺序 I/O 是 Kafka 吞吐的核心。
• .index：稀疏索引——不是每条消息都记，而是每隔 log.index.interval.bytes（默认 4KB）记一条，定位某 offset 先查索引再二分到文件。稀疏是「空间换查找速度」的折中。
• .timeindex：按时间戳查 offset（时间戳检索，用于按时间回放）。

1.2 段滚动与写放大

段不是无限增长的：达到 log.segment.bytes（默认 1GB）或 log.segment.ms 就滚动成新段。滚动的好处是留存与压缩以段为粒度——删除、合并都不会碰正在写的活跃段。

# 段的生命周期
# 活跃段: 正在被写，只增不减
# 非活跃段: 已关闭写入，等待被留存策略删除或被压缩线程合并

「写放大」的隐藏成本：log.flush.interval.messages 触发刷盘、索引稀疏度不合适导致查找慢。通常默认配置足够，不要为了「更稳」把刷盘调得太频繁——牺牲吞吐换来的稳定性收益往往不值得。

2. 写入路径与刷盘策略

2.1 追加、页缓存与刷盘

Producer 的写入最终落到 broker 的页缓存（page cache），然后异步刷到磁盘：

# 写入路径
# Producer → Leader 副本内存队列 → 页缓存 → （异步）磁盘
# 刷盘触发: 达到 flush.messages / flush.ms / log.retention 清理时顺带刷
# 关键: Kafka 依赖 OS 页缓存做读写加速，热数据读其实命中内存

理解这一点对调优至关重要：Kafka 的吞吐高度依赖 OS 页缓存，而不是磁盘本身。副本同步、消费者读取都能命中页缓存，磁盘只在冷数据或刷盘时被真正触及。

2.2 fsync 与丢数据的边界

log.flush.interval.messages（默认 10000）与 flush.ms 控制刷盘频率。刷得越勤，崩溃时丢得越少，但磁盘写压力越大。工程平衡：接受「页缓存丢失」的窗口（通常几秒），换取吞吐；只有强一致性场景才把 flush.ms 调小。

3. 留存策略：时间、大小与段删除

3.1 三类留存条件

留存（Retention）决定数据保留多久，按「时间」或「大小」约束：

# 留存参数
# log.retention.hours: 按时间（默认 168h = 7 天）
# log.retention.bytes:  按分区大小（默认 -1 不限制）
# 删除粒度: 整个日志段为单位，段内任一消息过期则整段删除

注意两个坑：

• 段粒度删除：留存删除以段为单位，不是逐条删。活跃段不删，所以「超过 retention 但还在活跃段」的消息会晚删——这是预期行为。
• 大小与时间取严格：时间与大小两个约束同时生效，满足其一即清理。想「只按时间删」就把 bytes 设成 -1。

3.2 段合并与文件碎片

删除段不会让文件「空出」，而是把过期段直接删文件。对「部分消息过期」的段，Kafka 用压缩式合并（把段内活消息重写到新段，删旧段）回收空间。log.cleanup.policy 的 delete 模式在段达到条件时触发删除，compact 模式则触发压缩。

4. Compact 主题与日志压缩

4.1 日志压缩的原理

Compact 主题（log.cleanup.policy=compact）保留的是每个 key 的最新值：同一个 key 的旧消息被压缩掉，只留最新一条。适合「状态类」数据——用户画像、配置表、最新状态快照。

# Compact 主题的行为
# 消息按 key 分组，压缩后每 key 只保留最新 value
# 墓碑消息: value = null 的消息，表示删除该 key
# 清除点: 压缩线程推进的 offset，清除点之前的数据已完成压缩
# 压缩不删除活跃段，且压缩是异步的（有延迟窗口）

4.2 压缩线程与清除点推进

压缩由LogCleaner 线程周期性执行：扫描非活跃段，构建 key → offset 映射，删除被覆盖的旧消息，写回新段。

# 压缩的关键参数
# log.cleaner.min.cleanable.ratio: 脏数据占比阈值（默认 0.5），达到才压缩
# log.cleaner.threads: 压缩线程数（默认 1）
# log.cleaner.dedupe.buffer.size: 去重缓冲，key 量大的主题需调大

工程要点：

• key 是压缩的前提：生产端必须带 key，否则无法分组，压缩失效。
• 内存与时间：压缩需要把 key 装进去重缓冲，key 量巨大的主题要调大 dedupe.buffer.size，否则压缩慢。
• 消费者读取：读 Compact 主题时，未压缩的旧数据也能读到（读取不依赖压缩完成）。压缩只影响存储，不影响读取语义。

4.3 Compact 与 Delete 混用

一个主题可以同时配置 compact,delete：既按时间/大小删除，又做压缩。适合「既有状态语义又想限时保留」的场景（如按 key 保留最新 + 超过 30 天整体清理）。

5. 分层存储（Tiered Storage）

5.1 热数据在本地、冷数据上对象存储

分层存储（Kafka 3.6+ 原生支持）把旧日志段上传到对象存储（S3/GCS），本地只留热数据：

# Tiered Storage 的段流动
# 活跃段: 本地（热）
# 近热段: 本地 + 异步上传对象存储（远热）
# 冷段:   本地删除，读取时从对象存储回拉
# 读取优先级: 本地优先，miss 才回源

5.2 分层存储的收益与成本

收益：把「容量上限」从磁盘变成对象存储，保留更长时间的数据而不用扩本地盘；消费冷数据虽要回源，但对「低频回溯、离线分析」场景完全可接受。成本：对象存储的读取延迟、回源流量、以及元数据管理复杂度。选型建议：数据量大、回溯频率低的场景（审计、离线数仓）才上分层存储；高频实时消费的主题放本地更稳。

6. 存储调优与磁盘故障排查

6.1 磁盘选择与容量规划

• 磁盘：SSD 显著优于 HDD（顺序写差异不大，但随机读与索引查找 SSD 快很多）。用 RAID 或云盘做冗余，避免单盘故障丢数据。
• 容量：分区数 × log.retention.bytes 粗算峰值；留 20~30% 余量给压缩与段滚动。Compact 主题按 key 规模估算。
• 副本放大：副本数 × 数据量 = 实际磁盘占用，三副本就是 3 倍。

# 容量粗算
# 单分区日写入 10GB × 保留 7 天 × 分区 20 × 副本 3
# = 10 × 7 × 20 × 3 = 4200 GB  ≈ 4.2TB
# 建议: 容量规划按峰值 × 1.3 预留

6.2 常见存储问题

• 磁盘写满：log.cleanup.policy=delete 但 retention 太宽松导致磁盘打满 → 收紧 retention 或扩盘。
• 压缩慢导致磁盘膨胀：key 量巨大但 dedupe.buffer.size 太小，压缩线程卡住 → 调大 buffer、加线程。
• Index 损坏：异常断电可能导致 .index 与 .log 不一致，broker 会自动重建或报错——监控 Log index corrupt 日志。
• 页缓存压力：冷数据大量回读时页缓存被挤出，读放大——监控缓存命中率，必要时扩容内存。

7. 常见坑清单

• 活跃段不删除：期望「数据一到时间就消失」的人会被活跃段「晚删」搞懵——接受它是设计。
• Compact 主题生产端没带 key：压缩永远无法去重，空间只增不减。
• 墓碑消息没有 value 会被误处理：消费端要显式处理 null value（代表删除）。
• 调小 flush.ms 想防丢数据：换来的吞吐损失可能远超收益，先评估真实丢失容忍度。

8. 总结

Kafka 存储内核的工程认知是「日志段 + 页缓存 + 异步刷盘 + 策略清理」四件套：段结构决定读写模型，页缓存决定吞吐，刷盘决定持久性边界，留存/压缩策略决定容量。调优的顺序是：先按业务定留存与压缩策略（这是容量大头），再根据磁盘与页缓存状态调刷盘与索引参数，最后在需要长回溯时才引入分层存储。理解存储层，才算真正理解 Kafka 的「快」与「省」从哪来。