MongoDB事务入门到实战：隔离级别、Spring注解与分布式事务

做后端开发的，早晚要在 MongoDB 事务上栽一次跟头。这句话不是夸张，我见过太多项目一开始只用单文档操作，觉得 MongoDB 写起来很爽，等到业务要同时扣库存、创建订单、更新用户余额的时候，才发现没把事务吃透有多难受。这篇是“MongoDB入门学习教程，从入门到精通”系列里单独拎出来的事务篇，专门梳理 MongoDB 事务的知识点。无论你是刚接触 MongoDB 的新手，还是已经写过不少查询的老手，只要想搞清楚事务隔离级别、Spring 事务注解、分布式事务场景，这篇都值得花十分钟过一遍。

我会从自己实际踩过的坑出发，先讲清楚事务为什么存在、MongoDB 从哪个版本开始支持事务，再把事务里的核心概念和实操代码一步步拆开，最后集中盘一盘那些你早晚会遇到的问题。这篇文章比较长，但每段都对应一类真实场景，建议收藏后按章节对照着看。

1. 为什么需要事务：从“单文档原子性”说起

1.1 文档模型下的原子边界

MongoDB 的文档模型和关系型表不一样，一个用户、一段订单、一份配置往往是一个完整文档。单独的 insert、update、delete 在 MongoDB 里天然是原子的，这个特性会让人误以为“MongoDB 不需要事务”。

如果一个下单动作要把订单、库存、用户积分全部塞进同一个文档，那一次写入就能完成，确实不需要事务。可真实业务里，数据不会刚好都待在一个文档里。订单放在 orders 集合，库存放在 stock 集合，用户余额放在 accounts 集合，一次下单至少涉及三次写入。三次写入中间任何一次失败，数据就处于一种“中间状态”。订单创建了但库存没扣，或者钱扣了但订单没生成，这种状态一旦出现，光靠单文档原子性完全救不回来。

早期版本里，遇到这种情况只能靠业务代码自己做补偿。先写订单，再扣库存，如果库存失败就写一条补偿日志，定时任务再去对账。看起来能跑，但非常考验工程能力，而且补偿逻辑本身也可能出错。这也是为什么以前总有人说“MongoDB 在高并发订单场景不行”。其实不是数据库不行，而是当时缺少一个标准化的原子提交手段。事务出来之后，这类问题才真正从“靠代码保证”变成“靠数据库保证”。

1.2 事务能力演进：4.0 到 7.0

MongoDB 的事务不能只当成一个简单开关来用，不同版本之间的能力差异很大。我整理了一个版本对照，方便你快速判断手头环境支持到什么程度。

如果你还没装环境，建议直接装 7.x，并且一定要按副本集模式启动。我见过太多人下载 MongoDB 后默认单机模式跑起来，然后连事务测试都跑不通，报错信息大概就是“Transaction numbers are only allowed on a replica set member or mongos”。这不是事务不好用，是部署模式从一开始就错了。后面在常见问题里我会展开讲。

2. 核心概念：ACID、隔离级别与读关注/写关注

2.1 MongoDB 事务如何满足 ACID

很多人一听“MongoDB 支持事务”，下意识会拿它和 MySQL 做对比。其实 MongoDB 事务在 ACID 层面有自己的实现方式，理解对了才不会被文档里的各种名词绕晕。

先看原子性。事务里的写操作要么全部提交，要么全部回滚。这一点和关系型数据库没区别。提交后如果某个环节失败，WiredTiger 存储引擎会把事务里所有的写操作全部撤销，应用层不需要自己写反向更新。

一致性可以理解为“从一个一致状态到另一个一致状态”。MongoDB 不像 MySQL 那样有外键、唯一约束一堆强规则，它的数据一致性很大程度上依赖文档模型设计和业务代码。事务能保证的是不产生“订单写了库存没扣”这种半截状态，但最终业务规则对不对，还是要你自己用代码来兜底。

隔离性靠的是快照隔离机制。事务开始后会生成一份数据快照，事务里的读操作都基于这份快照，别人提交的新数据不会影响你当前事务看到的内容。如果两个事务同时改同一条文档，后写的一方会直接收到 WriteConflict，而不是像 MySQL 那样排队等锁。

