MongoDB事务：跨铺转账的“对账手册”

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

事务基础概念：一张票据，一笔记录

陈掌柜当年在账本上记录银两进出，就是一行字。笔墨落纸，这行字要么清清楚楚，要么根本没写，绝不可能出现“笔画写了一半”的账目。这就是钱庄的童子功：字要一气呵成，账才能一笔不乱。MongoDB 保存文档也是这个道理——一个文档在存储引擎中作为整体写入，单次操作要么完全生效，要么完全不生效。这个特性有一个专门的名字：单文档原子性，它是 MongoDB 一切一致性保障的地基。

可联营以后，一笔生意要同时改两本账。这时候，一行“字”就不够了，需要一套把多笔操作打包成“一单”的机制——这就是事务。事务（Transaction）把一组操作捆在一起，要么全部成功，要么像墨迹未干就被擦掉一样全部回滚。MongoDB 从 4.0 版本起正式支持多文档事务，并完整遵循 ACID：原子性（Atomicity）保证操作整体提交或回滚；一致性（Consistency）保证事务前后数据满足所有约束；隔离性（Isolation）让并发事务互不干扰；持久性（Durability）保证提交后数据不丢失。

所以陈掌柜把多笔联营账装进一个“对账单”里：要么分铺都认这一单，要么全盘抹掉。MongoDB 事务就是这张对账单，它把“多行字”变成“一单字”，保住了钱庄“落笔即成、涂改即净”的老规矩。

开发支持历程：掌柜的工具箱升级

陈掌柜的账房并不是一夜之间学会跨铺对账的。早年间联营生意少，一本总账打天下。后来联营多了，掌柜先在自家几个分号之间试行了“对账手册”；再后来分号遍布各镇，手册又升级出“总号分号统一结算”的版本；如今手册多次改版，越用越顺手。工具是慢慢换的，账房先生的胆子也是慢慢练出来的——MongoDB 对事务的支持同样是分阶段的。

2018 年 6 月，MongoDB 4.0 正式发布，首先在副本集（Replica Set）上支持多文档 ACID 事务，让单副本集内的多文档操作具备了完整的原子性与隔离性。2019 年 8 月，4.2 版本把事务扩展到分片集群（Sharded Cluster），事务可以跨越多个分片协调执行，成为真正意义上的分布式事务。此后 8.0 及更高版本持续演进：扩大事务写入大小上限、优化协调开销、完善快照和可重试写入的支持，让事务在更重的业务场景下也能落地。

这就好比掌柜的“对账手册”先是自家分号用，后来扩展成联营各号通用。手册越写越厚，但对账的底气也越来越足。MongoDB 的版本演进，正是这本手册的“修修补补”。

副本集一致性：每本账都有复本

陈掌柜最怕两件事：火灾和盗贼。账本一旦烧了，生意全完。所以他让账房先生每本总账都抄出两三份复本，分放在不同的钱匣里——这就是钱庄的“副本集”。凡是重要的入账，先在主账本上落笔，再由账房先生誊抄到各复本上。万一主账本被毁，任取一份复本就能重建账目，生意不至于断档。

MongoDB 的副本集（Replica Set）也是同样思路：由一个主节点（Primary）承担全部写入，其他从节点（Secondary）通过复制操作日志（oplog）保持同步。如果主节点故障，剩余节点会发起选举，选出一个新主节点继续服务。三个要点值得牢记：主节点写入——所有写操作（包括事务）都必须经过主节点，它唯一决定写入顺序；从节点复制——从节点异步回放 oplog，不断追赶主节点的状态；读偏好设置——默认读主节点能拿到最新数据，而设置 readPreference 为 secondary 可以分散读压力，但可能读到稍旧版本。

有了复本，掌柜再也不怕火烧账本。但他也明白：读账的人若图快去看复本，有时会看到稍微旧一点的数字——这就是“从节点读”的取舍。想要永远最新，就得多花一点代价去读主账本。

快照隔离机制：看同一版老账本

