3. 副本集与事务生命周期

MongoDB 的事务并不是在单个节点上“自说自话”地完成，而是嵌入在副本集复制协议之中。理解事务生命周期，必须先理解副本集如何把一次写操作从主节点传播到从节点，以及“多数派提交点”如何决定事务何时真正对外可见。本节围绕主从复制、oplog 与多数派提交点三条主线，说明事务在副本集环境中的传播与确认机制。

一、副本集复制的基本结构

一个副本集通常由多个成员组成，其中只有一个主节点（Primary）接受写操作，其余为从节点（Secondary）。主节点接收写请求后，先在本地应用写操作，同时把这次写操作记录到自己的 oplog（操作日志）中。从节点持续从主节点拉取 oplog 条目，并在本地按相同顺序重放，从而保持数据一致。oplog 是一个固定大小的 capped collection，位于 local 数据库中，它记录的是“幂等的重放指令”，而不是简单的数据快照。

复制过程可以概括为：主节点写入 → 记录 oplog → 从节点拉取并重放 → 从节点确认进度。每个从节点会向主节点报告自己已经应用到哪个 oplog 位置，这个位置就是“复制进度”。主节点据此判断多数派是否已经确认某条写入。

二、oplog 与事务的关系

事务在副本集中的传播，本质上仍然依赖 oplog。事务提交时，主节点会把事务涉及的多条写操作以特定形式写入 oplog，从节点重放这些条目后，数据状态与主节点保持一致。需要注意，事务的 oplog 条目并不是简单地把多条语句拆开，而是保留了事务边界信息，使从节点能够按事务语义重放，避免出现“部分应用”的中间状态。

oplog 的大小直接影响复制窗口。如果从节点落后太多，而主节点的 oplog 已经循环覆盖了它需要的条目，从节点就无法继续增量同步，只能进行全量初始同步。因此，在生产环境中，oplog 大小需要根据写入量和可容忍的从节点延迟来评估。一个常见的经验是：oplog 至少能覆盖业务高峰期间数小时的写入量。

三、多数派提交点与事务可见性

事务提交时，MongoDB 并不会立即认为事务“已完成”。它需要等待多数派成员确认该事务对应的 oplog 位置，这个位置就是多数派提交点。只有当提交点推进到事务的 oplog 位置之后，事务的结果才被认为已经持久化并对外可见。这就是 writeConcern: majority 的核心含义。

在事务中，读操作默认使用事务快照，写操作则受 writeConcern 控制。如果事务使用 majority 写关注，那么事务提交会等待多数派确认；如果使用 w:1，则主节点本地写入后即可返回，但此时若主节点故障，事务结果可能丢失。因此，对于资金、订单等关键业务，通常建议在事务级别设置 majority 写关注。

四、传播与确认中的关键参数

理解事务在副本集中的行为，需要关注几个参数。第一是 writeConcern，它决定事务提交需要等待多少个节点确认。第二是 readConcern，它决定事务读取的数据版本，常用取值包括 local、majority 和 snapshot。第三是 maxTimeMS，它限制事务整体执行时间，避免长时间占用资源。第四是 oplog 大小，它影响从节点能否持续增量同步。

五、一个可观察的示例

假设一个三节点副本集，主节点为 P，从节点为 S1、S2。客户端开启事务，向 orders 集合插入一条订单，并更新 inventory 集合库存。事务使用 writeConcern: majority。提交时，P 将事务写入本地 oplog，S1 和 S2 分别拉取并重放。当 P 收到 S1 和 S2 中至少一个的确认后，多数派提交点推进到该事务位置，客户端收到提交成功。此时即使 P 立即宕机，S1 或 S2 中至少有一个节点拥有该事务数据，新主节点选举后数据不会丢失。

// 事务示例（伪代码）
session.startTransaction({
  readConcern: { level: "snapshot" },
  writeConcern: { w: "majority", wtimeout: 5000 }
});

session.getDatabase("shop").orders.insertOne({
  orderId: "O2024001",
  amount: 199.00,
  status: "created"
});

session.getDatabase("shop").inventory.updateOne(
  { sku: "SKU-001" },
  { $inc: { stock: -1 } }
);

session.commitTransaction();

在这个示例中，如果 wtimeout 设置为 5000 毫秒，而多数派确认在 5 秒内未完成，提交会返回错误。此时事务可能已经写入主节点，但尚未达到多数派提交点，客户端需要根据业务逻辑决定重试或回滚。这也是事务在副本集环境中需要特别关注的异常路径。

六、常见问题与排查方向

事务在副本集中传播时，常见问题包括：从节点复制延迟过大导致提交等待超时；oplog 太小导致从节点无法增量同步；writeConcern 设置过低导致故障时数据丢失；readConcern 设置不当导致读到未提交数据。排查时，可以先查看 rs.status() 中的复制进度和延迟，再检查 oplog 窗口是否足够，最后确认事务的 writeConcern 和 readConcern 是否符合业务要求。

理解主从复制、oplog 与多数派提交点，是掌握 MongoDB 事务生命周期的关键。事务不是孤立地提交，而是在副本集复制协议中完成传播与确认。只有把这三者放在一起看，才能准确判断事务何时真正持久化、何时可能丢失，以及如何通过参数配置在性能与一致性之间取得平衡。