MongoDB 4.2 分布式事务慢，高并发写易卡顿；因基于两阶段提交并全程持文档锁，prepare 阶段耗时常超60%，commit失败回滚成本高；优化需缩短事务、避免跨分片、拆分为最终一致，并调优journal压缩与监控P95/P99延迟。
MongoDB 4.2 的分布式事务到底慢不慢？
慢，而且在高并发写场景下会明显卡顿。MongoDB 4.2 是首个支持跨分片事务的版本，但底层仍基于两阶段提交（2PC），所有参与节点必须全程持有文档级锁（writeLock），直到 commitTransaction 或 abortTransaction 返回。这意味着：一个事务里更新 3 个分片上的文档，这 3 个文档在整个事务生命周期内都会被锁住，其他事务无法修改——哪怕只是读也要等（因为默认隔离级别是 snapshot，需保证一致性视图）。
实测常见瓶颈点：prepare 阶段耗时占比常超 60%，尤其当网络 RTT > 15ms 或某个分片响应延迟抖动时，整个事务会被拖慢；commit 阶段失败后回滚成本高，且可能残留 transaction table 条目，影响后续元数据操作。
怎么绕过或减轻 2PC 锁冲突？
不能跳过 2PC，但可以减少它被触发的频率和范围。核心思路是：让事务尽可能短、小、本地化。
- 优先用单文档原子操作替代多文档事务：比如把
$inc+$set合并在一条updateOne里，而不是先查再改再存 - 避免跨分片事务：检查
shard key设计是否导致相关数据散落在不同分片。例如订单和订单项共用order_id作 shard key，并确保它们写入同一分片（通过zone或合理shard key选择） - 把长流程拆成“最终一致”步骤：比如支付成功后只写本地订单状态为
pending，再由异步 job 调用库存服务扣减——用消息队列+幂等接口兜底，而非强一致事务 - 调大
transactionLifetimeLimitSeconds（默认 60 秒）要谨慎：延长超时只会让锁持有更久，反而加剧冲突；真需要长流程，应改用 Saga 模式
哪些配置能压测出真实性能拐点？
别只看平均延迟，重点监控 prepare 和 commit 的 P95/P99 分位耗时，以及 storage.journal.commits 和 metrics.recordReplOplog 是否突增——这说明日志刷盘或 oplog 同步成了瓶颈。
关键可调参数：
-
enableSharding必须为true，且所有分片和 config server 均运行在 WiredTiger 引擎上（MMAPv1 不支持事务） -
replication.enableMajorityReadConcern必须开启，否则snapshot隔离不可用，事务会退化为local级别（但实际中极少这么做） -
storage.wiredTiger.engineConfig.journalCompressor建议设为snappy（而非none），压缩 journal 可降低磁盘 I/O 压力，对 prepare 阶段有 8–12% 延迟改善
压测时务必使用真实分片拓扑（至少 2 分片 + 1 config server），单机模拟分片环境的结果完全失真。
为什么你写的事务日志看起来没报错，但性能还是差？
因为 MongoDB 4.2 的事务日志（system.transactions 集合）只记录已提交/中止的事务元数据，不记录锁等待或 prepare 超时。真正卡住你的，往往是隐式锁竞争：
- 同一个分片上多个事务同时修改不同文档，但这些文档物理位置靠近（WiredTiger page 级锁），引发间接争用
-
findAndModify类操作在事务中会升级为文档锁 + 索引键锁，若索引键分布密集（如时间戳前缀），极易形成热点 - 事务中混用
readConcern: "majority"和非事务性读操作，导致 read concern 等待与 write concern 冲突，放大延迟
查这类问题得看 db.currentOp({ "secs_running": { "$gt": 2 } }) 输出里的 waitingForLock 和 numYields 字段，而不是只盯 db.adminCommand({ "serverStatus": 1 }).transactions。
