EventSourcing+CQRS下唯一属性校验及查询方案咨询

一、Customer社会安全号（SSN）唯一性校验的最优方案 #

你的三个方案里，方案3确实是关系型数据库下的业内常规最优解，逐个分析如下：

• 方案1：全量加载事件流重构所有Customer实体后校验。这种方式完全不可行——随着业务增长，事件量会指数级上升，全量重构的性能损耗极大，根本无法支撑生产环境的并发创建需求。
• 方案2：查询读模型校验。读模型的最终一致性特性决定了这里存在“时间窗口漏洞”：比如刚创建的Customer事件还没同步到读模型，此时另一个请求查询读模型会误以为SSN可用，导致重复创建。除非你的业务能接受极低概率的重复（大部分场景都不能），否则绝对不能用这个方案。
• 方案3：事件库同库建立SSN唯一约束表，与事件提交同事务处理。具体做法：
  • 在事件库中新建一张customer_ssn_unique表，包含ssn（加唯一约束）和customer_id两个字段
  • 处理创建Customer的命令时，先尝试往这张表插入当前SSN和待生成的Customer ID（或占位符），利用数据库唯一约束抛出冲突异常；插入成功后，在同一个事务中写入Customer创建事件
  • 后续如果Customer被删除（有对应删除事件），可异步删除这张表中的对应记录（或保留做历史校验，依业务需求而定）
    这种方式利用数据库事务的ACID特性，保证了SSN校验的强一致性，同时避免了全量事件加载的性能问题，是业内处理这类全局唯一约束的标准做法。

二、“获取所有30岁以上客户”这类查询的常规处理方式 #

这类统计/过滤类查询，业内的标准做法就是基于读模型处理，原因如下：

• 重构全事件流的方式完全不现实，性能和时间成本都无法接受，只适合极端场景下的故障恢复，绝对不能作为常规查询手段。
• 读模型的核心定位就是为这类查询优化：通过事件订阅（Projection）机制，异步将Customer的关键属性（比如出生日期、年龄、基本信息）同步到专门的读模型表（比如customer_query_view），读模型表可根据查询需求建立索引（比如年龄索引），查询时直接走读模型表，性能和传统数据库查询无异。
• 关于最终一致性：这类查询绝大多数场景下不需要强一致性，比如“30岁以上客户列表”即使延迟几秒更新，对业务来说完全可接受。如果确实有强一致的查询需求（比如监管要求实时准确的统计），可考虑两种补充方案：
  1. 针对特定查询构建“准实时读模型”，缩短事件同步延迟（比如用高吞吐量消息队列投递，或数据库触发器同步）
  2. 对查询结果做二次校验：先查读模型，再针对关键数据加载对应Customer的事件流重构实体，验证数据准确性（但这种方式会增加复杂度，只适合极小部分场景）

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