不能。MongoDB多文档事务在跨机房多活架构下不可靠，因config server必须单中心部署以保障元数据写入多数成功，跨机房会导致prepare/commit卡死；mongos也须与config server同机房，否则路由表过期引发事务路由失败；shard跨机房仅提升局部高可用，不扩展事务范围。
不能。MongoDB 多文档事务在跨机房多活架构下无法可靠运行，核心限制不在驱动或语法，而在 config server 和 mongos 的部署约束。
为什么跨机房部署 config server 会直接阻断事务
config server 是分片集群的元数据中枢，所有事务协调（包括 prepare/commit 日志写入）都依赖其 majority 写成功。跨机房部署后，网络抖动会导致 waiting for majority commit 持续出现，sh.status() 中 config version 停滞，新事务根本无法开启 —— 这不是超时重试能解决的问题，而是写入路径已卡死。
常见误操作包括：
- 把 3 个 config server 分别放在机房 A、B、C，认为“高可用”
- 用
w:1或缩短wtimeout强行绕过 majority 要求，结果是元数据写入失败、路由表错乱 - 在 Atlas 上选了双活模板，但没注意到免费层默认单节点，升级后仍需手动确认 config server 是否为三节点副本集
mongos 跨机房后事务请求会路由失败
mongos 每秒轮询 config server 获取最新路由表。跨机房部署时，网络延迟会让缓存过期，导致事务中对不同分片的写入被发往错误节点，报错如 FailedToSatisfyReadPreference 或 NotMasterNoSlaveOk。即使 mongos 进程本身没崩溃，事务也大概率因路由不一致而失败。
关键点：
- mongos 必须与 config server 部署在同一机房，不能靠“就近接入”来优化
- 应用层不能通过增加 mongos 实例数来实现跨机房负载均衡——这只会放大路由不一致风险
- 若必须多机房接入，应由应用网关做流量隔离（如按 user_id hash 到固定机房），而非依赖 mongos 自动分发
shard replica set 跨机房不等于事务跨机房可用
单个 shard 可以跨机房部署（比如机房 A 主 + 机房 B 从），但这只解决该 shard 内部的高可用，不扩展事务作用域。事务仍受限于：config server 单中心 + mongos 单中心 + 所有参与分片必须能实时连通 config server。
若强行让 shard 跨机房且未配置选举控制，还会引发更严重问题：
- 机房间网络分区时，两机房 secondary 各自发起选举，产生双主（split-brain），事务提交可能覆盖写入
- 未设
members[n].votes = 0导致非主中心节点参与投票，平票后选举僵持 - 未关闭
chainingAllowed: false，B 机房节点从 A 机房 secondary 同步，进一步放大延迟，使事务超时
真正容易被忽略的是：事务是否“能跑通”和“是否生产可用”是两回事。一个 session.startTransaction() 不报错，不代表后续 commitTransaction() 能在 60 秒内稳定完成。跨机房场景下，网络不确定性会直接暴露事务模型的边界——它不是功能缺陷，而是设计前提未被满足。
