4. 事务管理器：核心职责、生命周期管理与状态机模型

事务管理器（Transaction Manager）是 ControlTransaction 体系的中枢组件。它负责协调所有参与方（资源管理器、应用、恢复管理器）的行为，确保事务的原子性、一致性、隔离性和持久性。本章深入剖析事务管理器的核心职责、事务的生命周期演化以及支撑其正确运行的状态机模型。

4.1 事务管理器的核心职责

事务管理器在分布式事务与指令序列管理中承担以下五项关键职责：

职责 说明 关键操作
事务标识与注册 为每个新事务分配全局唯一的事务ID（XID），并在事务表中注册该事务的上下文信息。 生成XID、记录事务起始时间、关联参与者列表
指令序列编排 将应用提交的操作指令按事务边界组织成有序序列，确保指令在提交或回滚时按正确顺序执行。 指令入队、序列化、顺序校验
两阶段提交协调 在事务提交阶段，协调所有参与者执行两阶段提交（2PC）或优化变体（如Paxos提交），保证全局一致性。 Prepare、Commit/Rollback、超时处理
状态持久化与恢复 将事务状态变更写入持久化日志（Transaction Log），在系统崩溃后通过日志重建事务状态。 写日志、检查点、重做/撤销
并发控制与隔离 与锁管理器或MVCC引擎协作，确保并发事务之间不产生脏读、不可重复读、幻读等异常。 锁申请/释放、版本检查、隔离级别实施
职责聚焦： 事务管理器的核心在于“协调”而非“执行”。它不直接操作数据，而是通过指令序列和状态机驱动各组件协同工作。

4.2 事务生命周期管理

一个事务从创建到结束经历多个阶段，事务管理器负责在每个阶段执行对应的管理动作。下图展示了事务的完整生命周期：

事务生命周期流程图 事务生命周期管理 BEGIN ACTIVE PREPARE COMMIT ROLLBACK END 说明：事务管理器在 ACTIVE 阶段收集指令，PREPARE 阶段进行预提交检查，COMMIT/ROLLBACK 阶段完成最终持久化。

4.3 状态机模型

事务管理器内部维护一个严格的状态机，确保事务状态转换的合法性和可追溯性。状态机模型是事务正确性的数学基础，它定义了哪些状态转换是允许的，哪些是禁止的。

4.3.1 状态定义

状态 编码 含义 可执行操作
BEGIN 0x01 事务已创建，尚未执行任何指令 注册参与者、分配XID
ACTIVE 0x02 事务正在执行指令序列，可追加新指令 追加指令、读取数据、写入数据
PREPARE 0x03 事务进入预提交阶段，等待所有参与者确认 发送Prepare请求、收集投票
COMMIT 0x04 事务已提交，所有变更持久化 写Commit日志、释放资源
ROLLBACK 0x05 事务已回滚，所有变更撤销 写Rollback日志、撤销指令
END 0x06 事务生命周期结束，清理上下文 释放XID、清理事务表

4.3.2 状态转换规则

状态机模型定义了以下合法转换路径，任何非法转换都会被事务管理器拒绝并触发异常：

  • BEGIN → ACTIVE：事务初始化完成后立即进入活动状态。
  • ACTIVE → ACTIVE：允许在活动状态内持续追加指令（自循环）。
  • ACTIVE → PREPARE：应用发起提交请求时，事务管理器将状态切换为预提交。
  • ACTIVE → ROLLBACK：应用发起回滚请求或发生错误时，直接进入回滚状态。
  • PREPARE → COMMIT：所有参与者投票通过（Yes），进入提交状态。
  • PREPARE → ROLLBACK：任一参与者投票否决（No）或超时，进入回滚状态。
  • COMMIT → END：提交日志写入完成后，进入结束状态。
  • ROLLBACK → END：回滚操作完成后，进入结束状态。
