MongoDB 4.2分布式事务：两阶段提交保证ACID跨分片一致性

MongoDB 4.2 的分布式事务能否保证 ACID？答案是肯定的，但前提条件极为苛刻，性能代价也相当显著。它依赖两阶段提交协议，所有参与分片必须全程持有文档锁，隔离级别必须设为 snapshot，写关注必须指定 { w: "majority" }。只要有一条不满足，所谓的“事务保障”便只是看上去很美罢了。

更关键的是，在 ACID 的四个特性中，隔离性是最容易出现漏洞、也最容易被忽视的。默认的 snapshot 读关注要求所有读节点都已同步 oplog 到同一时间点，一旦某个分片延迟超过 100 毫秒，系统就会悄悄退化为 local 读取——这意味着你随时可能读到未提交的中间状态，或者跳过刚提交的重要变更。这并非理论风险，而是真实场景中反复出现的问题。

两阶段提交：唯一可行的路，却也是狭窄的路

MongoDB 没有中心事务协调器，跨分片操作必须依靠一种可以收敛的分布式协议。两阶段提交（2PC）是它在缺少全局时钟和 Paxos 类共识引擎前提下，做出的最务实的选择。prepare 阶段让各分片预写日志并锁定文档，commit 阶段再统一确认生效或全部回滚。

但这里面有几个容易被忽略的细节：

• prepare 并非轻量的试探性操作——它确实在修改数据。WiredTiger 内部的事务日志已经刷盘，只是对外不可见。一旦失败，需要走完整的回滚流程，并非简单的“撤销预占”。
• 所有分片的 txnNumber 必须单调递增且对齐，否则直接抛出 TransactionTooOld 错误。logicalSessionCacheRefreshPeriodMS 默认是 5 分钟，但生产环境中强烈建议压到 30 秒以内。
• 协调者（mongos）不持久化状态。prepare 成功后如果协调者崩溃，其他分片会卡在“prepared but not committed”的悬空状态，直到 transactionLifetimeLimitSeconds（默认 60 秒）超时才会触发自动 abort。

也就是说，整个流程从开始到结束，处处都是潜在的风险点。

ACID 里面，哪一项最脆弱？

客观而言，隔离性最容易被动摇，且业务层几乎感知不到。写操作全程持有 writeLock，即便只是读也需要等待锁释放（因为 snapshot 需要构建一致视图），高并发下排队现象极其严重。事务内还不能用 $lookup 引用其他库，也不能操作 system.* 或 config 库，否则直接报 InvalidNamespace。

还有一个容易踩的坑：maxTimeMS 只约束协调者本地的执行时间，并不覆盖网络往返和 prepare 响应的延迟。实际场景里，事务 hang 住十几秒才失败，这是很常见的事。

哪些配置错误会让 ACID 名存实亡？

即使代码里老老实实写了 session.startTransaction()，遗漏以下任何一项配置，事务都会退化成一堆独立的写操作，原子性和一致性全部归零：

• 副本集没开 replication.enableMajorityReadConcern: true？——snapshot 不可用，事务直接退化为 local 隔离。
• 分片集群里还有分片在用 MMAPv1 引擎？——启动事务就报错，WiredTiger 是硬性依赖。
• 写操作没显式指定 writeConcern: { w: "majority" }？——提交后可能只写入了主节点，从节点一宕机，数据说丢就丢。
• 事务跨了数据库（比如 db1.col1 和 db2.col2）？——触发 InvalidNamespace，根本进不了 2PC 流程。

所以真正难的不是“怎么写事务”，而是判断“这笔业务到底值不值得用事务扛”。prepare 阶段耗时占比常超过 60%，一个慢查询或者一次网络抖动，就能把整个两阶段流程拖垮。别只盯着 commitTransaction() 返回的成功看——先检查一下 P99 的 prepare 延迟，再谈 ACID 保障，那才是认真负责任的做法。