Java编程式清理Kafka Topic时修改留存时间未删除消息问题

• 配置修改为异步操作，未等待生效就休眠：incrementalAlterConfigs是AdminClient提供的异步API，代码中没有等待修改请求执行完成就直接进入休眠，很可能休眠结束后配置还未同步到所有Broker，甚至配置修改请求根本没完成发送，实际生效时间远短于预期。
• 日志清理线程触发间隔远长于等待时间：Kafka的过期消息清理由后台定时线程执行，默认检查间隔由Broker端配置log.retention.check.interval.ms控制，默认值为30000毫秒（30秒）。你仅等待5秒就将配置还原，清理线程根本来不及触发过期检查，自然不会删除消息。
• 无配置修改结果校验：代码没有处理修改请求的返回值，也没有校验最终配置是否生效，可能因为权限不足、Topic不存在等原因配置修改直接失败，全程无感知。
• Kafka清理粒度限制：Kafka的消息删除以日志段（Segment）为单位，只有整个非活跃Segment内的所有消息都超过保留时间才会被删除，正在写入的活跃Segment就算包含过期消息也不会被清理。如果待删除消息都在活跃Segment内，修改保留时间不会生效。
• 清理策略不匹配：如果目标Topic的清理策略配置为compact（压缩）而非delete，修改保留时间不会触发消息删除。

• 同步等待配置修改完成：调用incrementalAlterConfigs返回结果的all().get()方法，等待修改请求执行完成，再开始计时。
• 延长等待时间：至少等待30秒以上，保证日志清理线程至少触发一次过期检查，确认消息清理完成后再还原保留时间配置。
• 校验配置生效状态：调用describeConfigs接口轮询查询目标Topic的retention.ms配置，确认配置确实修改成功后再进入等待。
• 更稳妥的方案：Kafka 2.4及以上版本直接使用deleteRecords接口指定偏移量删除消息，比修改保留时间的方式更可控、效率更高。
• 前置校验：执行操作前先查询目标Topic的清理策略，确认是delete模式后再执行后续操作。

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