Apache Kafka 不只是消息队列：日志与 Offset 分离如何让事件可重放【Kafka合集】-育师

风控规则上线后，团队发现过去七天漏判了一类订单。订单服务没有重发接口，直接扫描业务库又会冲击线上。此时系统能否补算，不取决于消费者还能不能启动，而取决于七天前的事件是否仍在、消费位置能否独立回退、重复副作用是否可控。

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 请求中携带自己要读取的 Offset，Broker 从该位置返回一段日志。Kafka Design 因此，risk-v1提交到 Offset 900，并不会推动warehouse-v1的 Offset；风控组回退到 500，也不要求 Producer 再发送一次。

这套设计同时把一项责任交给了业务：Kafka 知道某个 Group 提交到哪里，不知道短信是否发出、积分是否入账、目标数据库事务是否完成。Offset 可重放，不等于副作用天然幂等。

相同目标下，任务交付和事件重放不是同一种模型

先锁定共同前提：订单事件需要实时驱动一个处理程序；故障时不能静默丢失；未来可能增加新的下游；七天内可能按新规则重新计算。

执行模型	消费进度由谁维护	一次处理完成后	新下游读取历史	失败恢复的核心成本
任务队列模型	Broker 记录交付与确认状态	已确认任务通常退出待处理集合	需要复制、归档或重新投递	ACK、重投、死信和任务幂等
Kafka Consumer Group	Group 保存各 Partition 的 Offset	Record 是否保留与本组确认解耦	新 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.policy=delete，retention.ms控制日志保留时间，retention.bytes控制每个 Partition 的空间上限；满足条件的是旧 Log Segment，而不是单条 Record。Topic Configs 明确说明，Retention 和清理按 Segment 执行，retention.bytes也按 Partition 计算。

这会产生三个容易忽略的边界：

配置保留七天，不代表任何时刻都能精确拿到七天前的第一条消息；Segment 滚动与删除使实际边界存在粒度。
retention.ms=-1只取消时间上限；磁盘、容量治理和其他清理条件仍需要单独设计。
cleanup.policy=compact保留的是每个 Key 的最新值语义，不等于完整保留事件历史；Tombstone 也有自己的删除保留窗口。

所以，重放 SLA 不能只写保留七天。它至少应同时包含：最大回溯时长、峰值写入字节、Partition 数、磁盘或远端容量、Segment 策略、消费者最长中断时间以及超出 Kafka 窗口后的归档来源。

用两个 Group 证明重放能力，而不是看配置猜

下面是构造实验，不是生产事故复盘。目标是证明三个结论：不同 Group 的位置互不影响；Offset 能在可用范围内回退；业务结果不会因重放翻倍。

实验前提：

Kafka：4.3.1 测试集群 Topic：order-events-replay-test Partition：3 cleanup.policy：delete 数据：10,000 条订单事件 事件字段：event_id、order_id、event_version、produced_at Consumer Group：risk-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.000

Kafka 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-v1`Offset	与重放前一致	Reset 影响了其他 Group
`risk-v1`Offset	从预览位置重新推进	实际没有按计划重放
`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){Stringgroup=args.length==0?"risk":args[0];Propertiesp=newProperties();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(KafkaConsumer<String,String>c=newKafkaConsumer<>(p)){c.subscribe(List.of("order-events"));ConsumerRecords<String,String>records=c.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();}}}