持久性由 writeConcern 控制。提交事务时如果设置 w: majority，副本集里大多数节点都确认写入落盘后，事务才算提交成功。如果只设置 w:1，主节点写完就返回，主节点一旦故障切换，这个事务的数据可能就丢了。

我习惯把事务想象成“把先改 A 再改 B 包装进一个黑盒里”。外部的人要么看到 A 和 B 都变了，要么看到 A 和 B 都没变，不存在中间状态。而这个黑盒里的所有操作，都必须绑定在同一个会话（session）上执行。

2.2 事务隔离级别：快照隔离与并发可见性

MongoDB 并没有像 MySQL 那样把事情分成读未提交、读已提交、可重复读、串行化四个级别，它的核心隔离机制是快照隔离（snapshot）。

默认情况下，事务使用 snapshot read concern。整个事务在开始时会形成一份一致快照，之后事务内的读操作都从这份快照里取数。其他事务哪怕提交了新数据，当前事务也看不见。这个效果和 MySQL 的 REPEATABLE READ 有点接近，但底层机制完全不同。WiredTiger 依靠 MVCC 维护多版本数据，没有 MySQL 的间隙锁概念，所以不会出现 next-key lock 那种大规模锁等待。

有同学会问：“能不能让事务里读到最新已提交的数据？”这就要调整 readConcern 了。事务支持 snapshot、local、majority 等读关注级别，其中 local 可以理解为读取本地节点最新已提交的数据，效果上接近“读已提交”的变体，但我不建议普通业务乱调。默认 snapshot 已经帮我们规避了脏读、不可重复读、幻读这些麻烦问题，工程上省心很多。

用表格对比一下常见现象：

面试时如果被问“MongoDB 事务隔离级别”，你可以直接答“默认快照隔离，等价于 MySQL 的可重复读，但是靠 MVCC 快照实现，不靠锁”。这个回答比背概念更容易让面试官记住。

2.3 读关注与写关注怎么配才稳

读关注和写关注这两个词经常一起出现，但很多人分不清。

读关注（readConcern）控制的是“读到的数据是怎么样的”，影响的是隔离性和一致性。写关注（writeConcern）控制的是“写操作什么时候返回成功”，影响的是持久性和可用性。

在事务提交时，我常用的是 w: majority。理由很简单：都开事务了，通常就是为了要强一致，如果提交时只等主节点确认，主节点一挂数据就可能丢，事务的意义就打折了。如果业务确实能接受少量数据丢失来换取低延迟，可以用 w:1，但这就别抱怨为什么故障切换后少了数据。

事务开始的时候最好把 readConcern 和 writeConcern 直接定好，不要让它们散布在每条操作里。每条语句都写一遍既乱，又容易漏，而且一旦配置不一致，排查起来非常痛苦。

还有一个特别容易踩的坑：readConcern: majority 和事务特性都要求部署在副本集或分片集群上。如果你用 standalone 模式启动 MongoDB，连多数派这个概念都没有，自然无法满足要求。所以环境部署这步真的别省。

3. 实操打开事务：Shell、Spring 注解、Python 客户端

3.1 mongosh 中的完整事务流程

先不用想太复杂，直接在 MongoDB Shell（mongosh）里跑一遍事务，比任何文档都直观。下面是一个很经典的转账例子，从 A 账户扣 100 块，给 B 账户加 100 块：

javascript复制const session = db.getMongo().startSession();

session.startTransaction({
  readConcern: { level: "snapshot" },
  writeConcern: { w: "majority" }
});

try {
  const bank = session.getDatabase("bank");
  const accounts = bank.accounts;

  accounts.updateOne(
    { name: "A" },
    { $inc: { balance: -100 } },
    { session }
  );
  accounts.updateOne(
    { name: "B" },
    { $inc: { balance: 100 } },
    { session }
  );

  const a = accounts.findOne({ name: "A" }, { session });
  if (a.balance < 0) {
    throw new Error("insufficient balance");
  }

  session.commitTransaction();
  print("transaction committed");
} catch (err) {
  session.abortTransaction();
  print("transaction aborted: " + err);
}

这里最关键的一点是：事务里的每个操作都必须把 session 传进去。很多人写代码时只建了 session，但后面 updateOne 忘了传 { session }，那这个操作就不算在事务里，一旦后面出错回滚，它也滚不回去。

