## 01、痛点

凌晨三点，运营群炸了：某爆款商品库存明明还有 50 件，后台却显示负数，超卖了几十单。我是老李，被拉起来救火。第一反应：是不是代码在并发下把库存扣成了负数？翻出核心逻辑，发现是典型的 find → Java 修改 → save：先按 id 查出商品文档，拿到 stock，减去 1，再保存回去。这个流程在压测下必然出问题。

更具体地看，很多 Java 项目里会这么写：

Document doc = productRepo.findById(skuId);
int currentStock = doc.getInteger(stock);
doc.put(stock, currentStock - 1);
productRepo.save(doc);

这段逻辑单线程跑没问题，一上并发就露馅。假设库存还剩 10 件，两个请求几乎同时到达：

- 线程 A 执行 findById，读到 stock = 10
- 线程 B 执行 findById，也读到 stock = 10
- 线程 A 在内存里把 stock 改成 9，写回数据库
- 线程 B 在内存里也把 stock 改成 9，后写回数据库

最终数据库里的库存是 9，而不是正确的 8。少扣的那一件就是超卖。如果并发量再大一点，100 个请求同时读，库存可能只被扣掉几次，系统眼睁睁看着超卖。

浏览量也是同样的问题：文章详情页每次打开都先读取 viewCount，加 1，再保存。高流量下，几十次浏览只增加一次计数，数据完全不准确。点赞、收藏、评论数、SKU 数组的局部修改，凡是走“读出来、改一改、存回去”的路线，都躲不开这个坑。

问题的本质不是 Java 代码写得不好，而是应用层读改写之间有一个时间窗口。这个窗口里没有锁，后写会把先写的结果覆盖掉，这就是丢失更新。更糟的是，很多时候开发同学为了修这个 bug，第一反应是加分布式锁，结果系统越写越复杂，吞吐还上不去。其实 MongoDB 早就给了更优雅的答案。

## 02、是什么

MongoDB 一个非常重要的能力，是直接针对 Document 字段进行原子更新，而不是每次读取完整对象再保存。换句话说，你不需要把文档拉到应用层改完再写回去，而是把“改哪个字段、怎么改”用更新表达式发给数据库，数据库在服务端完成原子操作。

这套更新表达式通常叫 Update DSL，核心操作符有几个：

$set：给指定字段赋值。比如把某个商品的状态改成“下架”，其他字段不受影响。

$inc：对数值字段做原子加减。正数增加，负数减少。非常适合计数、库存、余额等场景。

$push：向数组追加元素。比如给某个文档的 SKU 数组新增一个规格，或者给用户消息列表追加一条消息。

$pull：从数组移除满足条件的元素。比如从购物车删除某个商品，或者从标签集合移除某个标签。

upsert：update 时如果查询条件没有匹配到文档，就插入一条新文档。常用于“有则更新，无则插入”的幂等操作。

findAndModify：原子地查找并修改一个文档，可以返回修改前或修改后的文档。在 Java 驱动里通常对应 findOneAndUpdate。

单文档原子性是这里的基石。MongoDB 保证对单个文档的所有写操作是原子的，要么全部生效，要么全部不生效。两个并发更新同一文档时，数据库会串行化执行，不会出现前文那种读改写互相覆盖。

举个最简单的例子，把库存减 1 可以写成：

db.products.updateOne(
  { _id: skuId },
  { $inc: { stock: -1 } }
)

这条命令不需要先查询库存，也不需要把文档读回 Java 内存。数据库自己知道要把 stock 字段减 1，整个操作在文档级别原子完成。

## 03、为什么

为什么 $inc、$set 这些更新表达式能解决覆盖问题？因为“读出旧值、计算新值、写入新值”这三个步骤被压缩到了数据库内部。应用层只发送一个意图：把 stock 减 1。至于当前 stock 是多少，数据库拿着文档级锁或并发控制机制去处理。

