4. 事件回放基础
在实盘系统中，故障恢复与状态重建的核心能力，是能够把“过去发生过什么”重新读出来，并按正确顺序重新应用。事件回放不是简单地重跑日志，而是围绕事件日志、事件溯源、消息队列、持久化存储与回放机制形成的一条完整数据链路。理解这条链路，才能判断一次回放是否可信、是否完整、是否会引入二次故障。
一、核心原理：事件是状态的唯一事实来源
传统系统常把“当前状态”作为主要存储对象，例如账户余额、持仓数量、订单状态。事件回放则反过来：状态由事件推导而来。每一次下单、成交、撤单、资金划转，都先被记录为不可变事件，再通过顺序应用这些事件，得到某一时刻的状态快照。
事件日志是回放的原材料。它通常具备三个特征：追加写入、不可篡改、全局有序。追加写入保证写入路径简单且高效；不可篡改保证历史可审计；全局有序保证回放时不会出现“先成交后下单”这类因果颠倒。事件溯源则是一种架构模式：不直接保存最终状态，而是保存导致状态变化的事件序列，需要时通过重放事件重建聚合根或整个业务视图。
二、方法流程：从事件产生到状态重建
一个可落地的回放流程通常包含以下环节：
- 事件产生：业务操作成功后，生成带有全局唯一ID、时间戳、序列号、聚合ID、事件类型和负载的事件。
- 持久化写入：事件先写入事件日志或消息队列，确保持久化成功后再对外确认。
- 顺序保证：按分区键或聚合ID保证同一实体的事件严格有序，跨实体事件通过全局序列号或时间戳协调。
- 回放触发：故障恢复、审计核对、新视图构建或压测验证时，从指定检查点开始读取事件。
- 状态应用：回放器按顺序调用事件处理器，将事件应用到内存状态或数据库。
- 校验与对账：回放结束后，与快照、外部对账文件或实时状态进行比对，确认一致性。
下面是一段简化的事件回放伪代码，体现“检查点 + 顺序应用 + 幂等”三个要点：
checkpoint = load_checkpoint("account-001")
events = event_log.read(
aggregate_id="account-001",
from_seq=checkpoint.last_seq + 1,
order_by="seq asc"
)
for e in events:
if e.event_id in checkpoint.applied_ids:
continue
state = apply_event(state, e)
checkpoint.last_seq = e.seq
checkpoint.applied_ids.add(e.event_id)
save_checkpoint(checkpoint)
三、消息队列与持久化存储的分工
消息队列和事件日志经常被混为一谈，但它们在回放体系中的角色不同。消息队列擅长实时分发与削峰填谷，消费者消费后消息可能被删除；事件日志则强调长期保留与可重复读取，是回放的权威来源。实际系统中，常见做法是“消息队列负责传输，事件日志负责存档”，或者直接使用具备持久化日志能力的消息系统。
| 组件 | 主要职责 | 回放中的角色 | 常见风险 |
|---|---|---|---|
| 事件日志 | 追加写入、长期保留、全局有序 | 回放的权威数据源 | 日志截断、序列号回绕 |
| 事件溯源 | 以事件推导状态 | 定义回放逻辑与聚合边界 | 事件版本不兼容 |
| 消息队列 | 实时分发、解耦、缓冲 | 触发回放或同步新视图 | 消息丢失、重复消费 |
| 持久化存储 | 保存事件、快照、检查点 | 提供回放起点与终点 | 写入未落盘、快照过期 |
| 回放机制 | 读取、排序、应用、校验 | 执行状态重建 | 非幂等、顺序错乱 |
四、案例场景：成交回报丢失后的状态重建
假设某交易系统在 10:00:00 至 10:00:05 之间发生网络抖动，部分成交回报未写入实时状态库，但事件日志完整。恢复步骤如下：
- 从快照库加载 09:59:59 的账户快照，作为回放起点。
- 从事件日志读取 10:00:00 之后该账户的所有订单与成交事件。
- 按序列号升序应用事件，遇到重复事件ID则跳过。
- 回放完成后，将重建状态与交易所对账文件比对，确认持仓与资金一致。
- 若发现差异，定位到具体序列号区间，检查事件负载或处理器逻辑。
五、误区与复盘：回放不是“重跑一遍”
最常见的误区是认为只要日志在，回放就一定成功。实际上，以下问题会直接导致回放失败或结果错误：
- 顺序错乱：多分区并行写入时，若未按聚合ID保序，回放会出现因果颠倒。
- 非幂等处理：重复消费或重复回放导致余额被多次扣减。
- 事件版本漂移：旧事件用新处理器解释，字段含义变化引发静默错误。
- 快照与日志不一致：快照生成时未记录对应序列号，回放起点模糊。
- 外部副作用：回放过程中误发真实订单或通知，造成二次故障。
总结来看，事件回放的基础并不神秘：事件日志提供事实，事件溯源提供推导方式，消息队列提供实时通道，持久化存储提供可靠载体，回放机制负责按序、幂等、可校验地重建状态。把这五者的边界和协作关系理清，实盘故障恢复才有稳定的工程基础。