Kafka通过日志分段机制和删除/压缩策略管理历史数据：删除策略按时间或大小整段清理，压缩策略保留每key最新值，二者可共存，且均异步执行不影响读写。
Kafka 对历史数据的清理和磁盘空间回收，核心依赖日志分段（Log Segment）机制和两种可配置的清理策略：删除（delete） 和 压缩（compact）。它不是逐条删消息，而是按“段”操作，既高效又不影响读写性能。
基于时间或大小的自动删除
这是最常用、默认启用的方式，适用于事件日志、监控指标等无需长期保留的场景。
-
按时间清理：通过
log.retention.ms（推荐）、log.retention.hours或log.retention.minutes设置保留时长。例如设为86400000（24 小时），超过该时间的整个日志段会被移除。 -
按大小清理：用
log.retention.bytes限制每个分区最大磁盘用量（如1073741824表示 1GB）。达到上限后，从最旧段开始删除，直到满足容量要求。 -
触发检查频率：后台线程每
log.retention.check.interval.ms（默认 300000ms，即 5 分钟）扫描一次，判断是否需清理。 -
段文件管理：日志被切分为固定大小的段（默认
log.segment.bytes=1073741824，即 1GB），新消息写满当前段就滚动到下一个，便于整段回收。
基于 Key 的精准压缩
适合需要长期保留“最新状态”的场景，比如用户资料、设备配置、订单状态等。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 只保留每个 key 的最新 value：相同 key 的多条消息中，仅最新一条被保留；无 key（null key）的消息会被丢弃。
-
必须显式启用：设置
log.cleanup.policy=compact，且确保log.cleaner.enable=true（broker 级别，默认开启）。 -
压缩不是实时的：后台 cleaner 线程定期扫描，按
log.cleaner.min.cleanable.ratio（默认 0.5）决定何时启动——即当“脏数据”（未压缩部分）占比超一半时才触发。 -
可与删除共存：设为
delete,compact，表示先压缩保留最新值，再对压缩后仍超时/超限的部分执行删除。
主题级覆盖配置更灵活
全局配置（server.properties）设默认策略，但生产中常按主题定制：
- 创建主题时指定：
bin/kafka-topics.sh --create --topic user-profile --config cleanup.policy=compact --config retention.ms=2592000000（保留 30 天，同时启用压缩） - 修改已有主题：
bin/kafka-configs.sh --alter --topic __consumer_offsets --add-config cleanup.policy=delete（解决 offset 主题占满磁盘的问题） - Docker 部署可通过环境变量映射，如
KAFKA_LOG_RETENTION_HOURS=24或KAFKA_LOG_CLEANUP_POLICY=compact
关键注意事项
清理不是瞬间完成，也受底层机制约束：
- 删除以“段”为单位，即使某条消息刚过期，也要等整个段过期才删；
- 压缩不改变 offset 连续性，压缩后可能出现跳号（如 offset 5、7 消失），消费者会自动跳到下一个有效 offset；
- 压缩不清理
null key消息，这类消息在压缩过程中被直接丢弃； - 清理过程是异步的，不影响正常读写，也不会阻塞 producer/consumer。
