低吞吐量Kafka Topic无新写入场景下触发日志压缩的配置问题

Kafka默认不会主动关闭仍处于写入状态的活跃日志段（active segment），如果没有新数据写入，活跃段会一直处于未关闭状态，无法被日志清理线程纳入压缩范围，哪怕你配置的segment.ms和max.compaction.lag.ms已超时，压缩逻辑也不会触发。

你当前的Topic端配置已经覆盖了大部分必要参数，但存在两处核心缺失：

• 未配置Broker全局级别的最大压缩滞后参数：Kafka Topic级别的max.compaction.lag.ms不能超过全局参数log.cleaner.max.compaction.lag.ms的取值，该参数默认值为Long.MAX_VALUE，相当于完全禁用了KIP-354的超时强制压缩逻辑，你配置的1小时Topic级限制不会生效。
• 未确认日志清理线程的主动段滚动检查逻辑：低吞吐量场景下需要依赖后台线程定期检查活跃段的超时状态，无需新写入即可滚动段。

1. 调整Broker全局配置（所有部署了日志清理线程的Broker都需要修改，重启后生效） #

• 新增/修改log.cleaner.max.compaction.lag.ms = 3600000，和你Topic端配置的1小时最大压缩滞后对齐，确保Topic级配置可以生效。
• 确认log.cleaner.enable = true，该参数默认开启，若你所在集群曾手动关闭过日志清理功能需要重新打开。
• 可选配置log.roll.jitter.ms = 360000，给段滚动时间增加10%以内的随机抖动，避免大量分区同时滚动段导致集群压力突增。

2. Topic端配置优化（无需重启集群，动态生效） #

你现有配置的cleanup.policy=compact、min.cleanable.dirty.ratio=0.01、min.compaction.lag.ms=3600000、max.compaction.lag.ms=3600000、segment.ms=3600000、segment.bytes=1048576均符合要求，无需调整，Kafka 2.6版本中只要脏数据的最久存活时间超过max.compaction.lag.ms，会忽略min.cleanable.dirty.ratio的限制直接触发压缩。

3. 无新写入场景的压缩触发逻辑 #

Kafka 2.3及以上版本已经支持后台线程定期检查活跃段的最后写入时间，默认检查间隔为5分钟（由Broker参数log.roll.check.interval.ms控制，默认300000无需修改），只要活跃段存活时间超过segment.ms，就算没有新数据写入，也会主动滚动关闭旧活跃段，纳入压缩队列，配合上面的max.compaction.lag.ms配置即可实现1小时内完成压缩的要求。

你可以使用测试环境验证效果：写入测试数据后停止写入，等待1.5小时左右，检查对应分区的日志目录，会看到旧的活跃段被关闭、生成新的空活跃段，旧段被压缩完成后仅保留每个Key的最新版本。

内容的提问来源于stack exchange，提问作者Lars KJ