MongoDB事务并非都走2PC：副本集事务依赖MVCC+oplog timestamp实现原子性与快照一致性，不需2PC；仅分片集群事务因各shard自治，必须通过mongos协调并强制采用两阶段提交协议。
MongoDB事务是否都走2PC？
不是。副本集事务不走2PC，分片集群事务才强制走2PC。
副本集内所有数据都在同一组节点上，MongoDB靠WiredTiger的MVCC + oplog timestamp对齐就能保证原子性和快照一致性，无需协调多个独立数据源。而分片集群中每个shard是自治副本集，彼此无共享日志或锁机制，必须引入外部协调者（mongos）来统一决策——这就绕不开2PC。
-
db.currentOp()里看到secs_running低但客户端超时，大概率卡在prepare或commit等待，这是2PC特有的“协调延迟”，副本集事务不会出现 - 分片事务的
prepareTransaction请求会写config.transactions表，这个config server写入是副本集事务完全不存在的额外路径 - 副本集事务虽免2PC，但强制
writeConcern: "majority"且全程持文档锁，实际吞吐下降8–10倍，这点容易被误认为是2PC开销
为什么分片事务的2PC比MySQL的2PC更慢？
MongoDB分片事务的2PC不是单纯协议实现差异，而是拓扑结构和存储模型共同放大的结果。
MySQL的2PC协调redo log和binlog两个日志组件，它们同属一个进程、共享内存和磁盘IO；MongoDB的2PC要协调多个物理隔离的shard，每个shard都要完成本地prepare→config server持久化状态→mongos聚合响应→再广播commit，链路更长、失败面更多。
- 跨机房部署时，单次
prepareTransactionRTT常超40ms，而MySQL本地双日志协调基本是微秒级 - config server成为单点瓶颈：高并发下
config.transactions写入排队，metrics.recordReplOplog突增可佐证 - commit阶段必须等最慢shard返回，一个shard因GC暂停200ms，整个事务就拖慢200ms；MySQL没有这种“木桶效应”
2PC失败后，MongoDB如何清理残留？
2PC本身不负责清理，MongoDB靠后台线程+定时任务兜底，但存在窗口期和盲区。
prepare成功但commit未发出（比如mongos宕机），shard上会留下未提交事务的oplog条目和临时数据版本；此时db.currentOp()可能不显示该事务，profiler也捕获不到，只能查db.adminCommand({ listTransactions: 1 })或mongos日志grep "prepareTransaction"。
- 默认
transactionLifetimeLimitSeconds: 60，超时后由shard本地事务管理器主动abort，但abort操作本身也可能失败 - 残留事务会阻塞后续对该文档的写入（仍持writeLock），直到被清理或超时释放
- 真正难定位的是“半成功”状态：部分shard commit了，部分abort了——这违反原子性，只能靠应用层幂等补偿，MongoDB不自动修复
能绕过2PC吗？
不能跳过，但可以避免触发。
只要事务操作落在单个shard内（即所有文档命中同一shard key），mongos就降级为副本集事务处理路径，不走2PC。关键在于shard key设计是否让关联数据物理共置。
- 订单和订单项用
order_id作shard key，再配zone约束确保二者写入同一shard，就能规避跨shard事务 - 用
$lookup替代跨集合join，把多集合读操作转为单shard内聚合，减少事务必要性 - 高频更新场景优先用单文档原子操作：
updateOne({ _id }, { $inc: { balance: -100 }, $set: { updated: new Date() } })，而非先findOne再updateOne
真正的难点不在协议本身，而在你无法从driver日志直接看出当前事务走的是副本集路径还是分片2PC路径——得靠db.currentOp() + mongos日志 + shard key分布三者交叉验证。