联营对账最怕账目一边对一边变。陈掌柜订了一条铁规矩：一旦开启对账，所有分铺都必须照着“开账那一刻的账本副本”核对，谁也不许看中途改动的数字。这就像读今天的晨报——哪怕下午出了增刊，你手里那份晨报的内容也不会变。看报的人从不会因为增刊而困惑，因为报纸是某个时间点的“快照”。

MongoDB 事务也遵循同样的快照隔离（Snapshot Isolation）：事务开始时，存储引擎为事务生成一个一致性快照，事务内的所有读操作都基于这个快照，而不是实时数据。其他事务的写入，在这个事务看来仿佛不存在——直到它自己提交。底层支撑来自 WiredTiger 存储引擎的多版本并发控制（MVCC）：每条记录维护多个版本，读操作按快照时间点选取对应版本；写操作之间则通过版本号检测冲突，两个事务同时改同一文档时，后提交者会收到 WriteConflict 错误，需要捕获后重试。

有了“晨报”式快照，各分铺对账时再也不用担心隔壁突然改了数。谁要改账，就等这一单对完再改——改早了就会撞上“写冲突”这堵墙，无功而返。

两阶段提交：发函确认与统一落账

跨铺转账最难的不是算数，而是协同。陈掌柜的解法是“先问后写”：第一步，掌柜给涉及的每家分铺发一封确认函，写明“明日开市，布庄减银三百，粮行加银三百，贵号能否办妥？”各分铺收到后认真验账，回函“可办”或“不可办”。如果所有分铺都回“可办”，掌柜才发第二封函：“约定已定，即刻落账！”所有分铺同时下笔。但凡有一家回“不可办”，所有回函作废，一切恢复原样——这就是两阶段提交的雏形。

MongoDB 的分布式事务协调者正是这么做的。整个流程分为两个阶段：准备阶段（prepare），协调者向所有参与节点发送准备请求，各节点执行写操作并持有锁，但不提交，回复“已准备”或“不能准备”；提交阶段（commit），若全部回复“已准备”，协调者广播提交指令，各节点正式提交；否则广播中止指令，所有节点回滚。协调者（Coordinator）是核心角色：它记录事务状态，决定提交或中止，并且会把状态写入事务集合持久化，防止协调者自身崩溃后丢失决定。

陈掌柜这套“先问后写”的规矩，保证了联营各号步调一致。两阶段提交的智慧正在于此：把“能不能办”和“一起办”分成两步。宁可事前多问一句，也不要事后扯皮。

分片事务限制：跨分号的麻烦

分号开多了，麻烦也来了。陈掌柜发现，跨分号对账时，每封信都要送到不同的镇子，信使往返的脚程（网络延迟）累积起来相当可观；有的分号规矩不同，有些账目那边根本不接（功能限制）；对账时间拖久了，账本一直锁着，别的新生意都做不了（超时与锁）。跨铺对账虽好，代价却实实在在。

当 MongoDB 集群做了分片（Sharding），数据被切分到多个分片上。一旦事务涉及多个分片，每个分片都要完整参与 prepare 与 commit，协调成本随分片数量增长，网络往返、锁等待、日志同步的成本叠加起来，事务性能明显下降。分片事务的典型限制包括：性能开销——涉及分片越多，两阶段协调的往返次数越多，延迟越高；功能限制——某些聚合命令和跨分片操作受限，对分片键的查询约束也更严格；超时机制——事务默认 60 秒超时（由 transactionLifetimeLimitSeconds 控制），超时自动中止；锁等待时间过长也会快速失败，保证不会无限占用资源。

陈掌柜于是定下规矩：能在一家分号办完的事，绝不劳烦第二条街。同样的道理，能设计成单分片事务的应用，就不要让 MongoDB 为“跨分片一致”多付三倍脚程钱。

事务实践指南：掌柜的操作手册

陈掌柜把多年对账心得整理成一本《联营操作手册》。扉页写着三条训诫：一、回函没等到就重新发，别干等（重试）；二、收到“不可办”就当即作废，从头再议（错误处理）；三、对账要有专属房间，账房先生用固定桌案（会话 Session），用完马上收拾，别占着桌子（缩短事务范围）。

