mongos天然承担2PC协调角色，无需额外配置；必须通过配置文件设置transactionLifetimeLimitSeconds（30–90秒），确保config server负载可控，并为跨分片事务设计幂等与重试机制。
mongos 就是协调节点，不需要额外配置
MongoDB 分片集群中没有独立的“2PC 协调器服务”，mongos 实例天然承担协调角色。它不是靠单独部署或开启某个开关来变成协调节点，而是所有发往分片集群的事务请求——只要经过 mongos（而非直连 shard）——就自动进入两阶段提交流程。
常见误解是去 config server 或 shard 上找“协调模块”并试图配置它，其实完全没必要。真正要做的，是确保应用层只通过 mongos 发起事务，并且 mongos 本身配置合理。
必须设置 transactionLifetimeLimitSeconds，否则 prepare 阶段会卡死
分片事务的 prepare 阶段需要向所有参与 shard 发起预提交、再写入 config.transactions 表、最后等待全部响应。这个过程若无超时控制，一个网络延迟或慢 shard 就会让整个事务挂住，客户端看到的是连接超时或 TransactionTooOld 错误，但实际卡在 prepare 等待中。
-
transactionLifetimeLimitSeconds必须在mongos启动前通过配置文件设置，例如：sharding: transactionLifetimeLimitSeconds: 45
- 不能动态修改，也不能用
db.adminCommand()设置 - 值设为 30–90 秒之间，具体看业务链路实测耗时；设成 3600 是掩耳盗铃，只会让问题更难定位
- 该参数只对经
mongos的事务生效；直连 shard 的单分片事务不受限，但也失去跨文档原子性保障
config server 写入是隐式协调瓶颈，别忽略它的负载
每次分片事务进入 prepare 阶段，mongos 必须把事务元数据写入 config.transactions 集合——这是副本集事务完全不存在的路径。这个写入本身是强一致性操作（writeConcern: "majority"），一旦 config server 压力高或网络抖动，prepare 就会排队甚至失败。
排查时注意：
- 监控
config数据库的recordReplOplog指标突增，说明 config server 正在被大量事务元数据冲击 - 避免高频小事务：比如每秒发起 100 个跨分片事务，比合并为每秒 1 个批量事务更容易压垮 config server
- 不要给
config server配低规格机器；它不存业务数据，但扛着全局事务状态，IO 和 CPU 压力不低
事务失败后不会自动回滚已提交的分片，得靠应用兜底
这是最容易被忽略的现实约束：MongoDB 分片事务的 2PC 不是强一致实现。当 mongos 在 commit 阶段收到部分 shard 成功、部分失败的响应时，它不会尝试补偿或反向回滚——而是直接报错 TransactionAborted 或 NoSuchTransaction，此时你无法知道哪些分片已落库、哪些没落。
所以真正关键的不是“怎么配协调节点”，而是：
- 所有跨分片事务必须带幂等 key（如订单号），并设计可重试逻辑
- 避免在事务里混入外部调用（如 HTTP 请求、消息队列发送），否则失败后状态不可知
- 监控
db.currentOp({ "secs_running": { "$gt": 30 } })，重点看secs_running低但状态卡在prepared的操作——这往往是 config server 或最慢 shard 拖累所致
协调节点本身很轻量，真正复杂的是它暴露出来的分布式现实：没有银弹，只有权衡和兜底。
