消息重放机制如何设计？
简化版
消息重放应是独立、可审计的数据修复流程：明确来源、时间/位点范围、目标消费者和副作用策略，先影子验证，再限速分批执行。重放复用原 eventId 或保留明确关联，消费者必须幂等，并防止短信、支付等外部副作用再次发生。
详细版
来源可以是 Broker 保留日志、归档或业务事件表；按 Topic/分区/offset 精确选择，快照原位点和过滤条件。优先使用独立 replay Topic/consumer group，不直接扰动线上消费组；消息带 replayId、originalEventId、原因和批次。
执行前验证历史 Schema、当前业务状态和下游容量，配置 dry-run、速率、并发、暂停和回滚。完成后比较输入量、成功/跳过/失败、幂等命中和业务对账，保存审批与审计记录。
完整版教学
一、重放不是简单改 Offset
改线上组 offset 会改变正常消费进度，且所有副作用重新执行。受控重放更常从历史来源复制选定事件到独立通道，由专用消费者按当前规则处理。目标是修复特定派生状态，而非“再跑一遍看看”。
记忆钩子：重放先限定影响面，再决定哪些副作用允许重做。
二、定义选择范围
选择条件包含 Topic、partition、起止 offset/时间、业务 key、Schema 版本和失败原因。按时间查 offset 要逐分区核对，生产者时钟与延迟到达会使时间窗口不精确。
replay batch R17
source: orders partition 0..7
range: [offset_start, offset_end)
filter: eventType=OrderPaid三、独立通道与元数据
重放消息保留 originalEventId，并增加 replayId、batchId、operator、reason 和 source position。独立 Topic 允许单独限速、暂停与授权；消费者可进入 replay mode，禁用不应重复的通知或外部调用。
| 模式 | 优点 | 风险 |
|---|---|---|
| 重置原组 | 简单 | 干扰线上进度 |
| 新消费组 | 不改原位点 | 副作用需隔离 |
| Replay Topic | 控制最强 | 多一条管道 |
| 离线回填 | 适合大数据 | 逻辑可能不一致 |
四、幂等与当前状态
同 eventId 已成功过的消费者应返回既有结果；需要重新计算派生表时，可用 replay batch 作为新幂等范围，但写入仍需版本条件。历史事件不能覆盖更新状态，例如旧地址事件不应把用户当前地址改回去。
可先重建到影子表，比较校验和与抽样结果后原子切换，比直接覆盖生产表更安全。
五、Schema 与代码版本
一年前的事件可能缺少字段或语义已变化。重放前用 Schema registry/转换器升级到当前内部模型，或运行对应历史消费者；仅“能反序列化”不代表业务含义兼容。
历史代码可能含已修复 bug，因此通常由新版本消费旧事实，同时明确新规则会不会改变当时结果。
转换器和过滤条件也要版本化并随批次存档，否则同一重放范围日后无法复现，审计只能看到输入而看不到当时采用的解释规则。
六、容量、暂停和验证
重放 1 亿条、限速 5000/s，理论至少 100000000/5000=20000s，约 5.56 小时。还要计正常流量和失败重试，给下游留余量。提供 kill switch、分批 checkpoint 和最大错误率护栏。
验证输入=成功+幂等跳过+失败，核对业务行数、金额或状态差异；失败进入独立 DLQ，不能悄悄遗漏。
七、常见误区与追问
- 误区：重置 offset 就完成重放设计。 会干扰线上组且缺少副作用控制。
- 误区：历史消息按当前代码跑一定正确。 Schema 与业务语义可能变化。
- 误区：消费者幂等就无需审批。 重放范围错误仍会造成大规模影响。
- 误区：Broker 永久保留所有消息。 保留期和压缩可能已删除历史。
- 追问：如何避免重复短信？ replay mode 禁用通知或使用原业务幂等键。
- 追问：怎样回滚重放？ 优先写影子表；不可逆副作用需补偿方案。
- 追问：如何证明重放完整？ 用分类计数、checkpoint 和业务对账闭环。
八、加强记忆
重放按“选范围—留原始身份—独立通道—影子验证—限速执行—分类对账”设计。它是高风险数据变更，不是普通消费；幂等防重复，版本条件防旧事件覆盖新状态，审计和 kill switch 控制爆炸半径。