在 find → Java 修改 → save 的模式里，读和写是两次独立操作，中间隔着网络往返和应用逻辑。这个窗口越长，并发越高，丢更新越严重。而服务器端原子更新把整个操作变成一次请求、一次执行，天然没有应用层窗口。

这样做至少带来四个好处：

第一，并发安全。两个 $inc 操作先后到达，MongoDB 会串行化处理，最终 stock 被扣两次，结果正确。

第二，网络开销小。读改写需要两次请求，原子更新只需要一次请求，延迟更低。

第三，锁粒度小。MongoDB 单文档操作只锁一个文档，其他文档的读写照常进行，吞吐不受太大影响。

第四，代码更简洁。不用写复杂的事务或分布式锁，更新意图直接表达在 DSL 中。

当然，这里要强调“单文档”三个字。如果是跨多文档的改动，比如从 A 文档扣库存、再往 B 文档写订单，单文档原子性管不了。这种场景需要多文档事务。但在很多业务中，如果数据结构设计合理，把需要一起更新的字段放在同一个文档里，就能享受单文档原子更新的红利。

## 04、架构

MongoDB 的单文档原子性由存储引擎保障。以 WiredTiger 为例，它采用文档级并发控制。同一时刻对同一个文档的写操作会排队，对不同文档的写操作可以并行。更新请求到达 mongod 后，会解析更新表达式，然后发给存储引擎。存储引擎在文档级锁或乐观并发控制下完成原子更新。

大致的链路可以这样理解：

应用 -> mongod -> WiredTiger -> 文档级原子操作

当副本集部署时，主节点负责处理写操作。单文档原子更新在主节点执行完成后，再通过复制机制同步到从节点。因为复制的是操作结果或者 oplog，单个文档的原子性在复制过程中仍然保持。

findAndModify 是另一个值得留意的能力。它在一个操作里完成“查找 + 更新 + 返回”三件事，并且返回的文档与更新结果一致。例如把订单状态从“待支付”改成“已支付”，同时把更新后的订单返回给前端，这个操作不会出现两个请求都支付成功的情况。因为它也是单文档原子操作，底层与 updateOne 类似，只是多了返回文档的能力。

需要注意的是，MongoDB 的原子更新是在单个文档范围内，而不是整个集合或整个库。因此数据建模时，如果能把相关字段聚合到同一个文档，原子更新的威力会更大。比如商品文档里同时包含库存、浏览量、SKU 数组，扣库存、加浏览量、修改 SKU 都可以在同一次更新里用多个操作符完成。

## 05、实战

看完概念，我们具体看三类常见业务的落地。

一、库存 stock -= 1

库存扣减是典型的高并发计数。基本写法是：

db.products.updateOne(
  { _id: skuId, stock: { $gte: 1 } },
  { $inc: { stock: -1 } }
)

这里过滤条件里加了 stock: { $gte: 1 }，确保库存大于等于 1 才执行扣减。如果 modifiedCount 为 0，说明库存已经不足，前端可以直接提示“已售罄”。这样从源头上避免了库存变成负数。

在 Java 驱动中，同样用 updateOne 方法，传入过滤条件和更新表达式即可。重点是把业务判断下推为查询条件，而不是在应用层判断。

二、浏览量 viewCount += 1

浏览量场景更简单：

db.articles.updateOne(
  { _id: articleId },
  { $inc: { viewCount: 1 } }
)

每次打开文章，直接发这条命令，数据库负责原子加 1。不用担心丢失，也不用先查出来。如果还想顺便记录浏览用户，可以再配合 $push 将用户 id 追加到 viewUsers 数组，并配合 $addToSet 去重。

三、SKU 数组修改

数组修改是平时很容易踩坑的地方。如果先把整个 SKU 数组读出来，在 Java 里改完再保存回去，并发下整个数组都可能被冲掉。正确做法是使用数组更新操作符。

新增一个 SKU：

