Log Compaction 与磁盘 IO 极致优化

【今日主题】：Log Compaction 与磁盘 IO 极致优化

【业务场景痛点】

场景：大型社交平台的用户画像系统。

• 数据特征：Topic 中存储着数亿用户的属性变更记录（例如：User:1001 -> {"city": "Beijing"}，User:1001 -> {"city": "Shanghai", "vip": true}）。消息总量已达 PB 级，并且每天新增 10TB。
• 业务需求：下游的推荐系统需要每个用户的最新完整画像来实时更新推荐模型。它不关心 User:1001 在过去一周内变更了 100 次，只关心最后一次变更后的完整状态。
• 痛点：
  1. 磁盘成本：存储所有历史变更导致磁盘飞速消耗，扩容成本高昂。
  2. 消费效率：下游 Consumer 如果从头消费，需要扫描海量无效的历史消息，延迟极高。
  3. 性能瓶颈：机械硬盘（HDD）的随机 IO 导致读取性能低下。

【架构与原理解析】

1. Log Compaction 流程（画图式讲解）

Log Compaction 不是删除消息，而是“去重保留最新状态”。

• 数据写入阶段：

  • Producer 发送消息到 Compacted Topic，每条消息包含一个 Key（如 User:1001）和 Value（用户属性）。
  • Broker 将这些消息按顺序写入 .log 文件，并记录索引到 .index 文件。

• Compaction 触发阶段（后台线程）：

  • 触发时机：当 Topic 的 log 文件达到 min.cleanable.dirty.ratio 阈值（默认 50%）或手动触发。
  • 核心流程：
    1. 构建哈希表：线程扫描最近的 log 段，为每个 Key 构建一个内存哈希表，记录该 Key 的最新 Offset。
    2. 清理旧数据：对于每个 Key，只保留最新 Offset 的消息，将之前的旧消息标记为“可删除”。
    3. 重写文件：将需要保留的消息（包括最新消息和其他未变更的 Key 的消息）写入新的 log 段文件。旧的 log 段文件被删除。
  • 结果：Topic 的磁盘占用从 PB 级下降到 GB 级（假设用户数远小于总消息数）。Consumer 拉取时，只需读取新生成的紧凑文件，IO 开销极小。

2. 零拷贝 (Zero-Copy) 原理

Kafka 的高吞吐不仅依赖于磁盘顺序写，还依赖于 Zero-Copy 减少 CPU 和内存拷贝。

• 传统 IO 流程：

  • 磁盘 -> OS Kernel Buffer -> User Buffer (CPU 拷贝) -> Socket Buffer -> 网卡
  • 涉及 4 次上下文切换和 4 次数据拷贝。

• Kafka Zero-Copy 流程：

  • 磁盘 -> OS Kernel Buffer -> 直接发送到网卡 (通过 sendfile 系统调用)
  • 绕过 User Buffer，CPU 几乎不参与数据搬运。
  • 结果：极大降低 CPU 使用率，提升网络吞吐，尤其是在 Consumer 拉取大量数据时。

3. 为什么默认配置在生产环境是“不可用”的？

• 默认配置：Topic 默认是 cleanup.policy=delete（基于时间或大小删除）。
• 风险：对于状态类数据，delete 策略会丢失所有历史状态，导致下游无法重建当前状态。且随着数据增长，磁盘会无限膨胀，最终导致 Broker 宕机。
• 结论：对于需要保留“最新状态”的场景，默认的删除策略不仅浪费资源，还破坏了业务逻辑。必须使用 cleanup.policy=compact。

【生产级配置与代码】

1. 核心配置 (Topic 级别配置，通过 kafka-configs.sh 设置)

# 创建或修改 Topic 时指定 Compaction 策略
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name user-profiles --alter --add-config cleanup.policy=compact,min.cleanable.dirty.ratio=0.1,segment.ms=60000

