kafka compacted 主题通过保留每个 key 的最新 value 实现历史状态持久化，需显式配置 cleanup.policy=compact、delete.retention.ms，并确保生产者使用稳定非空 key、消费者处理 tombstone 消息以重建最终一致状态。
Java 中使用 Kafka 的 compacted 主题实现历史状态持久化，核心是让每个 key 对应的最新 value 持久保留，而不是按时间或大小被删掉。这相当于在 Kafka 上构建一个分布式的、可回溯的键值存储，特别适合用户配置、订单状态、设备快照等需要“最终一致性”而非完整历史的场景。
主题必须启用 compaction 策略
创建 topic 时需显式设置 cleanup.policy=compact（不能只依赖 broker 默认的 delete）。Java 客户端本身不参与策略生效，但必须配合服务端配置：
- 用 AdminClient 创建 topic 时传入：
"cleanup.policy" → "compact" - 若已有 topic，可用
alterConfigs更新（Kafka 2.0+ 支持动态修改） - 推荐同时配
"delete.retention.ms"=86400000（1天），确保 tombstone 消息（key 存在但 value=null）能被保留足够久，避免误删逻辑上已删除的 key
生产者必须带非空 key 并合理设计 key 结构
Log Compaction 只对有 key 的消息起作用。key 是压缩的唯一依据，所以：
- 每条状态更新消息的 key 必须稳定且有意义，例如
"order_123456"、"user_789" - 避免使用 UUID 或时间戳作为 key，否则无法归并；也不要用 null key，这类消息会被跳过压缩
- value 推荐为完整状态快照（如 JSON 字符串），而非增量 patch，方便下游直接消费最新态
消费者需支持从头读取 + 处理 tombstone
要重建完整状态，消费者通常要执行一次全量拉取（seek to beginning + poll）。这时要注意：
- 设置
auto.offset.reset=earliest，确保从最早 offset 开始消费 - 遇到 value == null 的消息（即 tombstone），表示该 key 已被逻辑删除，应用层应清除本地对应状态
- 因压缩是异步后台行为，刚写入的消息可能尚未被压实，所以首次加载后建议再追一次实时流，保证状态最终一致
配合 Java 应用做状态恢复与缓存同步
典型模式是：启动时加载 compacted topic 全量最新态 → 运行中持续消费增量变更 → 本地缓存与 Kafka 状态保持镜像：
- 可用 ConcurrentHashMap 或 Caffeine 构建内存状态映射，key 为消息 key，value 为解析后的对象
- 消费逻辑中统一处理：非 tombstone 则 put；tombstone 则 remove
- 若需强一致性，可结合事务或幂等写入，但 compacted topic 本身不提供跨分区原子性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