db.products.updateOne(
  { _id: productId },
  { $push: { skus: { skuId: newId, price: 9.9, stock: 10 } } }
)

删除一个 SKU：

db.products.updateOne(
  { _id: productId },
  { $pull: { skus: { skuId: oldId } } }
)

更新数组中某个元素的字段，可以用位置操作符 $：

db.products.updateOne(
  { _id: productId, skus.skuId: targetId },
  { $set: { skus.$.price: 8.8 } }
)

如果数组里有多个元素需要更新，可以使用 arrayFilters 配合 $[element] 表达式。

upsert 的实战示例：用户登录时更新登录次数。如果没有该用户记录，则插入一条新文档，同时记录创建时间：

db.users.updateOne(
  { openId: openId },
  { $setOnInsert: { createTime: now }, $inc: { loginCount: 1 } },
  { upsert: true }
)

findAndModify 实战示例：订单支付状态流转。查询条件带 status: 待支付，更新成已支付，并返回更新后的文档：

db.orders.findAndModify({
  query: { _id: orderId, status: 待支付 },
  update: { $set: { status: 已支付 } },
  new: true
})

这里用单文档原子操作防止两个支付回调同时把订单改成已支付，配合条件查询可以避免重复支付。

## 06、洞见

MongoDB 的优势之一，就是把业务原子操作尽可能下推到单 Document。这句话听起来简单，但背后是一种数据建模和业务逻辑的重新思考。

很多从关系型数据库转过来的工程师，习惯把 MongoDB 当成一个对象存储，读写方式还是先查再改。这带来的问题不仅是并发覆盖，还把数据库的性能浪费在应用层逻辑上。真正用好 MongoDB，应该让数据库多做它擅长的事：原子地更新字段、数组、计数。

要做到这一点，有几个指导原则：

第一，能用一个文档表达的状态，就不要拆成多个文档。比如电商商品，把库存、浏览量、SKU 数组放在一个文档里，扣库存、浏览量加 1、改 SKU 都可以在同一次更新里完成，避免跨文档事务。

第二，单个字段的自增自减，永远优先用 $inc。库存、点赞数、评论数、积分、余额，这些场景用 $inc 最合适。

第三，数组的局部修改，永远优先用 $push、$pull、$set 配合位置操作符。不要整组读出来改，那样既危险又低效。

第四，状态流转用 findAndModify 或 updateOne 带条件更新。把前置状态放在查询条件里，避免并发下状态被重复推进。

第五，跨文档事务是最后手段。MongoDB 支持多文档事务，但事务的成本比单文档原子更新高得多。如果可以通过嵌入数据模型把多个操作压缩到一个文档，就不要轻易开启事务。

说到底，MongoDB 给了我们一个机会：让数据库成为原子操作的执行者，而不是把一致性压力全部丢给应用层。这个能力一旦用起来，很多并发 bug 会从根源上消失。

## 07、行动

看完文章，最重要的事情是把库存、点赞、计数三个“读改写”流程改造成服务器端原子更新。这里我列一个可以立马执行的行动清单：

第一步，梳理现有读改写。在代码库中搜索 findById / findByXxx + save 的组合，找出所有库存、点赞、计数、状态流转的读改写点。

第二步，库存扣减改成带条件更新。用 updateOne 搭配 stock: { $gte: 1 } 过滤，再 $inc: { stock: -1 }。根据 modifiedCount 判断是否扣减成功，避免库存为负。

第三步，点赞数、收藏数、评论数等计数场景，全部改成 $inc。点赞还可以配合 $addToSet 防止重复点赞，取消点赞用 $pull 移除。

第四步，SKU 数组修改改用 $push、$pull、$set 和位置操作符。不要在应用层整体读写数组。

第五步，需要返回更新后文档的场景，使用 findOneAndUpdate 或 findAndModify。比如支付状态流转、抢购成功返回最新库存。

第六步，补上并发测试。用 JMeter 或压测脚本模拟同一时间大量并发请求，验证库存不为负、计数不丢失、SKU 数组不被覆盖。

