M10是MongoDB Atlas事务支持的最低层级，因仅此及以上副本集默认启用完整WiredTiger缓存策略与稳定锁管理；低于该层级（如免费/Flex集群）不支持事务，调用startTransaction会直接报错。
MongoDB Atlas 中的事务支持与集群层级强绑定，M10 及以上副本集、M30 及以上分片集群才完整支持多文档 ACID 事务；低于此层级（如免费集群、Flex 集群）**不支持事务**，调用 session.startTransaction() 会直接报错 CommandNotSupported 或 NotImplemented。
为什么 M10 是事务支持的最低门槛
MongoDB 从 4.0 开始在副本集上支持多文档事务，但 Atlas 将该能力与硬件资源和 WiredTiger 引擎配置深度耦合：
- M10 是 Atlas 中首个默认启用完整 WiredTiger 缓存策略（25% RAM 分配给缓存）且保障稳定锁管理器行为的层级，这对事务的 snapshot isolation 和写冲突检测至关重要
- 免费集群和 Flex 集群运行在共享、不可控的底层宿主上，无法保证事务所需的锁持有时间、oplog 写入延迟和 session 状态一致性
- Atlas 后台会主动拒绝在不支持事务的集群上解析包含
startTransaction、commitTransaction的命令，而非让其进入执行阶段再失败
选择 M30+ 专用集群才能用分片事务
如果你的应用需要跨分片事务（例如涉及两个不同分片上的集合），仅 M10/M20 不够——必须使用 M30 或更高层级的专用集群，并部署为分片集群：
-
sharded部署模式是前提，M10/M20 仅支持副本集，不提供分片协调器（mongos）和 config server 的事务元数据同步能力 - 所有分片必须统一为 ≥M30 层级；若混用 M20 和 M40，事务会因分片间 oplog 截断点（oplog hole）不一致而回滚
- 分片事务要求
readConcern: "snapshot"和writeConcern: "majority"，M30+ 才保障 majority 写入的亚秒级确认延迟
自动伸缩对事务稳定性的影响
开启集群层自动伸缩（Cluster Tier Scaling）时，事务可能被意外中断：
- 当 Atlas 在事务进行中将集群从 M40 降级到 M30，节点内存骤减会导致 WiredTiger 缓存抖动，触发隐式
abortTransaction - 升级过程虽通常无感，但若发生在长事务（>60s）期间，新旧 mongod 进程切换可能导致 session state 丢失
- 生产环境强烈建议：对启用了事务的关键集群，禁用
Cluster Tier Scaling，仅保留Storage Scaling（它不影响内存或 CPU）
容易被忽略的驱动层配置
即使集群满足层级要求，Node.js、Python 等驱动仍需显式启用事务上下文：
- 必须用
client.startSession()获取 session 对象，不能直接在 collection 上调用事务方法 - 事务内所有操作必须传入该 session：
collection.insertOne(doc, { session })，漏传则变成普通非事务写入 - 超时必须手动控制：
session.startTransaction({ maxTimeMS: 30000 })，否则默认 60s 后服务端强制 abort，但客户端可能卡在等待响应
事务不是“开了就能用”的开关，而是贯穿集群选型、部署拓扑、驱动调用和监控告警的链路。M10 是底线，M30 是跨分片事务的硬性入口，而自动伸缩和驱动 session 管理这两个点，恰恰是上线后最容易出 silent failure 的地方。
