MongoDB分片事务在网络抖动时不保证原子性：mongos协调器超时（默认60秒）即中止，已提交分片不回滚，导致部分写入；其非标准2PC实现不持久化prepare状态、无全局时钟对齐，故无法恢复续执行，必须依赖应用层幂等补偿。
MongoDB分片事务在遇到网络抖动时，**不保证原子性**——它会直接中止事务，已提交的分片变更不会回滚，数据可能处于部分写入状态。
网络抖动触发 TransactionAborted 或超时中止
mongos 作为协调器，依赖各分片在 transactionLifetimeLimitSeconds（默认 60 秒）内返回“准备就绪”响应。一旦某分片因网络抖动延迟响应或连接中断：
- mongos 不等待，立即放弃协调，向客户端返回
TransactionAborted错误 - 已成功执行
commitTransaction的分片，其变更已写入 oplog 并对读可见（取决于readConcern），但不会被自动回滚 - 未响应的分片上，本地事务可能仍处于 prepared 状态，也可能已被后台清理线程中止（WiredTiger 不持久化 prepare 状态）
- 客户端收到错误后，无法通过重试恢复原事务上下文，
session已失效，必须新建事务重做
为什么不能像传统 2PC 那样等网络恢复再继续？
MongoDB 分片事务不是标准两阶段提交（2PC），关键差异在于：
- 不持久化
prepare阶段状态到磁盘：分片崩溃重启后，无法恢复“我已准备好但未提交”的中间态 - 不阻塞其他操作：分片在 prepare 后仍可接受新写入，导致时间戳和 oplog 位置错乱，无法安全续 commit
- 无全局时钟或逻辑时间戳对齐机制：即使网络恢复，mongos 也无法判断“shardA 的 commitTimestamp 是否早于 shardB 的 prepare 开始时间”
- arbiter 节点参与 replica set 时，事务直接失败，报错
CannotSatisfyWriteConcern，连尝试协调的机会都没有
实际开发中怎么应对抖动下的原子性丢失？
只能靠应用层补偿，没有数据库级兜底：
- 所有跨分片写操作，必须设计幂等接口 + 外部事务日志（如用单独集合记录
transfer_id、状态、各分片操作结果） - 避免在事务中混合读写不同分片的数据；若必须，
readConcern: "snapshot"必须配合显式startTransaction和readTimestamp，否则读到中间态 - 监控
shardingStatistics中的abortedTransactions和preparedTransactions指标，及时告警 - 压测时主动注入网络延迟（如用
tc netem），验证补偿逻辑是否覆盖shardA 成功 / shardB 超时这类典型分裂场景
真正容易被忽略的是：事务返回 commitTransaction 成功，只代表 mongos 收到了全部分片的确认包，不代表这些变更已同步到 secondary、已刷盘、或对外一致可见——抖动下，这个“成功”本身已是脆弱共识。
