Kafka 2.7.0 compact策略Topic日志未压缩原因及强制压缩方法咨询

核心原因 #

• 最常见的测试场景问题：Kafka 日志压缩仅会处理已关闭的非活跃Segment，正在写入的活跃Segment永远不会被纳入压缩范围。你写入的5条测试数据远小于默认1GB的Segment大小阈值，修改的segment.ms=10000仅对修改后新生成的Segment生效，已存在的活跃Segment不会自动滚动关闭，因此无法触发压缩。
• 配置未实际生效：你使用--zookeeper参数修改Topic配置，Kafka 2.7版本已推荐使用--bootstrap-server操作Topic配置，通过Zookeeper修改的配置可能存在Controller同步延迟，导致配置未被 broker 实际加载。
• Broker压缩功能未开启：若集群broker端配置log.cleaner.enable=false，全局压缩线程不会启动，所有配置compact策略的Topic都不会执行压缩。

强制触发压缩的操作步骤 #

1. 先确认Topic配置已正确生效，执行如下命令：

./kafka-topics.sh --describe --bootstrap-server kafka.core-kafka.svc.cluster.local:9092 --topic _test_quick_compaction_2021_12_02

检查输出中的cleanup.policy是否为compact，你设置的max.compaction.lag.ms、min.cleanable.dirty.ratio等参数是否正确显示。
2. 强制滚动当前活跃Segment，临时将该Topic的Segment大小阈值调至远小于当前已写入数据的大小：

./kafka-topics.sh --alter --bootstrap-server kafka.core-kafka.svc.cluster.local:9092 --topic _test_quick_compaction_2021_12_02 --config segment.bytes=1024

修改后等待10秒左右，当前活跃Segment会因超过大小阈值自动滚动关闭，成为可被压缩的非活跃Segment。
3. 等待压缩执行，你配置的max.compaction.lag.ms=10000和min.cleanable.dirty.ratio=0.0会让关闭的非活跃Segment立刻进入压缩队列，等待30秒确保压缩完成且旧的未压缩Segment被清理（你设置的delete.retention.ms=10000）。
4. 再次查询Topic消息即可看到每个Key仅保留最新值的压缩结果。

注意：测试完成后请将segment.bytes改回业务正常配置，过小的Segment阈值会产生大量小文件，严重影响集群性能。

内容的提问来源于stack exchange，提问作者Tobias Hermann