Kafka Retention 怎么配置？消息到期就一定删除吗？
面试怎么回答
我会先确认 cleanup.policy 是 delete、compact 还是两者同时。delete 策略下，retention.ms 和 retention.bytes 只是保留边界；Kafka 按 Segment 清理，还受段滚动、后台检查和删除延迟影响，所以消息到期不会立刻消失。配置时要结合回放窗口、写入量、副本数和磁盘容量，并区分普通 Retention 与 Tombstone 的 delete.retention.ms。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
业务要求 Kafka 消息保留 7 天，于是把 retention.ms 配成 7 天。
第 8 天检查磁盘，却发现部分旧消息还在。很多人第一反应是配置没生效。
问题其实在于：Kafka Retention 怎么配置？消息到期后真的会立刻删除吗？
Kafka 的删除以日志段为单位，还受到 cleanup.policy、段滚动和后台检查周期影响。retention.ms 是保留边界，不是精确到秒的删除定时器。
先看 cleanup.policy
delete
按照时间或空间条件删除旧日志段，主要受：
retention.msretention.bytessegment.ms/segment.bytes
影响。
compact
按 Key 保留较新的值，用于状态类 Topic，不等同于按时间清空全部旧消息。
delete,compact
同时启用两类策略：既做 Key 压缩，也受时间或空间保留约束。
为什么到期后不会立刻删除？
Kafka 日志由多个 Segment 组成。活跃 Segment 还在持续写入，通常要先滚动成非活跃段，才能作为整体进入删除判断。
因此实际删除时间还会受到：
- Segment 何时滚动
- 后台多久检查一次
- 文件删除延迟
- Broker 当前 IO 与清理负载
影响。
如果 segment.ms 很大，一个 Segment 跨越很长时间，段内最早的消息即使超过 7 天，也可能要等整个 Segment 满足删除条件。
配置时看四件事
业务回放窗口
保留多久要由故障恢复、离线补算和审计需求决定，不要只按磁盘大小拍脑袋。
磁盘容量
根据写入速率、压缩率、副本数和保留时长估算容量，并保留安全水位。
Segment 粒度
Segment 太大，删除粒度粗；太小，则文件数量和管理开销增加。
压缩 Topic 的墓碑消息
Compaction 场景还要理解 Tombstone 与 delete.retention.ms，它和普通日志的 retention.ms 不是同一个概念。
一个典型场景
某 Topic 每天写入量不大，retention.ms=7d，但 segment.ms 设置得很长，活跃 Segment 多天没有滚动。
第 8 天看到最早消息仍在，并不是保留策略失效，而是它所在的 Segment 还未进入可删除状态。
调整 Segment 滚动粒度并观察日志段、清理线程和磁盘水位，才能判断 Retention 是否符合预期。
Retention 管的是日志生命周期，不是单条消息的闹钟。