CosmosDb事务中如何隔离先读后插操作以实现锁、避免409冲突？

现有实现的可行性与问题本质 #

你当前先查询、不存在再创建的锁实现，核心缺陷是存在检查-执行的竞态窗口：

• 虽然CosmosDb的存储过程执行在单分区的原子事务边界内，但文档查询、创建这类IO操作是异步回调模式的，当代码执行到等待IO返回的间隙，存储过程会暂时释放执行权，让引擎调度其他同分区的请求。这就导致两个并发请求可以先后发起查询动作，都拿到“锁记录不存在”的结果，再先后等回调触发创建操作，后执行的创建必然因为主键唯一约束触发409冲突，这也是你遇到偶发报错的根本原因。
• 这种靠业务逻辑判断“是否存在”再做创建的两步模式，没有服务端层面的强约束校验，就算是在同一个存储过程的事务里，也没法完全避免这种异步调度带来的并发冲突。

调整操作顺序的实际效果 #

把流程改成“先尝试插入，插入失败再读取已有记录”的思路是完全可行的，也是CosmosDb上实现这类乐观锁的标准方案：

• CosmosDb的文档创建操作本身是服务端原子的，对同一id+分区键的文档，只会允许一次成功创建，所有重复的同主键创建请求会被直接拦截返回409，完全不需要提前做存在性查询。
• 调整流程后，你不需要预先跑一次查询判断锁是否存在：
  • 直接发起创建操作，只要创建成功，就直接返回锁获取成功的状态，带上文档etag、创建时间
  • 如果创建返回409冲突，说明锁已经被其他请求持有，这时候再读取已存在的锁记录，返回锁被占用的状态即可
• 这种模式可以彻底消除原来的竞态窗口，不会再出现创建操作偶发抛409的问题，同时还能减少一次无意义的前置查询，降低请求单元消耗。

落地注意事项 #

• 所有锁记录必须固定使用同一个分区键值存储，否则存储过程无法正常在单分区内执行（CosmosDb存储过程的执行边界必须对齐单个分区键）。
• 保留你当前实现里的ttl字段，配合容器开启的TTL自动清理能力，可以避免长期不释放的死锁记录残留。
• 当创建操作返回非409类的错误（比如请求限流、服务端临时故障）时，需要直接把错误抛给调用方做重试处理，不要在存储过程内吞掉错误。

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