c# 事件溯源(Event Sourcing)模式下的并发和快照策略

并发冲突典型表现为OptimisticConcurrencyException,应对方式是版本校验+重载重放+幂等重试;快照按需触发(事件数阈值+耗时判断),加载时三段式合并快照与后续事件,序列化需确保无参构造、类型兼容与语义一致。

事件溯源中并发冲突的典型表现和应对方式

在 C# 事件溯源系统中,并发写入最常触发 OptimisticConcurrencyException(或自定义的类似异常),本质是多个线程/请求对同一聚合根尝试基于不同版本号追加事件。EF Core 的 DbUpdateConcurrencyException、自研事件存储中校验 ExpectedVersion 失败,都属于这一类。

关键不是“避免并发”,而是“让并发失败可预测、可重试、不丢数据”:

  • 聚合根必须维护 Version(整数递增)字段,每次成功应用事件后 +1
  • 保存时严格校验:数据库 WHERE 子句含 WHERE AggregateId = @id AND Version = @expectedVersion,或事件存储要求写入时传入 expectedVersion
  • 捕获冲突后,**不直接抛出上层异常**,而是重新加载最新状态(含所有已存事件)、重放业务逻辑、生成新事件序列,再重试 —— 这个过程需幂等且无副作用
  • 重试次数建议限制(如 3–5 次),超限应降级为人工介入或异步补偿,避免雪崩

快照(Snapshot)该在什么时机触发

快照不是“定期执行”,而是“按需截断事件链”。核心判断依据只有一个:EventCount 超过阈值(如 100 或 500) 重建聚合耗时明显升高(实测 >50ms)。

不要用固定时间(如“每天凌晨”)或固定事件数(如“每 100 条”)硬编码触发,因为不同聚合生命周期差异极大 —— 订单聚合可能一天产生 20 个事件,而用户配置聚合可能三年才变 3 次。

推荐做法:

  • 在聚合加载逻辑中,统计从快照点开始读取的事件数量,若 ≥ SnapshotThreshold(例如 200),则在本次保存后主动创建快照
  • 快照本身只存聚合当前状态(State 对象),不含事件;其版本号必须与所覆盖的最后一个事件的 Version 一致
  • 快照存储需支持唯一键约束:(AggregateType, AggregateId, SnapshotVersion),防止重复写入

快照与事件如何协同加载聚合

加载聚合时,不能假设“有快照就一定用快照”,也不能“无视快照全量重放”。正确流程是三段式:

var snapshot = _snapshotStore.GetLatest(aggregateId);
if (snapshot != null)
{
    aggregate = new Order(snapshot.State); // 从快照重建
    var events = _eventStore.GetEvents(aggregateId, afterVersion: snapshot.Version);
    foreach (var e in events) aggregate.Apply(e); // 仅重放快照之后的事件
}
else
{
    aggregate = new Order(); // 空构造
    var events = _eventStore.GetEvents(aggregateId);
    foreach (var e in events) aggregate.Apply(e);
}

注意两个细节:

  • GetEvents(aggregateId, afterVersion: snapshot.Version)afterVersion 是排他性参数(即从 snapshot.Version + 1 开始),否则会重复应用快照已包含的事件
  • 快照中的 State 必须是“可序列化纯净对象”,不能含引用、委托、DbContext 实例等运行时依赖,否则反序列化后无法安全调用 Apply()
  • 若快照损坏或版本错乱,要能 fallback 到全量事件重放 —— 所以快照永远是优化手段,不是状态唯一来源

C

# 实现快照时最容易被忽略的序列化陷阱

System.Text.JsonNewtonsoft.Json 序列化快照时,90% 的问题出在类型丢失和构造器约束上:

  • 聚合状态类必须有 public parameterless constructor,否则反序列化失败(即使你写了 [JsonConstructor],也要确保默认构造器存在)
  • 避免使用 record 类型直接作为快照 State —— 它的不可变性和私有字段会让 JSON 序列化器无法写入,除非显式配置 IncludeFields = truePropertyNamingPolicy = null
  • 若状态中含 DateTimeOffsetdecimal 或枚举,确认序列化器未做格式转换(如把 decimal 转成 double 导致精度丢失)
  • 快照表的数据库字段类型必须匹配序列化结果长度:JSON 字段建议用 NVARCHAR(MAX)(SQL Server)或 JSONB(PostgreSQL),别用 VARCHAR(200) 截断

真正的难点不在“怎么存快照”,而在于“怎么保证快照和事件语义严格一致”——只要有一次 Apply() 方法修改了非状态字段(比如缓存计数器、临时标记),快照就会脱离事件源事实。