风控规则上线后团队发现过去七天漏判了一类订单。订单服务没有重发接口直接扫描业务库又会冲击线上。此时系统能否补算不取决于消费者还能不能启动而取决于七天前的事件是否仍在、消费位置能否独立回退、重复副作用是否可控。Kafka 真正改变架构的地方不是把消息从 A 送到 B而是把事件日志和每个订阅者的消费位置拆开让业务在保留窗口内重新决定从哪里读取。消费完成不会自动删除那条记录Kafka 的核心路径可以压成四步Producer 将 Record 追加到 Topic-Partition → Broker 为 Record 分配 Offset 并保留日志 → 每个 Consumer Group 独立维护自己的消费位置 → 日志按 Topic 的清理与保留策略处理Kafka 4.3.1 的KafkaConsumer文档把一个 Consumer Group 描述为一个逻辑订阅者同组成员共同分摊 Partition不同 Group 则各自接收同一 Topic 的记录。KafkaConsumer API 还明确指出可以通过不同 Group 同时得到类似队列和发布订阅的效果。关键差异在消费位置。Kafka 的设计文档说明Consumer 在 Fetch 请求中携带自己要读取的 OffsetBroker 从该位置返回一段日志。Kafka Design 因此risk-v1提交到 Offset 900并不会推动warehouse-v1的 Offset风控组回退到 500也不要求 Producer 再发送一次。这套设计同时把一项责任交给了业务Kafka 知道某个 Group 提交到哪里不知道短信是否发出、积分是否入账、目标数据库事务是否完成。Offset 可重放不等于副作用天然幂等。相同目标下任务交付和事件重放不是同一种模型先锁定共同前提订单事件需要实时驱动一个处理程序故障时不能静默丢失未来可能增加新的下游七天内可能按新规则重新计算。执行模型消费进度由谁维护一次处理完成后新下游读取历史失败恢复的核心成本任务队列模型Broker 记录交付与确认状态已确认任务通常退出待处理集合需要复制、归档或重新投递ACK、重投、死信和任务幂等Kafka Consumer GroupGroup 保存各 Partition 的 OffsetRecord 是否保留与本组确认解耦新 Group 可从可用 Offset 开始Offset、保留窗口和业务副作用幂等RocketMQ 业务消息Consumer Group 与 Broker 维护消费进度围绕确认、重试和死信继续驱动任务可在消息仍保留时按位点重置业务消息类型更直接但重放、顺序与副作用仍需单独治理数据库 Outbox数据库事务和表记录由清理策略决定可查询或由 CDC 再分发OLTP 存储、扫描、清理与 CDC 运维对象存储归档读取作业自行记录文件长期保存可重新扫描索引、启动时间和批量计算成本这里不是比较谁功能更多。若目标只是把一次性任务尽快分给任意 Worker并按单条任务确认、重投和死信RocketMQ 或其他任务队列模型通常更直接。若多个业务需要以不同节奏消费同一事件并在规则变化后回到过去Kafka 的日志与 Group Offset 分离才形成实际优势。不能因此把 RocketMQ 简化成“消费即删除”两者都能在保留边界内重新消费选型差异在于是以持久化事件日志和多订阅者重放为主线还是以业务消息类型、确认、重试和死信为主线。Kafka 4.3.1 还提供 Share Group允许多个 Share Consumer 以不同于传统 Consumer Group 的方式共享和确认记录。但它解决的是队列式消费不会抹掉日志保留、重投和业务幂等的设计责任本文讨论的重放主线仍以普通 Consumer Group 为准。重放窗口由 Topic 决定不由消费者愿望决定Kafka 能重放的准确表述必须带上条件目标 Offset 对应的数据仍然可用。对于默认的cleanup.policydeleteretention.ms控制日志保留时间retention.bytes控制每个 Partition 的空间上限满足条件的是旧 Log Segment而不是单条 Record。Topic Configs 明确说明Retention 和清理按 Segment 执行retention.bytes也按 Partition 计算。这会产生三个容易忽略的边界配置保留七天不代表任何时刻都能精确拿到七天前的第一条消息Segment 滚动与删除使实际边界存在粒度。retention.ms-1只取消时间上限磁盘、容量治理和其他清理条件仍需要单独设计。cleanup.policycompact保留的是每个 Key 的最新值语义不等于完整保留事件历史Tombstone 也有自己的删除保留窗口。所以重放 SLA 不能只写保留七天。它至少应同时包含最大回溯时长、峰值写入字节、Partition 数、磁盘或远端容量、Segment 策略、消费者最长中断时间以及超出 Kafka 窗口后的归档来源。用两个 Group 证明重放能力而不是看配置猜下面是构造实验不是生产事故复盘。目标是证明三个结论不同 Group 的位置互不影响Offset 能在可用范围内回退业务结果不会因重放翻倍。实验前提Kafka4.3.1 测试集群 Topicorder-events-replay-test Partition3 cleanup.policydelete 数据10,000 条订单事件 事件字段event_id、order_id、event_version、produced_at Consumer Grouprisk-v1、warehouse-v1两个 Group 都消费完成后先执行只读检查bin/kafka-consumer-groups.sh\--bootstrap-server broker:9092\--grouprisk-v1\--describebin/kafka-consumer-groups.sh\--bootstrap-server broker:9092\--groupwarehouse-v1\--describe观察对象是每个 Partition 的CURRENT-OFFSET、LOG-END-OFFSET和 Lag。正常信号是两个 Group 都接近日志末端但其CURRENT-OFFSET分别存在这只能证明提交位置不能证明 10,000 条业务结果全部正确。还要在两个下游分别按event_id对账。下一步只预览risk-v1的回退计划不执行变更bin/kafka-consumer-groups.sh\--bootstrap-server broker:9092\--grouprisk-v1\--topicorder-events-replay-test\--reset-offsets\--to-datetime2026-08-29T00:00:00.000Kafka 4.3.1 的 Consumer Group 管理文档 说明--reset-offsets默认展示计划只有加入--execute才真正修改执行前必须让该 Group 的消费者处于非活动状态。预览结果应逐 Partition 核对NEW-OFFSET新 Offset 早于当前 Offset且位于可用范围支持目标时间仍可重放的判断新 Offset 被调整到可用边界说明请求时间已经超出实际日志范围只有部分 Partition 能回到目标时间说明时间戳、保留边界或数据分布需要继续核对。真正执行 Offset Reset 属于状态变更只能在这个隔离 Topic 和测试 Group 上进行停止risk-v1保存当前 Offset 作为恢复点复核预览结果后增加--execute再启动该组。若预览内容、Topic 范围或 Consumer 活性与计划不符应立即停止不能靠执行后再观察来试错。验收不是 Lag 再次归零重放完成后至少核对四组证据证据成功标准它排除的错误判断warehouse-v1Offset与重放前一致Reset 影响了其他 Grouprisk-v1Offset从预览位置重新推进实际没有按计划重放event_id处理次数重复投递可识别只看 Lag 无法发现重复副作用最终业务结果同一订单只保留符合最高event_version的结果精确重放仍把旧状态覆盖了新状态如果消费者会发短信、扣款或调用外部 HTTP不能仅靠目标表唯一键验收。应把不可逆副作用替换为测试桩或使用独立的幂等账本记录event_id与执行结果。否则这个实验验证的是 Kafka 可以再次交付却可能同时制造第二次业务动作。实验也不能证明以下事情生产峰值下的重放吞吐、跨机房恢复能力、Kafka 之外的长期归档完整性以及所有消费者都正确实现了幂等。这些需要独立容量实验和故障演练。Kafka 适合保存可重读的热事实不适合包办所有历史把保留期无限调大并不会自动得到事件湖。Partition 越多、写入越快、历史越长本地磁盘、副本复制、恢复时间和运维成本越高启用 Tiered Storage 也需要远端存储实现、读取性能和功能限制的独立验证。更稳妥的分层是Kafka保存需要低延迟消费和近期重放的热事件 对象存储保存长期、低成本、可审计的事件归档 数据库/状态存储保存当前业务状态和幂等结果当业务只需要一次性任务分发时不必为了重放能力引入整套日志治理当多个下游、规则迭代、补算和审计成为常态时Kafka 的价值才不再是消息队列四个字能够概括的。队列关注下一条任务交给谁Kafka 关注同一份事实允许哪些业务在什么时间、从什么位置重新读取。源码与 Java两个 Group 如何独立重放同一订单统一依赖为org.apache.kafka:kafka-clients:4.3.1。固定源码入口是KafkaConsumer.poll/commitSync和 Coordinator 的OffsetMetadataManager。提交位点按 Group 保存所以risk不会推进warehouse。以下示例按 Kafka 4.3.1 API 静态审阅未在本环境启动集群运行。importjava.time.Duration;importjava.util.List;importjava.util.Properties;importorg.apache.kafka.clients.consumer.*;importorg.apache.kafka.common.serialization.StringDeserializer;publicclassIndependentReplay{publicstaticvoidmain(String[]args){Stringgroupargs.length0?risk:args[0];PropertiespnewProperties();p.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,localhost:9092);p.put(ConsumerConfig.GROUP_ID_CONFIG,group);p.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,false);p.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG,earliest);p.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG,StringDeserializer.class);p.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG,StringDeserializer.class);try(KafkaConsumerString,StringcnewKafkaConsumer(p)){c.subscribe(List.of(order-events));ConsumerRecordsString,Stringrecordsc.poll(Duration.ofSeconds(10));if(records.isEmpty()){System.out.println(NO_RECORDS);return;}records.forEach(r-System.out.printf(group%s key%s partition%d offset%d%n,group,r.key(),r.partition(),r.offset()));c.commitSync();}}}分别以risk、warehouse运行两者应维护独立 offset换成相同 Group 时分区会分配而非广播。映射是group.id → OffsetMetadataManager → CURRENT-OFFSET。实验只能证明独立读取位置不能证明下游业务已经处理成功。官方资料Kafka DesignKafkaConsumer 4.3.1 APIBasic Kafka OperationsTopic Configs