事件溯源中的读取状态管理：添加新事件时如何避免数据重复？

针对你提到的“添加用户前需确保用户不存在”的场景，结合EventStoreDB的特性，有以下几种落地方案：

1. 用EventStoreDB投影构建实时读模型 #

EventStoreDB自带的**连续投影（Continuous Projections）**是处理这类查询需求的核心工具，它可以实时消费事件流并维护专门的读模型（比如用户唯一索引）。

具体实现： #

• 创建一个连续投影，监听所有UserCreated事件，将用户的唯一标识（如邮箱、用户名）作为键，映射到对应的用户流ID或用户ID，存储在投影的状态中。示例投影代码（JavaScript）：

fromAll()
  .when({
    $init: () => ({ userUniqueIndex: {} }),
    UserCreated: (state, event) => {
      // 假设事件数据包含唯一标识（email）和用户ID
      state.userUniqueIndex[event.data.email] = event.data.userId;
      return state;
    }
  })
  .outputState();

• 在处理“添加用户”命令前，通过EventStoreDB的客户端SDK（如.NET/Java SDK）查询该投影的状态，检查目标唯一标识是否已存在。
• 优势：支持复杂查询需求，读模型实时更新，可扩展到其他查询场景；缺点：需要维护投影逻辑，极端并发下可能存在毫秒级延迟（可结合其他方案兜底）。

2. 利用EventStoreDB的流唯一性约束 #

EventStoreDB中，创建流是原子操作：如果尝试向一个已存在的流写入事件（且未指定ExpectedVersion.Any），会直接返回流已存在的错误。你可以利用这一特性实现唯一性校验：

具体实现： #

• 将用户的唯一标识（如邮箱）作为流名称的一部分，比如命名规则为user-by-email-{email}（注意对特殊字符转义）。
• 当处理添加用户命令时，尝试向该流写入UserCreated事件（指定ExpectedVersion.NoStream，即仅当流不存在时才写入）。
• 如果返回StreamExistsException（或HTTP 409冲突），则判定用户已存在，拒绝命令；否则继续完成事件写入。
• 优势：无需额外维护读模型，利用EventStoreDB原生特性，原子性强；缺点：仅适用于简单唯一性校验场景，无法支持复杂查询。

3. 聚合根层面的幂等性校验 #

在事件溯源的聚合根逻辑中，直接加载目标用户的事件流进行校验：

具体实现： #

• 基于用户唯一标识定义聚合流的命名规则（如user-by-email-{email}），处理创建命令时先加载该流。
• 如果流存在且包含UserCreated事件，直接拒绝命令；否则写入UserCreated事件完成创建。
• 优势：业务逻辑内聚在聚合根中，符合DDD原则；缺点：如果用户量较大，频繁加载空流会有性能损耗，适合低并发场景。

并发场景兜底 #

针对极端并发下的竞态问题（比如两个请求同时创建同一个用户，投影还未更新），建议结合流唯一性约束作为最终兜底：即使投影查询显示用户不存在，写入事件时仍通过ExpectedVersion.NoStream确保原子性，避免重复创建。

内容的提问来源于stack exchange，提问作者thef2theg