第七步，建立代码规范。在团队 wiki 里明确：禁止对单文档字段做“读取-修改-保存”，所有数值增减、数组修改必须使用更新 DSL。

这三类流程只是起点。掌握了单文档原子更新后，你会发现更多适合下推的原子操作，比如积分变动、余额扣减、库存回补、状态机流转。越早用上，越能避免那些半夜救火的经历。

## 08、小结

MongoDB 的单文档原子更新，是解决高并发读改写覆盖问题的第一选择。别再手动 find → Java 修改 → save 了，这种做法在并发下必然丢更新。

用 $inc 做计数，用 $set 做字段赋值，用 $push / $pull 做数组修改，用 upsert 做有则更新无则插入，用 findAndModify 做原子查找并更新。把业务原子操作下推到数据库，代码更简单，性能更好，数据更一致。

下半夜再被库存超卖电话吵醒的概率，会小很多。

## 09、链接与概念说明

概念说明：

单文档原子性：MongoDB 保证对单个文档的所有写操作是原子的，不会出现部分写入或并发冲突。

Update DSL：描述文档字段如何更新的表达式，包含 $set、$inc、$push、$pull 等操作符。

upsert：update 时如果查询条件无匹配文档，则插入一条新文档。

findAndModify：原子地查找并修改文档，并返回修改前或修改后的文档。

WiredTiger：MongoDB 默认存储引擎，提供文档级并发控制和单文档原子写。

官方参考链接：

MongoDB Update Operators：https://www.mongodb.com/docs/manual/reference/operator/update/

findAndModify：https://www.mongodb.com/docs/manual/reference/command/findAndModify/

upsert 行为说明：https://www.mongodb.com/docs/manual/reference/method/db.collection.updateOne/

WiredTiger 存储引擎：https://www.mongodb.com/docs/manual/core/wiredtiger/

建议把官方文档里的更新操作符通读一遍，尤其是 $inc、$push、$pull、$set、数组位置操作符和 arrayFilters。这些操作符看起来多，但常用的就几个，吃透之后，很多业务逻辑会变得更简单。

凌晨三点，运营群炸了：某爆款商品库存明明还有 50 件，后台却显示负数，超卖了几十单。我是老李，被拉起来救火。第一反应：是不是代码在并发下把库存扣成了负数？翻出核心逻辑，发现是典型的 find → Java 修改 → save：先按 id 查出商品文档，拿到 stock，减去 1，再保存回去。这个流程在压测下必然出问题。

《Spring Mongo实战》第8招 更新别总save

高并发下 find → Java 修改 → save 的读改写模式会造成丢失更新。本文详解如何用 $inc、$set、$push、$pull、upsert、fi

架构师

数据库

后端

编程语言

针对高并发读改写导致的库存超卖、计数丢失等更新覆盖问题，文章详解MongoDB单文档原子更新机制，介绍使用inc、set、push等Update DSL操作符及findAndModify方法替代低效的“读取-修改-保存”流程，并通过实战案例展示其在库存扣减、浏览量统计等场景的并发安全优势，助你彻底解决并发下数据不一致隐患。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

针对高并发读改写导致的库存超卖、计数丢失等更新覆盖问题，文章详解MongoDB单文档原子更新机制，介绍使用inc、set、push等Update DSL操作符及findAndModify方法替代低效的“读取-修改-保存”流程，并通过实战案例展示其在库存扣减、浏览量统计等场景的并发安全优势，助你彻底解决并发下数据不一致隐...

《Spring Mongo实战》第8招 更新别总save-腾讯云开发者社区-腾讯云

《Spring Mongo实战》第8招更新别总save

《Spring Mongo实战》第8招更新别总save

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Mongo实战》第8招 更新别总save

《Spring Mongo实战》第8招 更新别总save

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Mongo实战》第8招更新别总save

《Spring Mongo实战》第8招更新别总save