怎么在MongoDB中实现乐观锁_基于版本号字段的条件更新

首页

数据库

热心网友

转载

2026-04-23

怎么在MongoDB中实现乐观锁？基于版本号字段的条件更新

怎么在MongoDB中实现乐观锁_基于版本号字段的条件更新

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

为什么 `updateOne` 加 `$eq` 版本号检查不等于乐观锁

很多开发者容易掉进一个思维陷阱：直接在 updateOne 的查询条件里写上 { version: { $eq: 1 } }，就以为万事大吉，能防止数据被覆盖了。其实，这个做法漏掉了一个关键环节：它并没有保证你“读出的那个 version 值，就是当前数据库里的最新值”。

想象一下这个场景：你先读到 version 是 1，然后开始处理业务逻辑。就在这个空档，另一个操作已经悄悄把 version 更新到了 2。此时，你仍然拿着旧的版本号 1 去执行更新，结果居然还能匹配成功。这哪里是乐观锁？这分明是一个典型的条件竞态漏洞，误判了更新状态。

所以，真正靠谱的做法，必须把“读取版本号”和“更新校验”这两个动作，串成一个原子操作。这得依赖 MongoDB 单文档写操作的天然原子性来兜底。具体流程应该是：

先用 findOne 取出文档及其当前的 version 值。
业务逻辑处理完毕后，在 updateOne 中一次性完成两件事：检查 version 是否未变，同时将 version 自增。
最后，必须检查 result.matchedCount === 1 才意味着更新成功，否则就得走重试或者报错流程。

如何用 `$set` 和 `$inc` 一次完成版本校验与自增

这里有个技术细节需要注意：MongoDB 的更新操作，不允许在查询条件里直接引用原字段值做动态比较（比如写成 { version: oldVersion } 这种变量形式）。但是，我们可以巧妙地利用 $eq 操作符配合 $inc 运算符，在单次写入中完成校验和版本号递增，从而杜绝中间状态被篡改的可能。

来看一个 Node.js 驱动下的示例代码：

const result = await collection.updateOne(
  { _id: docId, version: 5 },
  {
    $set: { updatedAt: new Date(), /* 其他需要更新的字段 */ },
    $inc: { version: 1 }
  }
);

这里有几点需要特别提醒：

version 字段务必使用数字类型（如 Integer），字符串或者 ObjectId 是无法进行 $inc 操作的。
查询条件里的 version: 5，应该是你上一步 findOne 读到的确切值，而不是一个硬编码的数字。
如果返回结果的 matchedCount 为 0，那就清晰表明，在你读取之后、更新之前，这条数据已经被别人修改过了，你的本次操作自动失效。
切忌在 $set 阶段再次设置 version: 6。这样做不仅绕过了原子递增的保护，而且在并发写入时极有可能导致版本号被意外覆盖。

为什么不用 `findAndModify` 或事务替代

你可能会想，findAndModify 命令能原子性地返回修改前的文档，是不是更合适？实际上，它依然没有解决核心问题：你仍然需要自己手动去比对版本号。况且，它的原子性仅限于单个文档内部，无法嵌入更复杂的业务逻辑判断。

至于启用多文档事务，那更是杀鸡用牛刀了。乐观锁的设计初衷，就是为了避免数据库层面的锁表开销。如果仅仅为了一个版本号检查就去开启事务，反而会引入写锁，增加性能损耗，得不偿失。

更务实的方案选择是：

对于绝大多数单文档更新场景，坚持使用带 version 条件的 updateOne。它足够轻量、快速，并且兼容所有 MongoDB 版本。
如果需要跨多个文档保持强一致性，那其实已经超出了乐观锁的典型应用范围。这时候，应该考虑在业务层做补偿，或者接受最终一致性方案。
如果一个文档频繁发生更新冲突（比如每秒被多次争抢修改），那很可能不是技术选型问题，而是数据模型设计需要反思——要么拆分数据粒度，要么就该考虑引入分布式锁了。

容易被忽略的初始化和边界问题

乐观锁机制要顺利运转，初始化工作不能马虎。在第一次插入文档时，必须显式地将 version 字段设为 0 或 1null。否则，后续所有基于 $eq 的匹配都会失败。

另外，不同驱动程序的行为细节也值得留意：

MongoDB Node.js Driver 从 v4 版本开始，默认启用 strict 模式，undefined 字段不会被发送到数据库，但 null 会。因此，统一用 0 来初始化版本字段是最稳妥的。
如果使用 Mongoose ODM，记得关闭其默认的 versionKey 选项（即设置 versionKey: false），否则它会自动管理一个 __v 字段，干扰你自己的版本控制逻辑。
客户端时间不同步不会影响 version 机制，但请注意：绝对不要用 updatedAt 这类时间戳字段作为版本依据——它们既不具备可比性，也无法原子递增。