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 成功后如果 coordinator 崩溃，其他分片会卡在“prepared but not committed”的悬空状态，直到
transactionLifetimeLimitSeconds（默认 60 秒）超时才会触发自动 abort。
也就是说，整个流程从头到尾，处处都是潜在的风险点。
ACID 之中，哪一项最脆弱？
坦白讲，隔离性是最容易被打破的，而且业务层几乎难以察觉。写操作全程持有 writeLock，哪怕是读操作也需要等待锁释放（因为 snapshot 需要构建一致视图），在高并发下排队现象极为严重。事务内还不能使用 $lookup 引用其他库，也不能操作 system.* 或 config 库，否则直接报 InvalidNamespace。
还有一个常见的踩坑点：maxTimeMS 只约束 coordinator 本地的执行时间，并不覆盖网络往返和 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 保障，那才是认真负责的做法。
