分片集群跨分片事务无真正强原子性，所谓“原子提交”仅为协调器确认各分片本地事务完成，并不保证故障下全部回滚或全局时序一致；其本质是超时即中止的尽力而为模型，非标准两阶段提交。
分片集群中跨分片事务没有真正强原子性，所谓“原子提交”只是协调器确认各分片本地事务完成，并不保证故障下全部回滚或全局时序一致。
分片事务不是标准2PC，而是“尽力而为”的协调模型
MongoDB 4.2+ 声称使用两阶段提交（2PC），但实际实现与传统关系型数据库的2PC有本质区别：它不持久化 prepare 阶段状态到磁盘，也不在 commit 阶段强制所有分片同步阻塞等待。协调器（mongos）只检查各分片是否返回“准备就绪”，一旦超时或某分片失联，就放弃协调，已提交的分片变更不会自动回滚。
-
transactionLifetimeLimitSeconds默认 60 秒，超时即中止，不重试 - 任意分片所在 replica set 含
arbiter节点 → 事务直接失败，报错CannotSatisfyWriteConcern - 网络分区时，部分分片可能完成写入，其余分片未收到 commit 指令 → 数据不一致
单分片事务是真正 ACID，跨分片只是“伪原子”
事务在单一分片内由 WiredTiger 引擎保障原子性：靠 WAL 日志 + 事务 ID + snapshot isolation。但跨分片时，每个分片各自维护独立的事务上下文和 oplog，mongos 不同步各分片的逻辑时间戳，也不对齐 commitTimestamp。
- 读取使用
readConcern: "snapshot"时，必须显式调用startTransaction并指定readTimestamp，否则可能读到其他事务中间态 - 即使所有分片都返回成功，外部
readConcern: "local"查询仍可能只看到部分写入结果（如 shardA 已可见，shardB 还在 apply queue 中） - 分片键设计不当（如哈希分片 + 非
_id片键）可能导致本应同路由的文档被误发到不同分片，触发跨分片事务 → 原子性保障进一步降级
备份和恢复时事务一致性完全不可靠
mongodump --oplog 对副本集有效，但在分片集群中无法保证逻辑时间点一致：每个分片的 oplog 是独立推进的，主节点切换、网络延迟、写入抖动都会导致时间偏移。
- 同时对所有分片执行
mongodump --oplog，得到的快照大概率不是同一事务视图 - 恢复后常见现象：
orders集合在 shardA 中存在，inventory在 shardB 中已被扣减，但备份点不匹配 → 出现“订单有、库存没扣”或反之 - 唯一较稳妥方式是停写 +
sh.stopBalancer()+ 文件系统快照（LVM/ZFS），但业务中断成本高
真正容易被忽略的是：事务成功返回 commitTransaction 响应，不代表所有分片上的变更已对外可见或已持久化到磁盘；它只代表协调器收到了各分片的“我搞定了”信号。而这个信号本身，在网络异常或节点重启后可能根本没抵达客户端。
