MongoDB 4.0 仅支持单副本集内多文档ACID事务，不支持跨分片、跨集群或standalone模式；事务须通过客户端会话显式启动，受60秒默认超时、写冲突需手动重试等限制；4.2扩展支持分片集群事务，但需启用两阶段提交、WiredTiger引擎及config server协调，带来性能下降与运维复杂度提升，官方仍建议优先通过应用层设计规避分布式事务。
副本集事务在 MongoDB 4.0 中的限制
MongoDB 4.0 只支持单副本集（single replica set）内的多文档 ACID 事务，不能跨分片、不能跨集群、也不能在 standalone 模式下开启。事务必须显式启动，且生命周期严格绑定到一个客户端会话（session）——没有 session 就无法开启事务。
常见错误现象包括：Transaction numbers are only allowed on a replica set（启动事务时没在副本集）、Transaction is not supported on sharded clusters（误在分片集群上直接用 4.0 的事务 API）。
实操建议：
- 确认部署模式：
rs.status()必须返回至少 3 个成员（含 primary），且isMaster中hosts字段非空 - 事务必须使用
startTransaction()显式开启，且所有操作需通过该 session 的db.collection实例执行，不能混用普通 collection 对象 - 最大执行时间默认 60 秒（
transactionLifetimeLimitSeconds），超时自动 abort；可通过maxTimeMS单独控制单条操作时限，但不延长事务总时长 - 写冲突时（如并发修改同一文档），事务会抛出
WriteConflict错误，需应用层捕获并重试，MongoDB 不自动重试
MongoDB 4.2 引入分片集群事务的条件与代价
4.2 在 4.0 基础上扩展了事务边界：支持跨分片（sharded cluster）的多文档事务，但前提是整个集群启用「两阶段提交（2PC）」协调机制，并依赖 config server 的 config.transactions 集合记录事务状态。
这不是简单升级就能开的功能。它对架构和运维带来明确约束：
- 必须使用 WiredTiger 存储引擎（MMAPv1 已被完全弃用）
- 所有 shard 和 config server 必须运行 4.2+，且
featureCompatibilityVersion设为"4.2"（升级后需手动执行db.adminCommand({setFeatureCompatibilityVersion: "4.2"})） - 事务涉及的每个分片都必须能与 config server 通信；若 config server 不可用，新事务无法开启，进行中的事务可能卡在 prepare 状态
- 性能开销明显：跨分片事务需额外网络往返 + 日志同步 + 2PC 协调，吞吐通常比副本集事务低 30%~50%，尤其在高并发写场景
从 4.0 到 4.2：事务 API 表面兼容，底层行为已变
session.startTransaction()、session.commitTransaction()、session.abortTransaction() 这些函数签名没变，但语义和失败路径有关键差异。
例如，在 4.0 中 commitTransaction() 失败只可能是网络中断或节点宕机；到了 4.2，还可能因某个 shard 提交失败导致整体回滚，此时你收到的是 UnknownTransactionCommitResult，而非明确的 success/fail —— 这意味着你得查 config.transactions 或重试 commit，不能假设“没返回就是成功”。
另一个易忽略点：readConcern: "snapshot" 在 4.0 中仅用于事务内读，4.2 中它成为跨分片事务的强制要求（否则报错 Snapshot reads are not supported on sharded clusters），且 snapshot 时间戳由 config server 统一分配，不再是本地 oplog 时间。
分布式事务不是万能解药，多数业务仍应规避
即便 4.2 支持分片事务，MongoDB 官方文档仍明确建议：优先用应用层设计规避跨文档强一致性需求，比如用嵌套文档、事件溯源、最终一致性补偿等方案。
原因很实际：
- 事务期间持有的锁（尤其是跨分片时）会阻塞其他写请求，容易引发级联延迟
- 事务日志（
config.transactions）持续增长，若大量短事务频繁提交，config server 可能成为瓶颈 - 备份恢复复杂度上升：物理备份需确保 config server 和所有 shard 状态一致，逻辑导出（
mongodump）默认不包含事务元数据 - 监控困难：没有内置视图暴露“当前活跃跨分片事务数”，只能靠
currentOp过滤，且字段含义随版本变化（如 4.2 新增twoPhaseCommitCoordinator字段）
真正需要分布式事务的场景极少：金融类实时清结算、库存与订单强扣减耦合、审计日志与主业务必须原子落库。其余情况，宁可拆成幂等步骤，也别把事务当银弹用。
