风控规则上线后，团队发现过去七天漏判了一类订单。订单服务没有重发接口，直接扫描业务库又会冲击线上。此时系统能否补算，不取决于消费者还能不能启动，而取决于七天前的事件是否仍在、消费位置能否独立回退、重复副作用是否可控。
Kafka 真正改变架构的地方，不是把消息从 A 送到 B，而是把事件日志和每个订阅者的消费位置拆开，让业务在保留窗口内重新决定从哪里读取。
消费完成不会自动删除那条记录
Kafka 的核心路径可以压成四步：
text
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 能在可用范围内回退；业务结果不会因重放翻倍。
实验前提：
text
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 都消费完成后，先执行只读检查：
bash
bin/kafka-consumer-groups.sh \
--bootstrap-server broker:9092 \
--group risk-v1 \
--describe
bin/kafka-consumer-groups.sh \
--bootstrap-server broker:9092 \
--group warehouse-v1 \
--describe观察对象是每个 Partition 的 CURRENT-OFFSET、LOG-END-OFFSET 和 Lag。正常信号是两个 Group 都接近日志末端，但其 CURRENT-OFFSET 分别存在；这只能证明提交位置，不能证明 10,000 条业务结果全部正确。还要在两个下游分别按 event_id 对账。
下一步只预览 risk-v1 的回退计划，不执行变更：
bash
bin/kafka-consumer-groups.sh \
--bootstrap-server broker:9092 \
--group risk-v1 \
--topic order-events-replay-test \
--reset-offsets \
--to-datetime 2026-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-v1 Offset |
与重放前一致 | Reset 影响了其他 Group |
risk-v1 Offset |
从预览位置重新推进 | 实际没有按计划重放 |
event_id 处理次数 |
重复投递可识别 | 只看 Lag 无法发现重复副作用 |
| 最终业务结果 | 同一订单只保留符合最高 event_version 的结果 |
精确重放仍把旧状态覆盖了新状态 |
如果消费者会发短信、扣款或调用外部 HTTP，不能仅靠目标表唯一键验收。应把不可逆副作用替换为测试桩，或使用独立的幂等账本记录 event_id 与执行结果。否则，这个实验验证的是 Kafka 可以再次交付，却可能同时制造第二次业务动作。
实验也不能证明以下事情：生产峰值下的重放吞吐、跨机房恢复能力、Kafka 之外的长期归档完整性，以及所有消费者都正确实现了幂等。这些需要独立容量实验和故障演练。
Kafka 适合保存可重读的热事实，不适合包办所有历史
把保留期无限调大并不会自动得到事件湖。Partition 越多、写入越快、历史越长，本地磁盘、副本复制、恢复时间和运维成本越高；启用 Tiered Storage 也需要远端存储实现、读取性能和功能限制的独立验证。
更稳妥的分层是：
text
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 静态审阅，未在本环境启动集群运行。
java
import java.time.Duration;
import java.util.List;
import java.util.Properties;
import org.apache.kafka.clients.consumer.*;
import org.apache.kafka.common.serialization.StringDeserializer;
public class IndependentReplay {
public static void main(String[] args) {
String group = args.length == 0 ? "risk" : args[0];
Properties p = new Properties();
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 = new KafkaConsumer<>(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();
}
}
}分别以 risk、warehouse 运行，两者应维护独立 offset；换成相同 Group 时，分区会分配而非广播。映射是 group.id → OffsetMetadataManager → CURRENT-OFFSET。实验只能证明独立读取位置，不能证明下游业务已经处理成功。