MongoDB副本集事务不使用两阶段提交（2PC），而是依赖MVCC与oplog timestamp实现原子性和可串行化隔离；仅分片集群才启用2PC，其性能瓶颈源于跨网络拓扑延迟与config server单点压力，而非协议本身缺陷。
MongoDB事务在副本集场景下根本不走两阶段提交（2PC），所以谈“相比2PC的优势”本身是个伪命题——它压根没用2PC。
副本集事务不依赖2PC，靠MVCC+oplog timestamp实现原子性
很多人误以为MongoDB所有事务都走2PC，其实只有分片集群才强制启用。副本集里所有数据都在同一组节点上，WiredTiger引擎通过MVCC提供快照读，再配合oplog timestamp对齐各节点的可见性边界，就能保证多文档操作的原子性和可串行化隔离，完全不需要跨节点协调。
-
db.currentOp()里看到事务运行时间短但客户端超时？那基本不是2PC卡住，而是writeConcern: "majority"等待多数节点落盘导致的延迟 - 副本集事务全程持有文档级写锁，吞吐下降8–10倍——这常被误认为是2PC开销，其实是WiredTiger本地锁机制+强一致性保障的代价
- 开启
replication.enableMajorityReadConcern: true是必须的，否则事务会退化为local隔离级别，snapshot不可用
分片集群事务才走2PC，但它的瓶颈不在协议本身，而在拓扑结构
分片事务确实走2PC，但慢的根本原因不是协议设计落后，而是物理隔离带来的链路放大：prepare要写config.transactions表、mongos聚合响应、再广播commit，每个环节都跨网络。
- 跨机房部署时，单次
prepareTransactionRTT常超40ms；MySQL本地双日志协调基本是微秒级 -
config server成为单点瓶颈，高并发下config.transactions写入排队，metrics.recordReplOplog指标突增可佐证 - commit必须等最慢shard返回，“木桶效应”明显：一个shard因GC暂停200ms，整个事务就拖慢200ms
2PC失败后的残留事务清理存在盲区，运维成本高
MongoDB不靠2PC协议自身清理失败状态，而是依赖后台线程+定时任务兜底，但窗口期真实存在。
-
prepare成功但commit未发出（比如mongos宕机），shard上会留下未提交事务的oplog条目和临时数据版本 -
db.currentOp()可能不显示该事务，profiler也捕获不到，只能查db.adminCommand({ listTransactions: 1 })或grep mongos日志里的"prepareTransaction" - 默认
transactionLifetimeLimitSeconds: 60，超时后由shard本地事务管理器abort，但abort操作本身也可能失败，残留事务会阻塞后续对该文档的写入
真正容易被忽略的是：副本集事务虽免2PC，但writeConcern和锁机制带来的性能衰减比想象中更硬；而分片事务的2PC问题，本质是分布式系统物理隔离与强一致诉求之间的根本矛盾，调参解决不了拓扑瓶颈。
