如何在按账号ID分区的Cosmos DB中实现序列号跨分区唯一约束？

刚好之前在项目里处理过几乎一模一样的场景，我来给你梳理下可行的方案——完全不用遍历所有分区就能实现跨分区的serial number唯一性，关键是别死磕主集合的分区键限制：

方案1：创建专门的“全局序列号注册表”集合 #

这是最推荐的方案，简单高效。你可以单独创建一个小型的Cosmos DB集合，专门用来记录所有已经被使用过的serial number：

• 把serial number设置为这个集合的分区键，同时也设置为唯一键
• 每次要给用户添加新条目时，先尝试往这个注册表集合里插入一条记录（只存serial number或者关联对应的account ID都行）
  • 如果插入成功，说明这个序列号还没被占用，你再去主集合写入用户的条目
  • 如果插入失败（触发唯一键冲突异常），直接返回“序列号已存在”的提示给用户

这个方案的核心是利用了Cosmos DB单分区内唯一键的强约束，而因为我们把serial number作为分区键，每次检查都是精准定位到单个分区的操作，完全不需要遍历其他分区。唯一的额外开销就是多了一个小集合，以及两次写入操作，但你可以用客户端的事务逻辑（或者Cosmos DB的批量事务）来保证这两步的一致性。

方案2：别用跨分区存储过程！ #

可能有人会想到用Cosmos DB的存储过程来跨分区检查，但我强烈不推荐——跨分区存储过程本质上会遍历所有分区，当你的分区数量上去之后，性能会暴跌，完全不符合你的需求，直接pass这个思路就好。

方案3：应用层分布式锁 + 全局索引（备选） #

如果你的架构里已经有Redis这类分布式缓存，也可以用这个方案：

1. 当要添加新序列号时，先给目标serial number加一个分布式锁（避免并发写入冲突）
2. 然后在主集合里查询serial number（注意要给serial number开启全局索引），检查是否存在
3. 如果不存在，写入主集合后释放锁；如果存在，直接释放锁并返回错误

这个方案的缺点是复杂度稍高——要处理分布式锁的超时、死锁问题，而且全局索引的查询延迟会比单分区操作高一些，所以作为备选方案更合适。

总结 #

优先选方案1，它是最贴合Cosmos DB设计理念的实现方式，既不用遍历所有分区，性能又稳定，代码实现起来也没什么难度。只要先在全局注册表“占坑”，就能稳稳保证跨分区的序列号唯一性。

内容的提问来源于stack exchange，提问作者John von No Man