MongoDB事务并发更新同一文档的乐观锁解决方案

先明确一个核心概念：在MongoDB里，用findOneAndUpdate配合version字段来实现乐观锁，本质上并不是开启一个事务。但它确实能在无需事务的情况下，有效避免单文档的并发覆盖问题。关键在于，整个“检查版本号、更新数据、递增版本”的过程，被MongoDB打包成了一个原子操作。如果更新失败，返回的matchedCount会是0，这时你就知道需要重试了。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

findOneAndUpdate 带 version 条件不是事务，但能避免并发覆盖

MongoDB的findOneAndUpdate操作本身不会开启事务，也不会加锁。但它天然具备单文档的原子性——这正是乐观锁能够落地的基础。你完全不需要用事务来包裹它以防止并发覆盖，反而应该避免滥用事务。要知道，事务在写入时会对涉及的文档加写锁（在WiredTiger存储引擎层），在高冲突场景下很容易导致操作排队，拖慢整体吞吐量，甚至可能触发“write conflict”错误而被自动中止。

真正起作用的，是你在查询条件（filter）里显式地带上version字段进行匹配，再配合更新操作符$inc: { version: 1 }。MongoDB会把“检查旧的version值是否还存在”和“递增版本号并更新业务字段”这两步，打包成一次原子性的写入操作。只要中间没有其他人抢先修改过，操作就会成功；否则，matchedCount === 0，你就知道该启动重试逻辑了。

• 事务的适用场景：它更适合保障跨文档的一致性，比如转账场景中扣减A账户余额并增加B账户余额。对于单文档更新使用事务，无异于杀鸡用牛刀。
• 关注 matchedCount：findOneAndUpdate返回结果中的result.matchedCount比modifiedCount更可靠。前者表示“条件命中且执行了更新”，后者只表示“字段值真的发生了变化”。而在乐观锁场景下，你更关心的是“我之前读到的状态是否还有效”。
• 注意驱动版本：Node.js Driver 4.x及以上版本，默认返回的是更新前的文档（returnDocument: 'before'）。如果你需要拿到更新后的最新快照，必须显式地将其设为'after'。

重试逻辑里最容易漏掉的三件事

很多人以为写个while (retry < maxRetry)循环就万事大吉了，结果上线后还是会出现更新丢失。问题往往不出在重试本身，而在于重试的“上下文”没有清理干净。

• 必须重新读取：每次重试前，务必重新执行findOne来获取文档的最新状态。绝不能复用第一次读出的version和业务字段值，否则你就是在用已经过期的快照反复尝试，注定失败。
• 确保外部操作幂等：如果更新前需要调用外部服务（比如发送信息、扣减第三方账户余额），必须确保这些操作是幂等的。否则，重试会导致重复扣款、重复发送通知等严重问题。
• 准确判断失败原因：不要只看result.value === null。还要检查result.lastErrorObject?.code === 11000（表示唯一键冲突）或result.matchedCount === 0。后者才是乐观锁失败最明确的信号。

version 字段初始化和类型必须严格

version字段绝非装饰品，它是整个乐观锁机制的命门。MongoDB不会自动创建它，也不会自动帮你递增或校验类型。

• 初始化必须显式：插入第一条文档时，必须显式设置version: 0或version: 1。不能留空（null、undefined）或使用空字符串，否则后续所有基于$eq的匹配都会失效。
• 类型必须是数字：version字段必须是数字类型（如NumberInt或NumberLong），绝不能是字符串"1"或ObjectId。因为字符串在BSON里是按字典序比较的，会导致"10" < "2"这样的逻辑错乱。
• 禁止手动赋值：绝对不要在$set里手动给version赋值（如version: 2）。这完全绕过了原子递增，而且在并发写入时，可能会把别人刚刚递增到的版本号2，又覆盖回2，等于版本号没变，锁机制形同虚设。

冲突太频繁时，别硬扛乐观锁

如果压测时发现matchedCount === 0的比例超过10%，那就说明乐观锁已经退化成了一场“重试风暴”。这通常不是代码写得不够好，而是数据模型或业务粒度的设计需要调整了。

• 优先使用原子操作符：考虑能否用$inc、$push等原子操作符，直接替代“读取-计算-写入”的流程。例如，库存扣减完全可以直接用$inc: { stock: -1 }。
• 热点文档拆分：对于热点文档（如用户余额），可以考虑将其拆分成多个子文档。例如，把user.balance拆成balance_shard_0到balance_shard_9，每次更新时随机选取一个分片（shard）进行操作，最后汇总结果。这能将冲突概率降低近一个数量级。
• 引入分布式锁：如果业务要求强一致性且冲突率极高（如秒杀场景），那就需要引入分布式锁（如基于Redis+Lua的实现）。但必须特别注意锁的粒度和过期时间，避免失败的请求持有锁不放，导致整个链路卡死。

总而言之，version字段的生命周期从文档插入的第一行代码开始，到文档被删除的最后一行才结束。中间的任何一个环节松懈，都可能让精心设计的乐观锁机制变得毫无用处。