• cleanup.policy=compact：启用日志压缩。
• min.cleanable.dirty.ratio=0.1：当脏数据比例达到 10% 时就触发压缩（默认 50%，生产环境建议更激进以减少磁盘占用）。
• segment.ms=60000：每分钟滚动一个 log 段，让压缩线程更快处理小文件（根据磁盘性能调整）。
• delete.retention.ms=86400000：标记为删除的消息保留 24 小时（给 Consumer 留出拉取时间）。
• min.compaction.lag.ms=0：消息写入后可立即被压缩（默认为 0）。

2. 代码演示 (Java)

Producer：只需确保消息有 Key，Value 是完整状态。

// Producer 代码与普通 Topic 无异，关键是 Key 的设计
ProducerRecord<String, String> record = new ProducerRecord<>("user-profiles", "user:1001", "{\"city\":\"Shanghai\",\"vip\":true}");
producer.send(record);

Consumer：从 Compacted Topic 消费时，可能收到 null Value 的消息（代表该 Key 被删除）。

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Collections.singletonList("user-profiles"));

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        if (record.value() == null) {
            // 场景：Key 被删除（例如用户注销）
            System.out.printf("Key %s 被删除%n", record.key());
            // 业务逻辑：从本地缓存或数据库中删除该用户状态
            localCache.remove(record.key());
        } else {
            // 场景：Key 的最新状态
            System.out.printf("更新状态: Key=%s, Value=%s%n", record.key(), record.value());
            // 业务逻辑：更新本地缓存或数据库
            localCache.put(record.key(), record.value());
        }
    }
}

【老司机的血泪教训】

1. 误区一：对 Compacted Topic 的 Consumer 做幂等性处理

   • 事故：一个 Compacted Topic 的下游 Consumer，因为本地状态存储没有处理 null 消息，导致用户被删除后，本地缓存依然存在，推荐系统持续给已注销用户推送广告。
   • 教训：消费 Compacted Topic 时，必须处理 null Value。这是该机制的核心特性，代表“状态删除”。忘记处理会导致数据不一致。

2. 误区二：在 Compacted Topic 上使用 seekToBeginning()

   • 事故：开发在 Compacted Topic 上调用 consumer.seekToBeginning()，试图全量重放数据。结果发现无法获取历史所有状态，因为大部分旧消息已被压缩掉。
   • 教训：Log Compaction 会丢弃旧消息，因此不能用于需要“重放所有历史”的场景。如果业务需要全量历史，必须使用 cleanup.policy=delete 并设置超长保留期，或额外存储到数据湖。

【今日运维命令/作业】

作业：创建一个 Compacted Topic，写入数据，手动触发压缩，并观察磁盘占用变化。

命令：手动触发 Log Compaction（通常自动触发，但可强制）并查看 Topic 详细信息。

# 1. 创建 Compacted Topic
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic test-compaction --partitions 1 --replication-factor 1 --config cleanup.policy=compact

# 2. 写入多条相同 Key 的数据（通过命令行）
kafka-console-producer.sh --broker-list localhost:9092 --topic test-compaction
> key1 value1
> key1 value2
> key1 value3

# 3. 查看 Topic 详细信息，关注 "Config" 中的 cleanup.policy 和磁盘文件
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic test-compaction

# 4. 强制触发日志段滚动和压缩（通过调整配置并恢复）
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name test-compaction --alter --add-config segment.ms=1000
sleep 2
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name test-compaction --alter --add-config segment.ms=604800000

# 5. 使用 Console Consumer 消费，观察输出（只会看到 key1 value localhost:9092 --topic test-compaction --from-beginning

输出解读：在 Consumer 的输出中，你只会看到 key1 value3，证明旧消息已被压缩。通过 du -sh <log_dir>/test-compaction-* 可以观察到磁盘占用远小于写入的原始数据量。

---

总结：Log Compaction 是 Kafka 作为“状态存储”的核心能力，而 Zero-Copy 是其高性能的基石。理解并正确使用它们，能让你在处理海量状态数据时游刃有余，同时显著降低硬件3）
kafka-console-consumer.sh --bootstrap-server成本。明天我们将进入更复杂的流处理与 Kafka 的整合领域。