Kafka日志清理策略配置指南
一 核心概念与策略选择
- 清理对象是以分区为单位的日志分段（LogSegment），Kafka按“段”评估并删除，而不是逐条消息删除。这样便于快速回收磁盘空间并保持索引一致性。
- 两种基础策略：
- 删除策略 delete：按时间或大小清理过期分段，适合常规业务消息。
- 压缩策略 compact：按键保留每个 key 的最新版本，适合状态/配置类主题（如用户资料）。
- 同一 Broker 可为不同主题设置不同策略；也可在同一主题上组合策略为 delete,compact（删除+压缩）。压缩需启用清理线程（默认开启）。
二 Broker 端全局配置 server.properties
- 建议将以下关键参数加入 config/server.properties，并按需调整：
| 参数 |
含义 |
默认值 |
建议 |
| log.cleanup.policy |
清理策略：delete 或 compact，或两者组合 |
delete |
常规主题用 delete；状态类用 compact；也可 delete,compact |
| log.retention.ms |
消息保留时间（毫秒，优先级最高） |
无（若未显式设置，通常由 hours 生效） |
如 604800000（7 天） |
| log.retention.minutes |
保留时间（分钟） |
无 |
与 ms/minutes/hours 三选一，优先级 ms > minutes > hours |
| log.retention.hours |
保留时间（小时） |
168（7 天） |
与 ms/minutes 互斥使用 |
| log.retention.bytes |
每个分区日志总大小上限 |
-1（不限制） |
如 1073741824（1GB） |
| log.retention.check.interval.ms |
检查分段是否可删除的间隔 |
300000（5 分钟） |
根据磁盘与负载适当缩短或拉长 |
| log.segment.bytes |
单个分段最大字节数 |
1073741824（1GB） |
与保留粒度配合，便于精细过期 |
| log.roll.hours / log.roll.ms |
分段滚动周期（时间） |
168 小时 |
低流量时可缩短，更快形成可删除的非活动段 |
| log.segment.delete.delay.ms |
标记为删除后到真正删除的延迟 |
60000（1 分钟） |
一般无需修改 |
| log.cleaner.enable |
是否启用日志清理线程 |
true |
使用 compact 时必须为 true |
- 示例（保留 7 天，或每分区超过 1GB 触发清理）：
log.cleanup.policy=delete
log.retention.hours=168
log.retention.bytes=1073741824
log.retention.check.interval.ms=300000
log.segment.bytes=1073741824
log.roll.hours=24
log.cleaner.enable=true
三 按 Topic 动态覆盖配置
- 查看某 Topic 当前配置：
bin/kafka-configs.sh --zookeeper <ZK_IP:2181> --describe --entity-type topics --entity-name <topic_name>
- 修改 Topic 保留时间为 10 秒（用于演练或临时缩短保留）：
bin/kafka-configs.sh --zookeeper <ZK_IP:2181> --alter --entity-type topics --entity-name <topic_name> --add-config retention.ms=10000
- 删除 Topic 级别覆盖，恢复 Broker 全局默认：
bin/kafka-configs.sh --zookeeper <ZK_IP:2181> --alter --entity-type topics --entity-name <topic_name> --delete-config retention.ms
- 如需对压缩主题设置策略：
bin/kafka-configs.sh --alter --entity-type topics --entity-name <topic_name> --add-config cleanup.policy=compact（确保 Broker 端启用清理线程）
四 压缩策略与关键注意点
- 压缩适用场景：需要按键保留最新值的主题（如用户画像、配置中心）。压缩后每个 key 仅保留最新版本，且 offset 可能不连续。
- 启用压缩：设置 topic 的 cleanup.policy=compact，并确保 log.cleaner.enable=true。
- 压缩相关调优参数（可选）：
- log.cleaner.dedupe.buffer.size：清理线程去重缓冲总大小（默认 128MB）
- log.cleaner.threads：清理线程数（默认 1）
- log.cleaner.io.buffer.load.factor：去重缓冲负载因子（默认 0.9）
- compression.type：压缩算法（gzip/snappy/lz4/zstd/producer，默认 producer）
- log.cleaner.min.compaction.lag.ms：消息最小保留时间，避免过早压缩（默认 1000ms）
- 删除与压缩可组合：cleanup.policy=delete,compact。通常 delete 负责回收过期段，compact 负责保留每个 key 的最新值
五 运维与验证要点
- 大小阈值删除的触发条件：仅当“超出阈值的部分 ≥ 一个日志段大小（log.segment.bytes）”时，才会删除最旧的分段，避免频繁小文件抖动。
- 实际保留可能大于设定值的原因：清理以“非活动分段”为单位；若分段因滚动延迟未关闭（例如低流量且时间滚动周期较长），即使消息超时仍会随活动段保留一段时间。
- 区分两类日志：
- 消息日志（Topic 数据）：由 log.dirs 指定目录，受上述策略管理。
- Broker 运行日志（server.log 等）：由 log4j/log4j2 或系统 logrotate 管理，需单独配置轮转与归档。
- 快速验证：
- 调整 Topic 保留时间后，观察磁盘使用与分段文件变化；
- 使用 kafka-topics.sh 查看分区与副本状态，确认无异常；
- 对压缩主题，生产含相同 key 的多版本消息，消费验证仅保留最新值。