MongoDB事务对网络延迟极其敏感，根本原因在于两阶段提交需多节点同步等待确认，任何跨节点通信超时都会拖慢整体完成时间；prepare/commit涉及多轮RPC，RTT超10ms即显著升高失败率，且无本地暂存机制，完全依赖网络协调。
MongoDB事务对网络延迟极其敏感，根本原因在于其两阶段提交（2PC）协议必须在多个节点间同步等待确认，任何一次跨节点通信超时都会直接拖慢整个事务完成时间。 单次事务涉及 prepare、commit 或 abort 多轮 RPC，哪怕平均 RTT 只有 3ms，高并发下 P99 延迟也可能被放大到 50ms+；若 RTT 超过 10ms（比如跨可用区），事务失败率会显著上升。
为什么事务比普通读写更怕网络抖动
普通查询或单文档写入失败可快速重试或降级，而事务一旦进入 prepare 阶段，就必须等所有参与者响应——中间任意一个 shard、config server 或副本集成员的网络延迟，都会让整个事务卡住。WiredTiger 存储引擎本身不缓存未提交变更，所有状态都靠网络协调维持，没有“本地暂存”余地。
- 事务日志（oplog）写入需多数派确认，网络延迟高 → 多数派达成慢 →
writeConcern超时 - 跨分片事务要求
mongos协调多个 shard，每次协调都含至少两次往返（mongos→shard→mongos） - 副本集内主从同步延迟（
optimeDate差值）若因网络波动变大，会导致事务读取不到最新已提交数据（违反读已提交语义）
优化数据中心内部网速的实操重点
不是盲目升带宽，而是消除拓扑瓶颈和协议开销。云厂商标称“万兆内网”不等于 MongoDB 能用满——真实吞吐受 MTU、TCP 栈配置、NIC 中断合并策略影响极大。
- 强制使用内网 IP：在连接字符串或
mongos配置中，所有shard、config server地址必须写内网 IP，禁用域名（避免 DNS 解析拖慢prepare阶段） - 调大 TCP 缓冲区：
net.core.rmem_max和net.core.wmem_max设为 4MB（sysctl -w net.core.rmem_max=4194304），尤其对长事务批量写入有效 - 关闭 NIC offload 特性：某些虚拟网卡的
gro（Generic Receive Offload）在高并发小包场景下反而引入延迟，用ethtool -K eth0 gro off关闭后实测 P95 延迟下降 12–18% - 确认 MTU 一致：所有节点（mongos/shard/config）设相同 MTU（建议 9000），避免分片传输中因路径 MTU 发现失败导致重传
如何验证网速优化是否真正起效
别只看 ping，要测真实 MongoDB 协议层延迟。用 mongosh 连接后执行：
db.runCommand({ ping: 1, maxTimeMS: 10 })
这个命令走的是真实 MongoDB wire protocol，返回的 ok: 1 时间才是事务协调链路的真实 RTT。连续跑 100 次，看 P99 是否稳定在 3ms 内。若仍高于 5ms，问题大概率不在带宽，而在交换机队列深度或宿主机 CPU 中断负载——这时候该查 cat /proc/interrupts 看网卡中断是否集中在单个 CPU 核上。
最容易被忽略的是：事务性能瓶颈往往藏在 config server 上。哪怕 mongos 和 shard 都在同一可用区，如果 config server 部署在另一个可用区，每次事务元数据读取都会多出一次跨区延迟。务必把 config server 副本集三个节点全部放在与 mongos 同一可用区。
