### MongoDB 4.0多文档事务：你以为的事务，其实是WiredTiger的“皮肤” 先说一个技术圈容易产生的误解：MongoDB 4.0的多文档事务，并不是在存储引擎层之上“额外搭建”的逻辑层。它的本质，是深度复用WiredTiger引擎原生的多行事务能力——把WT原本对单行事务的封装粒度，从一次`updateOne`放大到整个Session内的所有操作。底层仍然是WiredTiger的快照机制和MVCC体系在驱动。 所以，理解MongoDB 4.0的事务，核心是理解WiredTiger。 ### WiredTiger的快照隔离，才是事务的真正地基 MongoDB并没有自己维护版本链或者undo log——它完全仰仗WiredTiger引擎内部的快照机制。每个事务启动时，会获取一个全局单调递增的`clusterTime`。此后，事务内所有的读操作，都基于这个时间点下已提交的数据视图。 这意味着什么？ - 事务内连续多次`find()`调用，看到的永远是同一份快照。换句话说，不会出现“不可重复读”这种让人头疼的情况。 - 不存在传统意义上的“行锁”。写冲突只会在`commitTransaction()`阶段被检测到：如果另外一个事务已经修改了同一份文档，并且它的`txnNumber`更高，那么当前事务就会抛出一个`WriteConflict`错误。 - `readConcern: "snapshot"`是事务的默认值。但请注意：普通非事务的读操作，即使显式设置了这个值，也不会绑定到事务的快照——它只对事务内的操作生效。 ### 为什么startTransaction()没有返回值？ 这个问题很多开发者都问过。`startTransaction()`本质上只是一个配置会话状态的步骤——它设置的是`writeConcern`、`readConcern`、超时参数等。真正底层WT事务的生命周期，其实绑定在`session`对象上：从`startSession()`创建时开始，到`commitTransaction()`或`abortTransaction()`结束。整个过程对应WiredTiger层一个`WT_SESSION`的write unit。 这个设计带来几个直接影响： - 一个`session`不能并发同时执行多个事务。如果尝试，会报`IllegalOperation`。 - 事务内所有的CRUD操作，必须传入同一个`session`参数，否则不会被纳入事务上下文。 - 驱动中看到的`with_transaction()`，本质上只是语法糖。背后仍然是显式的`session.start_transaction()` + `session.commit_transaction()`。 ### oplog写入的时机，以及那个容易踩的持久性陷阱 这里有个关键点容易被忽略：事务提交成功，不等于oplog已经落盘。 WiredTiger的处理方式是，先把变更写入内存，打上`clusterTime`标记，然后`commitTransaction()`返回成功。但oplog的刷盘，是异步的。 这个设计导致了两个关键事实： - 如果服务端崩溃，而此时oplog尚未刷盘，那么已经被客户端确认提交的事务，可能就丢了——这直接违反了Durability（持久性）保证。所以，生产环境必须启用`journal: true`，并且把`transactionLifetimeLimitSeconds`配置得足够小（建议不超过30秒）。 - 客户端收到`commitTransaction()`的成功响应后，还需要检查返回的`ok: 1`和`operationTime`，而不能仅仅依赖异常捕获来判断结果。如果客户端超时，服务端会自动执行abort，但客户端未必能收到明确的报错信息。 - oplog条目本身不包含“事务边界”这类元信息。复制链路靠的是`applyOps`命令做批量重放。在分片集群中，跨分片的事务无法通过这种机制协调——这也是MongoDB 4.0不支持跨分片事务的根本原因。 最后再说一个容易被忽略的细节：事务快照的可见性窗口和oplog异步刷盘延迟之间，存在一个时间差。在极端情况下，比如网络分区或节点故障时，有可能短暂观察到“已提交又消失”的幻读现象。这不是Bug，而是快照隔离机制与异步日志系统之间固有的trade-off。