我在调试这个流程的时候经常加一句 print(a.balance)，用来确认事务里的读确实能看到同一个事务内还没提交的写入。这一点和 MySQL 里“当前读”的感觉不一样，但对业务判断非常有帮助。

还有一点要提醒：事务如果遇到 WriteConflict 或者 TransientTransactionError，不要只重试失败的那一条语句，而是要把整个事务从头重跑。事务是一个整体，局部重试通常没有意义。

3.2 Spring Boot 的 @Transactional 要怎么配才生效

Java 后端最常见的做法是加 @Transactional 注解。但 Spring Data MongoDB 和 JPA 不一样，光加注解不行，必须先配置事务管理器：

java复制@Configuration
public class MongoConfig {

    @Bean
    public MongoTransactionManager transactionManager(MongoDatabaseFactory factory) {
        return new MongoTransactionManager(factory);
    }
}

然后服务层方法上再加上 @Transactional。以“创建订单并扣减库存”为例：

java复制@Service
public class OrderService {

    @Autowired
    private MongoTemplate mongoTemplate;

    @Transactional
    public void createOrderAndReduceStock(Order order) {
        mongoTemplate.insert(order);

        UpdateResult result = mongoTemplate.update(Stock.class)
            .matching(where("_id").is(order.getProductId())
                .and("qty").gte(order.getQty()))
            .apply(new Update().inc("qty", -order.getQty()))
            .first();

        if (result.getModifiedCount() == 0) {
            throw new RuntimeException("库存不足");
        }
    }
}

这里有个容易踩的坑：Spring Boot 2.x 里，只要引入了 spring-boot-starter-data-mongodb，MongoTransactionManager 这个 Bean 不会自动装配，必须手动声明。如果你忘了配置，@Transactional 注解会静默失效，代码不会报错，但事务根本没有启动，一旦中间步骤失败，前面的写入也不会回滚。

还有一个 Spring 代理机制导致的经典问题：同类内部调用事务不生效。比如 OrderService 的 createOrder 方法内部调用了 this.sendMessage()，sendMessage 上也标了 @Transactional，这个内部调用不会经过 Spring 代理，注解等于白写。想让事务生效，必须从外部入口进入，或者把那个方法拆到另一个被代理的 Spring Bean 里。

另外，Spring 的 @Transactional 默认只在遇到 RuntimeException 时回滚，受检异常默认不回滚。如果业务方法里抛了业务异常但不想触发回滚，或者反过来希望受检异常也回滚，就该显式配置 rollbackFor。

3.3 Python 客户端的会话与事务

如果你用 Python 做数据脚本或中间服务，pymongo 也支持事务。核心 API 一样，关键点还是 session。先看一个转账示例：

python复制from pymongo import MongoClient

client = MongoClient(
    "mongodb://mongo1:27017,mongo2:27017,mongo3:27017/?replicaSet=rs0"
)

def transfer(from_name, to_name, amount):
    with client.start_session() as session:
        with session.start_transaction():
            accounts = client.bank.accounts
            accounts.update_one(
                {"name": from_name},
                {"$inc": {"balance": -amount}},
                session=session,
            )
            accounts.update_one(
                {"name": to_name},
                {"$inc": {"balance": amount}},
                session=session,
            )

pymongo 里，session 的上下文管理器退出时会自动提交事务，如果中途抛异常就会自动回滚。这个设计对脚本场景很友好。

需要提醒的是驱动版本。pymongo 3.9 之后才正式支持 MongoDB 4.0 的事务特性，顺手把驱动升到最新总能避免很多莫名其妙的问题。连接串也必须带 replicaSet 名称，不然驱动认为你在连接单节点，启动事务时会直接报错。

如果想让事务更健壮，可以在异常处理里判断错误标签：

python复制from pymongo.errors import OperationFailure

while True:
    try:
        with client.start_session() as session:
            with session.start_transaction():
                # 事务操作
                pass
            break  # 成功后退出重试循环
    except OperationFailure as err:
        if err.has_error_label("TransientTransactionError"):
            continue
        raise

这个重试逻辑我已经在不少生产项目里用过。遇到 WriteConflict 或者瞬时故障，整个事务重跑会比人工介入高效得多。