状态转换约束： 不允许从 COMMIT 或 ROLLBACK 直接跳转到 ACTIVE 或 PREPARE。一旦事务进入终态（COMMIT/ROLLBACK），其状态不可逆转。这是保证事务原子性的关键。

4.3.3 状态机模型图

事务状态机模型 事务状态机模型 BEGIN ACTIVE PREPARE ROLLBACK COMMIT END 初始化 提交请求 全部同意 否决/超时 回滚请求 回滚完成 提交完成 追加指令 状态机模型确保事务状态转换的确定性：每个状态都有明确的入边和出边， 非法转换（如 ACTIVE → END）会被事务管理器拦截并抛出异常。

4.4 事务管理器内部架构

事务管理器的内部架构通常由以下模块组成，各模块协同完成上述职责：

事务管理器内部架构 事务管理器内部架构 事务管理器 状态机引擎 指令序列管理器 两阶段提交协调器 日志与恢复模块 状态机引擎：维护当前事务状态，执行状态转换校验。 指令序列管理器：组织指令执行顺序，支持回滚时逆向撤销。 两阶段提交协调器：与参与者通信，收集投票并决策。

4.5 关键实现要点

实现提示： 事务管理器的状态机应使用 有限状态机（FSM） 模式实现，避免使用 if-else 链。推荐使用状态表驱动或状态模式（State Pattern），便于扩展和维护。

以下是一个简化的状态机核心代码示例，展示如何用状态表驱动事务状态转换：

// 状态转换表：state_transition[当前状态][事件] = 下一状态
// 非法转换返回 -1
int state_transition[6][4] = {
    // 事件: BEGIN_READY, COMMIT_REQ, ROLLBACK_REQ, VOTE_DECISION
    { ACTIVE,      -1,          -1,            -1           },  // BEGIN
    { -1,          PREPARE,     ROLLBACK,      -1           },  // ACTIVE
    { -1,          -1,          ROLLBACK,      COMMIT       },  // PREPARE
    { -1,          -1,          -1,            -1           },  // COMMIT (终态)
    { -1,          -1,          -1,            -1           },  // ROLLBACK (终态)
    { -1,          -1,          -1,            -1           }   // END (终态)
};

int next_state = state_transition[current_state][event];
if (next_state == -1) {
    // 抛出非法状态转换异常
    throw IllegalStateTransitionException(current_state, event);
}
// 执行状态切换
current_state = next_state;

4.6 事务管理器与指令序列的交互

事务管理器与指令序列管理器的交互遵循以下协议：

  1. 指令追加：在 ACTIVE 状态下，应用每提交一条指令，事务管理器将其追加到当前事务的指令序列尾部。
  2. 序列冻结：当状态切换到 PREPARE 时，指令序列管理器冻结当前序列，禁止追加新指令。
  3. 序列提交：在 COMMIT 状态下，指令序列管理器将序列标记为“已提交”，并通知资源管理器执行持久化。
  4. 序列回滚：在 ROLLBACK 状态下，指令序列管理器逆向遍历序列，逐条执行撤销操作。
关键设计原则： 指令序列的提交和回滚操作必须是幂等的。事务管理器在崩溃恢复时可能重放这些操作，幂等性保证即使重复执行也不会破坏数据一致性。

4.7 本章小结

事务管理器是 ControlTransaction 体系的核心协调者，其核心职责涵盖事务标识、指令编排、两阶段提交协调、状态持久化与并发控制。事务生命周期从 BEGIN 到 END 经历 ACTIVE、PREPARE、COMMIT/ROLLBACK 等关键阶段，每个阶段由严格的状态机模型驱动。状态机模型确保了状态转换的合法性和可追溯性，是事务原子性和一致性的数学基础。事务管理器内部的状态机引擎、指令序列管理器、两阶段提交协调器和日志恢复模块协同工作，共同支撑起分布式事务的正确执行。

← 上一章 📖 返回目录 下一章 →