Kafka日志清理是时间、空间与清理方式协同的动态机制：保留策略决定可清理数据，Log Cleaner周期执行物理操作；时间策略以段内最后消息时间戳为判断依据，推荐统一使用log.retention.ms；大小策略按分区独立生效，与时间策略为“或”关系；清理策略支持delete、compact或混合模式，compact需启用log.cleaner.enable且仅对有key的消息有效；关键参数如log.retention.check.interval.ms和log.cleaner.min.cleanable.ratio影响清理节奏与效率。
Kafka 的日志清理与保留策略不是“设完就生效”的静态开关，而是由时间、空间、清理方式三者协同作用的动态机制。核心在于理解“触发条件”和“执行动作”的分离：保留策略决定哪些数据可被清理，而清理器（Log Cleaner）按固定周期扫描并执行物理删除或压缩。
基于时间的保留：毫秒级精度优先
时间维度控制最常用，但配置有明确优先级：log.retention.ms > log.retention.minutes > log.retention.hours。默认只启用 log.retention.hours=168（7天），若需更精确控制（比如保留 3 天 6 小时 30 分钟），直接设 log.retention.ms=279000000 即可，无需换算小时或分钟。注意：Kafka 判断段是否过期，依据的是该段内最后一条消息的时间戳（largestTimeStamp），不是文件修改时间。
- 生产环境建议统一用 log.retention.ms，避免单位混用导致预期偏差
- 单个段不会被“切片删除”，只有整个段满足时间条件才进入待删队列
- 实际删除延迟受 log.segment.delete.delay.ms 影响（默认 1 分钟），即标记后至少等 1 分钟才真正落盘删除
基于大小的保留：按分区独立生效
log.retention.bytes 是针对每个 Partition 设置的上限，不是 Topic 或 Broker 总量。例如一个 12 分区的 Topic，设为 1GB，则理论最大占用约 12GB（未考虑副本）。该值与 log.segment.bytes（默认 1GB）配合使用：当某分区所有段总大小超限，最旧的段会被整段移除。
- 设为 -1 表示不限制大小，仅靠时间策略控制——线上慎用，易引发磁盘告警
- 大小策略和时间策略是“或”关系：任一满足即触发清理，不需两者同时达标
- 监控时应关注每个 Partition 的 size 和 age，而非整体 Topic 指标，避免误判
清理策略选择：delete、compact 或混合
log.cleanup.policy 决定清理行为本质：delete 是按段丢弃过期数据；compact 是按 key 保留最新值，适合状态类场景（如用户资料变更）；delete,compact 可同时启用，先压缩再按时间/大小裁剪冗余段。
- 启用 compact 必须打开 log.cleaner.enable=true（默认 false），否则策略不生效
- compact 不影响 retention 时间/大小阈值，它只在满足保留条件的前提下做“去重”，不改变生命周期底线
- 对非 key 类消息（key=null）的 topic 启用 compact 无效，且可能增加 cleaner 负担
关键辅助参数：让清理更可控
清理不是瞬间完成的后台任务，它的节奏和粒度由几个关键参数调节：
- log.retention.check.interval.ms：检查频率，默认 300000ms（5 分钟）。调小可加快响应，但增加 CPU 开销；生产建议保持默认或略调至 60000ms（1 分钟）
- log.roll.ms / log.roll.hours：控制新段生成时机，间接影响清理粒度。滚动越频繁，段越小，清理时释放空间越细粒度
- log.cleaner.min.cleanable.ratio：仅对 compact 生效，表示“多少比例脏数据才值得启动压缩”，默认 0.5。低频更新 topic 可适当调低（如 0.1），避免空转