4. 分布式事务：从订单库存场景看事务边界

4.1 订单与库存到底该不该共用事务

分布式事务这个话题，是所有 MQ 和微服务面试里绕不开的点。我在第 3 节举了“创建订单 + 扣库存”的例子，但这里要说明一个实际判断：如果订单、库存都在同一个 MongoDB 副本集里，直接开一个事务就够了，这不算分布式事务。如果两个集合分布在同一个 MongoDB 分片集群的不同分片上，可以用分片集群事务，这算分布式事务。如果订单在你这边 MongoDB，库存是另一边 MySQL，那就是跨系统分布式事务，数据库原生事务帮不了你。

怎么判断要不要上分布式事务？我的经验是：看业务链路是否全部掌握在同一个数据源里。如果全部在一个 MongoDB 实例或集群里，优先用官方事务；如果涉及支付网关、物流系统、第三方接口，链路已经跨系统了，采用强一致事务的成本会非常高，这时候更适合用最终一致性方案。

订单库存场景就是典型：下单那一刻订单和库存最好强一致，所以可以用本地事务或分片集群事务；但如果下单后还要等第三方支付回调、等待仓库发货，你不可能把第三方系统拉进同一个事务里。支付成功和订单状态同步之间，只能通过消息队列和回调接口做最终一致。

4.2 分片集群事务的协调逻辑与硬限制

MongoDB 从 4.2 开始支持分片集群上的分布式事务。当多个分片参与同一个事务时，mongos 会作为协调者，把事务分发给涉及的分片，各分片执行本地操作后，再统一提交或回滚。对应用层来说，代码写法和副本集事务没有太大区别，底层多了一层协调开销。

看起来很方便，但硬限制必须心里有数：

• 事务默认超时时间为 60 秒，由 transactionLifetimeLimitSeconds 控制，业务里的事务必须短平快。
• 事务获取锁的默认等待时间很短，超过后直接返回 LockTimeout 或 WriteConflict。
• 单个事务的写集数据量不要太大，官方实践里不建议在事务里批处理几万条数据，压力非常大。
• 事务内不能随意创建、删除集合，也不能执行 DDL 类操作。
• 跨分片事务的性能开销远大于单分片事务。

所以分片键设计就显得至关重要。如果订单表按 user_id 分片，一个用户的所有订单、库存、支付记录尽量落在同一个分片上，那事务就能在单分片内完成，性能会好很多。如果分片键设计得不好，一个事务要跨好几个分片协调，延迟和失败概率都会上升。这里给个建议：设计分片键时，务必要把高频事务查询的维度放进去。

4.3 业务兜底：最终一致性方案

不是所有场景都该硬上事务。就拿“订单过期”这个经典问题来说，它本质上是一个状态一致性问题，但直接开着后台扫码事务去处理超时订单，很容易把数据库拖垮。

更常见的做法是：

1. 订单创建时写入过期时间 expires_at。
2. 定时任务扫描超时未支付订单，调用幂等接口关闭订单。
3. 库存释放通过消息队列或者补偿流程异步完成。
4. 支付回调里再次校验订单状态，超时订单直接拒绝支付。

这种设计牺牲了“实时强一致”，但换来了更高的吞吐量和可用性。数据库事务在订单和库存真正需要强一致的那一小步里把一致性兜住，跨系统链路用状态机和幂等操作串起来。

另外，扣库存这类操作其实有很多时候用一条原子更新就能搞定，不需要事务：

javascript复制db.stock.updateOne(
  { _id: productId, qty: { $gte: 1 } },
  { $inc: { qty: -1 } }
);

只要更新的匹配条件里带上“库存大于等于 1”，条件不满足就更新不到，返回的 modifiedCount 为 0，说明库存不足。这个操作本身是原子的，可以省掉一整个事务。我的习惯是：能用单条原子操作解决的，绝不为套事务而套事务。

5. 常见问题与排查技巧实录

5.1 事务根本启动不了的几类原因

事务启动失败的原因其实比较集中，我把最常见的几种现象列成一张速查表：

这里我要特别说一下连接串。很多时候你觉得已经连上副本集了，但代码里用的是 mongodb://localhost:27017 这种单机地址，驱动会认为你连接的是 standalone。正确做法是显式指定副本集名称，类似：

