Kafka Topic压缩功能失效，如何排查调试？

一、生产者端（Spring Kafka 2.7）配置检查 #

• 确认所有消息都指定了非空Key：Compact策略只针对同Key的消息保留最新版本，如果消息无Key，Broker会将其视为独立消息，不会触发压缩。检查spring.kafka.producer.key-serializer是否正确配置，同时确认业务代码发送消息时没有遗漏Key。
• 核对acks配置：确保acks设置为all或1，只有Broker确认持久化的消息才会纳入Compact范围。如果设为0，可能存在消息未落地导致Compact无法识别的情况。
• 检查生产者压缩配置：虽然不直接影响Compact，但开启生产者压缩（如compression-type: lz4）能降低Broker存储压力，帮助Compact任务更高效运行，建议配置。

二、Broker端Topic配置验证 #

结合你的Topic配置截图，重点核对以下生效配置（推荐用命令kafka-topics.sh --describe --topic <你的Topic名> --bootstrap-server <Broker地址>实际确认）：

• 确认cleanup.policy确实是compact,delete：避免UI显示与实际生效配置不一致，全局配置可能会覆盖Topic级配置。
• 检查delete.retention.ms是否为7天（604800000ms）：该参数控制Compact后旧消息的保留时长，若误设为极大值会导致旧消息长期留存。
• 核对min.cleanable.dirty.ratio：默认0.5，这个阈值决定脏数据（可被Compact的消息）占比达到多少时触发Compact。240分区的大Topic，若该值过高（如接近1）会导致Compact极少触发，建议保持默认或调低至0.3。
• 检查segment.ms和segment.bytes：过大的日志分段会增加Compact任务的处理压力，建议将segment.ms设为1天（86400000ms）、segment.bytes设为1GB，让分段更细碎，Compact更易触发。
• 确认min.compaction.lag.ms为默认0：若该值大于7天，会强制消息保留超过7天才能被Compact，直接导致旧消息无法被清理。

三、Broker日志高效排查技巧 #

不用遍历全量日志，重点过滤以下内容：

• 搜索Compaction、log cleaner关键字，定位包含目标Topic名的日志：
  • 找Starting log cleanup for partition <Topic名>-<分区号>：确认Broker是否触发了对应分区的Compact任务
  • 找Finished compaction for partition <Topic名>-<分区号>：查看Compact是否成功完成，以及处理的消息量、耗时
  • 找Skipping compaction for partition <Topic名>-<分区号> because...：这里会明确说明跳过Compact的原因，比如脏数据比例未达标、无同Key更新消息等
• 过滤ERROR+compact关键字：排查是否有磁盘IO异常、文件损坏、权限问题等导致Compact失败的情况
• 按时间段过滤日志：重点查看最近7天内的日志，对应旧消息本该被标记删除的时段，定位异常提示

四、其他排查方向 #

• 检查Broker磁盘使用率：若磁盘空间占比超过85%，Kafka会暂停Compact任务保护磁盘，用df -h确认磁盘状态
• 验证分区最早消息：用kafka-run-class.sh kafka.tools.GetOffsetShell --topic <你的Topic名> --time -2 --bootstrap-server <Broker地址>获取各分区最早偏移量，再用kafka-console-consumer.sh --topic <你的Topic名> --offset <最早偏移量> --bootstrap-server <Broker地址> --max-messages 10确认最早消息是否确实为一年前，排除消费者偏移量误判的可能
• 核对Broker版本：旧版本Kafka可能存在compact,delete策略的兼容bug，建议升级到2.8及以上稳定版本

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