mongodb分布式事务prepare阶段对网络延迟零容忍，rtt超15ms即卡顿，因两阶段提交串行阻塞且无超时约束；优化应聚焦数据共片、单文档操作与最终一致性。
MongoDB分布式事务对网络延迟非常敏感，RTT超过15ms就容易触发prepare阶段卡顿，不是“容忍度问题”，而是两阶段提交协议本身的硬性约束。
prepare阶段耗时占比常超60%，根本原因在跨分片网络往返
分布式事务的prepare阶段必须等待所有参与分片返回确认，每轮RPC都包含：协调者发请求 → 分片处理并响应 → 协调者收集结果。这个过程是串行阻塞的，不是并行发完就等。
- 实测中，当任意一个分片的RTT > 15ms，prepare平均耗时会跳升2–3倍；RTT > 30ms时，P95延迟常突破500ms
- 网络抖动比均值更致命：某次prepare因单次RTT突增至80ms，直接拖慢整个事务，而maxTimeMS只约束主操作，不覆盖prepare等待时间
- mongos到各shard的连接复用率低，每次事务都可能新建TCP连接，TLS握手+DNS解析进一步放大首包延迟
transactionLifetimeLimitSeconds不是网络超时开关
这个参数只控制事务上下文在内存中存续多久（默认60秒），它不监控、不中断、不重试任何网络请求。即使网络断开、shard失联，事务状态卡在starting也不计入计时——所以调大它解决不了RTT高导致的卡顿。
- 真正受网络影响的是
maxTimeMS，但它只作用于协调分片上的主操作（如updateOne），对其他分片的prepare响应无约束 - 跨分片事务实际超时由最慢分片决定，且prepare失败后回滚需再次走完整2PC流程，二次网络开销更大
- 用
db.currentOp({ "secs_running": { "$gt": 2 }, "waitingForLock": true })查不到prepare卡住，因为它不算“运行中操作”，得看db.currentOp({ "secs_running": { "$gt": 2 }, "active": true })里带inProgress: "prepare"的状态
生产环境能做的三件事，比调参更有效
与其优化超时参数，不如从部署和建模上规避网络路径瓶颈：
- 把高频关联数据打到同一分片：比如订单和订单项共用
order_id作shard key，并通过zone确保它们落在同一个shard组内，避免跨分片事务 - 用单文档原子操作替代多文档事务：例如用
updateOne配合$inc和$set一次性更新库存和状态字段，而不是先find再update - 长流程改用最终一致：支付成功后只写本地
status: "pending"，再由消息队列驱动异步扣减库存，用幂等接口+重试兜底，而非强一致事务扛网络抖动
网络延迟不是配置能抹平的物理限制，MongoDB分布式事务的prepare阶段本质是同步阻塞模型，只要涉及跨机房、跨可用区部署，就必须接受它对RTT的零容忍——这不是bug，是2PC协议在CAP权衡下的必然代价。
