Kafka消息设置retention.ms=604800000消失及retention.ms=-1相关疑问

问题1：为何设置retention.ms=604800000时消息会消失？ #

设置retention.ms=604800000意味着消息最多保留7天（604800000毫秒=7×24×3600×1000），消息会在以下场景被删除，哪怕还未被消费者读取：

• 时间触发自动清理：消息写入Kafka的日志段后，只要该日志段的最后修改时间距当前时间超过7天，结合cleanup.policy=delete的配置，不管消息是否被消费，都会被清理。如果消费者因延迟启动、故障等原因，超过7天才开始读取，这部分旧消息已经被删除。
• 磁盘容量阈值触发：除了retention.ms，Kafka还受retention.bytes配置限制（默认值为-1即无限制，但如果集群或主题单独配置了该值）。当主题总消息大小达到retention.bytes阈值时，Kafka会优先删除最旧的日志段，哪怕这些消息还没到7天的保留期。
• 日志段滚动引发的清理：Kafka日志按段存储，当日志段达到log.segment.bytes（默认1GB）或log.roll.ms（默认7天）阈值时会滚动生成新段。旧段完成滚动后，会立即检查是否满足retention.ms的删除条件，即使消费者还未读取该段内的消息，只要时间达标就会被删除。
• 配置生效异常：如果主题实际运行的retention.ms配置和你提供的JSON不一致（比如配置修改后未生效，或全局配置覆盖了主题配置），也可能导致消息提前被清理。可通过kafka-topics.sh --describe --topic test --bootstrap-server <broker地址>命令确认实际生效的配置。

问题2：使用retention.ms=-1（永久保留）是否为合理方案？设置为-1后消息何时会被删除？ #

合理性分析 #

是否合理完全取决于业务场景：

• 合理场景：如果业务需要长期保存消息用于审计、数据回溯、故障排查，或者消息量小、磁盘资源充足，设置retention.ms=-1是可行的。
• 不合理场景：如果消息量大且持续增长，永久保留会导致磁盘空间被持续占用，最终引发磁盘耗尽问题，影响Kafka集群稳定性。这种情况下建议根据业务需求设置合理的保留时间，或结合retention.bytes限制磁盘占用。

设置为-1后消息的删除时机 #

retention.ms=-1只是取消了时间维度的自动删除，但消息仍会在以下情况被删除：

• 磁盘容量触发：当主题总消息大小达到retention.bytes配置的阈值时，Kafka会删除最旧的日志段以释放磁盘空间。
• 手动操作删除：通过Kafka工具（如kafka-delete-records.sh）手动删除指定offset之前的消息，或直接删除主题。
• 清理策略变更：如果将cleanup.policy改为compact（日志压缩），Kafka会保留每个key的最新版本消息，旧版本会被压缩清理；若改为delete,compact则同时应用两种清理策略。
• 集群或主题销毁：当主题被删除，或Kafka集群节点磁盘故障导致数据丢失时，消息也会消失。

内容的提问来源于stack exchange，提问作者sai jyothsna pentyala