事件溯源是什么
事件溯源以事件序列作为状态的事实来源：系统只追加记录发生了什么，当前状态由事件按顺序重放得到。它带来完整的审计轨迹、可重建任意时点状态的能力，以及天然与事件驱动架构契合的优势；代价是查询需要投影或读模型、事件成为不可随意修改的契约、重放成本需要快照控制。它适合以状态变更为核心、追溯价值高的领域，如账务与订单。
基本信息
| 存储 | 只追加的事件日志（append-only），不支持就地更新 |
|---|---|
| 快照 | 定期保存聚合状态，缩短重建时间 |
| 收益 | 完整审计轨迹、可重建任意时点状态、天然支持事件驱动 |
| 约束 | 事件不可变，历史事件的语义只能通过版本化与迁移演进 |
| 配套 | 读取侧使用投影或读模型，配合 CQRS 组织查询 |
工程要点
| 主题 | 做法 |
|---|---|
| 快照 | 每 N 个事件或按体积触发，控制重建时长 |
| 版本化 | 事件 schema 带版本字段，升级后仍可读旧事件 |
| 读侧 | 查询走投影或读模型，不扫描事件流 |
| 归档 | 冷事件转储到对象存储，保留回放能力 |
| 并发 | 按聚合标识串行写，用期望版本号做乐观并发控制 |
| 隐私 | 个人数据需加密或单独存储，避免永久留存敏感信息 |
典型使用场景
- 账务与流水：每一笔变动都有据可查，支持任意时点回溯
- 订单生命周期：完整保留状态变更轨迹，便于纠纷处理
- 规则频繁调整的业务：按新规则重放历史事件即可重算
- 审计合规场景：监管要求可解释的数据变更过程
- 与事件驱动集成：写侧产生事件，读侧与下游订阅消费
- 调试与复盘：按事件顺序复现线上问题发生过程
事件溯源不等于必须全量存储：快照加增量事件的组合是常见做法，既能快速重建聚合，也保留完整历史。
事件一旦发布即成为契约；修改历史事件语义需要版本化与迁移策略，直接改写旧数据会破坏所有派生状态的可信度。