落到代码层面，MongoDB 事务也有同样的实践规范。第一，事务必须绑定会话（Session）：通过 client.start_session() 开启会话，再调用 session.start_transaction() 开启事务，读写操作都要显式传入 session。第二，捕获可重试错误：遇到 TransientTransactionError（如写冲突、瞬态网络故障）时，应该重试的是整个事务，而不是单个操作。第三，保持事务短小：事务内只放必要的读写，杜绝耗时的外部 API 调用，避免长期占用锁和 oplog 空间。官方驱动普遍提供 withTransaction 回调，内部自动处理瞬态错误重试，开发者只需把业务操作封装进回调。

手册的道理朴素：“别干等、早作废、快收拾。”现代数据库事务也一样——代码写得越短平快，重试得越果断，系统就越稳。

设计原则权衡：能一笔记清就别啰嗦

陈掌柜的祖师爷留下一句训话：“能在一页账上记清的事，绝不牵连第二本账。”单行记录天然完整、修改快、不锁别人的账；一旦动用跨铺对账，就要发函、等回音、锁账本，劳师动众。账房先生们把这句话刻在算盘上，每次想开新账本前都要先问自己：这一页真装不下吗？

这条训话对应 MongoDB 的核心设计原则：优先设计单文档模型，把相关字段内嵌进同一个文档，利用单文档原子性完成大多数业务操作；只有真正需要跨文档、跨集合甚至跨库保持一致时，才引入事务。典型的单文档场景包括：订单与订单明细——把明细作为数组内嵌进订单文档，一次写完成；用户与偏好设置——同一文档承载全部资料。必须上事务的场景包括：转账（账户 A 扣款 + 账户 B 入账）、下单（订单创建 + 库存扣减 + 积分增加）等跨集合、跨文档的一致操作。反模式警示则是“为了事务而事务”——本来可以内嵌的建模被强行拆散，再靠事务拼回去，只会平添复杂度与性能损失。

陈掌柜把祖训刻在账房门楣上，也刻进了 MongoDB 的设计哲学：单文档原子性永远是最快的路，事务是备用的桥。能走桥是本事，能不走桥才是智慧。

AI 应用场景

Python 演示

from pymongo import MongoClient client = MongoClient("mongodb://localhost:27017")db = client["bank"]accounts = db["accounts"]  def transfer(sender, receiver, amount):    with client.start_session() as session:        with session.start_transaction():            sender_doc = accounts.find_one({"_id": sender}, session=session)            if not sender_doc or sender_doc["balance"] < amount:                raise ValueError("insufficient balance")            accounts.update_one(                {"_id": sender},                {"$inc": {"balance": -amount}},                session=session            )            accounts.update_one(                {"_id": receiver},                {"$inc": {"balance": amount}},                session=session            )  if __name__ == "__main__":    accounts.delete_many({})    accounts.insert_many([        {"_id": "alice", "balance": 1000},        {"_id": "bob", "balance": 500}    ])     transfer("alice", "bob", 200)    print("normal:", [(a["_id"], a["balance"]) for a in accounts.find()])     try:        transfer("alice", "bob", 99999)    except ValueError as exc:        print("rollback demo:", exc)    print("after rollback:", [(a["_id"], a["balance"]) for a in accounts.find()])

1. with client.start_session() as session:开启会话，事务必须绑定会话，如同掌柜为对账单分配专属房间
2. with session.start_transaction():在会话内开启事务，之后的读写都在“同一张对账单”里
3. accounts.find_one({"_id": sender}, session=session)事务内的读必须传入 session，才能读取事务快照，看到开账那一刻的余额
4. {"$inc": {"balance": -amount}}原子自减操作，配合事务保证扣款与入账同生共死
5. raise ValueError("insufficient balance")抛出业务异常，触发 with 块自动回滚，相当于掌柜喊了一声“作废！”

常见误区

面试题