text复制mongodb://mongo1:27017,mongo2:27017,mongo3:27017/?replicaSet=rs0

本地如果只想在单机副本集模式下测试，可以用一条命令初始化副本集，比如：

bash复制mongod --replSet rs0 --dbpath /data/db --port 27017

然后进入 mongosh 执行：

javascript复制rs.initiate()

做完这两步，事务才能跑起来。很多人装 MongoDB 时没走这一步，后面所有问题都跟着来了。

5.2 锁冲突和提交超时怎么处理

事务跑起来之后，最常见的两个报错是 WriteConflict 和 LockTimeout。

WriteConflict 不一定是 bug，它就是并发写冲突的正常信号。两个事务同时改同一条文档，后写的一方被取消，应用端收到带 TransientTransactionError 标签的异常。处理方式我在前面已经说了：整个事务重试。这不是数据库坏了，而是 MongoDB 用“直接让你重试”代替了 MySQL 那种“排队等锁”。

LockTimeout 通常说明锁等待超过了默认阈值。这个阈值受 maxTransactionLockRequestTimeoutMillis 控制，默认只有 5 秒左右。如果业务里事务经常出现 LockTimeout，不要急着调大参数，先检查两件事：第一，事务里是不是做了长时间查询或者远程调用；第二，是不是有大量并发事务在争抢同一个热点文档。比如爆款商品的库存就一条文档，所有下单并发都去改它，冲突率自然高。常见的优化办法是把热点库存拆成多个子库存桶，或者把事务窗口压到最短。

排查锁问题时，我习惯在 MongoDB Shell 里开一个窗口盯着 currentOp：

javascript复制db.currentOp({ "transaction": { $exists: true } });

这个命令能列出当前正在执行的事务操作，配合 MongoDB Compass 的 Current Op 面板，很快就能定位是哪个集合、哪条文档产生了锁等待。在有锁问题的时候，不要靠猜，直接看运行中的操作比看日志要快得多。

还有一种情况是事务提交成功但客户端没收到结果，比如提交过程中节点发生了故障转移，这种叫 UnknownTransactionCommitResult。这时不能立刻判断“提交失败”然后回滚，因为事务可能已经提交成功了。正确的做法是对提交操作做幂等重试，或者主动查询事务状态确认。

5.3 面试考点：MongoDB 事务、MySQL 隔离级别对比

这个知识点在很多后端面试里都会出现，我帮你把要点整理成一张对比表：

回答“MySQL 和 MongoDB 事务有什么区别”这类问题时，可以先说两者都满足 ACID，然后重点提隔离级别实现和写冲突处理方式的不同。面试官如果继续追问“死锁如何避免”，就往“固定访问顺序、缩小事务范围、减少锁竞争”方向答。MongoDB 里更常见的不是死锁，而是高频写冲突，所以“重试”也是一个加分点。

还有一类问题像“订单过期了怎么办”，本质上是在考你“强一致”和“最终一致”的权衡。你可以先讲数据库事务可以保证订单和库存强一致，再讲订单过期后的状态机流转和定时任务补偿，最后强调幂等设计能把两者串起来。这样答既有体系，又能落到工程实践上。

最后再分享一点我的个人体会

这篇文章写到这里，我反而想多说几句自己的经验。我最早使用 MongoDB 时也踩过“事务是不是鸡肋”的坑，后来发现事务真正解决的问题是“多文档状态的一致性”。事务是数据库给的保底方案，但它不是默认方案。

根据我个人的项目经验，最稳定的组合其实是：能用单条原子更新解决的事绝不开事务；必须开事务就把事务窗口压到最短，远程调用、消息推送这些耗时操作全部挪到事务外；最后靠对账任务和幂等补偿做兜底。这样既能享受事务带来的强一致，又不会被事务的锁和超时拖垮整个链路。

最后再分享一个小技巧。调试事务时，最好开一个 MongoDB Compass 的 Current Op 面板，盯着锁和会话的变化。事务一旦卡住，这个面板会直接告诉你卡在哪个集合、哪条文档上，比自己瞎猜日志高效太多。这个技巧帮我省了不少排查时间，也分享给正在看这篇的每一个踩坑人。