kafka的delete和compact策略本质是静态配置、分工协作：delete按时间/大小删除旧数据，适用于事件日志等不可变场景；compact按键保留最新值，适用于状态同步等kv场景；二者可共存为delete,compact，由broker后台线程执行，java客户端仅需配合设计key结构与消费逻辑。
Java 应用中对接 Kafka 时，理解 Delete 和 Compact 日志清理策略的关键，不在于“切换”动作本身，而在于根据业务数据语义提前选对策略。Kafka 不支持运行时动态切换策略（如 Java 客户端调用 API 改变 topic 的 cleanup.policy），策略是 topic 创建或重配置时静态设定的，后续由 broker 后台线程按规则执行。
什么时候该用 Delete 模式
适合事件流、日志采集、监控指标等只读、不可变、时效性强的数据场景。
- 消息本身没有 key，或 key 无业务唯一性（比如日志行无用户 ID）；
- 下游只需消费一次，不需要回溯某个实体的“最新状态”；
- 关注磁盘占用与保留周期，比如“只保留最近 3 天的埋点数据”；
- 典型配置：
cleanup.policy=delete+log.retention.ms=259200000（3 天）。
什么时候该用 Compact 模式
适合状态同步、维表更新、配置变更等以 key 为标识、需保留最终值的场景。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 每条消息必须带非空 key（如
"user_1001"），且相同 key 会多次写入； - 消费者需要拉取某个 key 的最新快照（比如重启后加载最新用户资料）；
- 数据本质是“覆盖写”，历史中间态可丢弃，但最终态必须保留；
- 典型配置：
cleanup.policy=compact+log.cleaner.enable=true（broker 级必须开启）。
Delete 和 Compact 能否共存
可以，且在某些混合场景下很有价值——不是“切换”，而是同时生效、分工协作。
- 配置为
cleanup.policy=delete,compact； - Compact 负责按键去重，保留每个 key 的最新值；
- Delete 负责兜底：即使 key 没再出现，其最后一条记录若已超时（如 30 天未更新），也会被整体删除；
- 适用于“状态+时效”双重要求的场景，例如用户配置主题：既要保证查到最新配置，又不能让失效账号长期占空间。
Java 侧需要注意的实际约束
客户端代码本身不参与清理逻辑，但需配合策略设计数据结构和消费方式：
- 用 Compact 主题时，生产者必须设置
ProducerRecord<string string>(topic, key, value)</string>，key 不能为空； - 消费者首次启动时，应使用
seekToBeginning()+readCommitted()或启用auto.offset.reset=earliest，才能读到完整状态快照； - 不要依赖 offset 连续性做业务判断——Compact 可能导致 offset 跳变（旧消息被压缩掉）；
- 修改策略需通过 AdminClient 调用
alterConfigs()更新 topic 配置，不是 Java 代码里“切换”，而是运维级变更。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
