ShardingSphere 事务管理的核心概念

ShardingSphere 事务管理的核心概念文档。这部分内容为理解其事务实现奠定了理论基础，非常重要。

核心概念解析：

1. 本地事务 (Local Transaction)

   • 定义： 作用于单个物理数据库节点（即一个真实的数据源连接）上的事务。这是数据库原生支持的事务类型（如 MySQL 的 InnoDB 事务）。
   • 在 ShardingSphere 中的角色：
     • 基础单元： ShardingSphere 处理的所有分布式事务，最终都会分解为对多个物理数据库节点执行的本地事务。
     • 透明支持： 对于仅涉及单个分片的 SQL 操作，ShardingSphere 会透明地使用本地事务管理，无需额外配置。例如，查询或修改某个表时，如果其分片键指向同一个物理分片。
     • 执行单元： 在分布式事务（如 XA、Seata AT）中，每个物理分片上的操作最终都会在一个本地事务中执行（并参与两阶段提交等协议）。

2. 全局事务 (Global Transaction) / 逻辑事务 (Logic Transaction)

   • 定义： 在 ShardingSphere 的逻辑数据库层面发起的事务。它封装了一个或多个可能跨越多个物理分片的数据库操作序列。对应用程序来说，它看起来像是在操作一个单一的数据库。
   • 关键特性：
     • 统一入口： 应用程序通过标准的 JDBC Connection.setAutoCommit(false), commit(), rollback() 或者 Spring 的 @Transactional 来开启、提交或回滚一个全局事务。
     • 协调者： ShardingSphere 的事务管理器（Transaction Manager）充当全局事务的协调者。它负责：
       • 开启全局事务上下文。
       • 协调其下管理的所有分支事务（每个物理分片上的本地事务）。
       • 根据全局事务的提交或回滚指令，驱动所有分支事务完成最终提交或回滚。
     • 生命周期管理： 管理全局事务的创建、激活、挂起、恢复、提交、回滚等状态。

3. 分支事务 (Branch Transaction)

   • 定义： 全局事务在单个物理数据库节点（资源管理器 Resource Manager）上执行的操作子集。每个分支事务最终对应一个物理数据库节点上的本地事务。
   • 关键特性：
     • 执行单元： 每个需要访问特定物理分片的 SQL 操作，都会在该分片对应的资源管理器上注册并执行一个分支事务。
     • 注册与报告： 分支事务需要向全局事务协调器（Transaction Manager）注册，并在执行过程中报告其状态（准备成功/失败）。
     • 服从协调： 分支事务的最终提交或回滚由全局事务协调器根据两阶段提交（2PC）或 Saga 等协议统一决定和驱动。
     • 资源绑定： 一个分支事务绑定到一个物理数据库连接（Connection）和一个资源管理器（如 Seata 的 RM， XA 的 XAResource）。

4. 事务管理器 (Transaction Manager - TM)

   • 定义： ShardingSphere 事务功能的核心组件，负责协调和管理全局事务及其关联的分支事务。
   • 核心职责：
     • 全局事务生命周期管理： 创建、开启、提交、回滚、恢复全局事务。
     • 事务上下文管理： 在分布式环境下（尤其是跨线程、跨服务调用时），维护和传播全局事务 ID (XID) 和事务上下文信息。确保同一个全局事务内的操作能找到正确的上下文。
     • 分支事务协调：
       • XA: 作为标准的 XA Transaction Manager，驱动分支事务（XAResource）执行 xa_start, xa_end, xa_prepare, xa_commit, xa_rollback。
       • Seata AT: 与 Seata TC 交互，负责分支事务的注册、状态报告，并接收 TC 的提交/回滚指令。
       • BASE (Local Transaction Log): 协调在每个分片本地事务中写入事务日志，并触发后续的异步事件处理流程。
     • 事务恢复： 在系统故障后，扫描未完成的事务（如处于 PREPARED 状态的 XA 事务，或 INIT 状态的 BASE 事务日志），并根据协议进行最终提交或回滚，保证数据最终一致性。
   • 实现： ShardingSphere 提供了 SPI 接口 ShardingSphereTransactionManager，并为 XA、Seata AT、BASE 等不同类型的事务提供了具体实现。

5. 资源管理器 (Resource Manager - RM)

   • 定义： 负责管理单个物理数据库资源（一个数据库连接/数据源）在分支事务中行为的组件。
   • 核心职责：
     • 分支事务管理： 在特定资源上开启、结束分支事务。
     • 注册与报告： 向全局事务协调器（TM）注册分支事务，并报告分支事务的执行状态（如准备是否成功）。
     • 执行指令： 接收并执行来自 TM 的指令（如 prepare, commit, rollback）。
     • 数据快照与恢复 (AT 模式特有)： 在 Seata AT 模式下，RM 负责：
       • 拦截业务 SQL，解析语义。
       • 生成数据修改前后的镜像（UNDO LOG）。
       • 在回滚时，利用 UNDO LOG 进行数据恢复。
     • 日志写入 (BASE 模式特有)： 在本地事务表模式下，RM 负责在同一个本地事务中将业务操作和事务日志记录写入数据库。
   • 实现： 通常由 ShardingSphere 代理的数据源 (ShardingSphereDataSource) 或其管理的连接 (ShardingSphereConnection) 实现 RM 的功能。对于 Seata AT，它实现了 Seata 的 ResourceManager SPI。对于 XA，它封装了数据库的 XAResource。

6. 事务上下文 (Transaction Context)

   • 定义： 包含标识和管理一个正在进行中的全局事务所需的所有信息。它是事务状态在系统内部流转的载体。
   • 核心内容：
     • 全局事务 ID (XID)： 唯一标识一个全局事务。至关重要，用于关联所有属于该全局事务的分支事务。
     • 事务状态： 如 BEGIN, ACTIVE, COMMITTING, ROLLING_BACK, COMMITTED, ROLLED_BACK 等。
     • 分支事务列表/信息： 记录该全局事务关联了哪些分支事务及其状态。
     • 其他元数据： 如事务隔离级别、超时时间等。
   • 传播： TM 负责在事务开始时创建上下文，并在分布式调用（如跨线程、跨微服务 RPC）时，通过事务上下文传播器 (Transaction Context Propagator) 将上下文（主要是 XID）透明地传播到下游服务或线程。这是实现跨服务分布式事务（如 Seata）的关键。常见的传播方式包括通过 ThreadLocal、RPC 框架的隐式参数（如 Dubbo 的 RpcContext, Feign 的 RequestInterceptor）等。

7. 挂起事务 (Suspended Transaction)

   • 场景： 当一个全局事务（事务 A）在执行过程中，需要暂时执行一个不属于它、且需要独立事务语义的操作（操作 B）时。
   • 操作：
     1. 挂起 (Suspend)： 事务管理器 TM 将当前线程关联的事务 A 的上下文（主要是 XID）保存起来，并将其从当前线程解除绑定。此时线程不再处于事务 A 的上下文中。
     2. 执行新操作： 线程执行操作 B。操作 B 可以：
        • 在非事务状态下执行。
        • 开启一个新的、独立的全局事务（事务 C）来执行。此时线程绑定的是事务 C 的上下文。
     3. 恢复 (Resume)： 操作 B 执行完毕后，TM 将之前保存的事务 A 的上下文重新绑定回当前线程。后续操作继续在事务 A 的上下文中执行。
   • 作用： 保证操作 B 的执行不会影响事务 A 的原子性，操作 B 的成败也不会导致事务 A 回滚（反之亦然）。常用于需要在事务中执行一些记录日志、发送非关键消息等操作，而这些操作本身不应该导致主业务事务失败。
   • API： 通常通过编程式事务管理的 API 实现（如 Spring 的 TransactionSynchronizationManager.suspend() / resume()，或 ShardingSphere 自身的底层 API）。

概念间的关系图：

                  +----------------------+
                  |      Application      |  (Starts/Commits/Rollbacks)
                  +----------+-----------+
                             |
                             | (JDBC / Spring @Transactional)
                             v
                  +----------------------+
                  | Global Transaction   |  <--- Managed by ---> Transaction Manager (TM)
                  | (Logic Transaction)  |         |
                  +----------+-----------+         | (Coordinates)
                             |                     |
                             | (Dispatches to Shards)
                             v                     v
+----------------+    +------v-------+    +----------------------+
| Physical DB (A)| <--| Branch TX (A)|    |                      |
+----------------+    +------+-------+    |  Resource Manager(s) | (RM)
                             |           |  (Per DataSource)    |
+----------------+    +------v-------+    |                      |
| Physical DB (B)| <--| Branch TX (B)|    +----------------------+
+----------------+    +--------------+

学习要点总结：

1. 层次清晰： 理解 应用层 (Global TX) -> 协调层 ™ -> 资源层 (RM / Branch TX / Local TX) 的分层模型。
2. TM 是大脑： Transaction Manager 是分布式事务协调的核心，负责全局状态、分支协调和恢复。
3. RM 是执行者： Resource Manager 负责具体物理资源上的操作执行、状态报告和指令响应（包括生成 UNDO LOG 或写事务日志）。
4. XID 是纽带： 全局事务 ID (XID) 是贯穿全局事务、分支事务和事务上下文的关键标识符，其正确传播是跨服务事务的基础。
5. 本地事务是基石： 所有分布式事务模式最终都依赖于对底层物理数据库本地事务的操控（直接提交/回滚 或 通过 XA/SQL 命令控制）。
6. 上下文管理是难点： 在分布式、多线程环境下，如何正确绑定、传递和恢复事务上下文是实现透明分布式事务的关键技术点。
7. 挂起提供灵活性： 挂起/恢复机制允许在事务中嵌套执行独立的事务或非事务操作。

下一步实践建议：

1. 代码调试： 在调试模式下运行一个简单的跨分片事务（如 Seata AT 模式）。观察：
   • 全局事务何时开始（XID 生成）。
   • TM 和 RM 如何初始化。
   • 执行 SQL 时，RM 如何拦截、生成 UNDO LOG、注册分支事务。
   • 提交时，TM 如何与 Seata TC 交互，驱动各 RM 提交。
   • 回滚时，RM 如何利用 UNDO LOG 恢复数据。
2. 查看日志： 开启 ShardingSphere 和 Seata 的 DEBUG 日志，仔细跟踪事务生命周期的日志输出，印证上述概念。
3. 模拟故障： 在事务执行的不同阶段（如 prepare 之后）模拟 TM 或 RM 或网络故障，观察系统行为，理解事务恢复机制。
4. 思考传播： 如果涉及微服务，设计一个简单的跨服务调用场景，跟踪 XID 是如何通过 RPC 框架（如 Dubbo, OpenFeign）在服务间传递的。

掌握这些核心概念，将为你深入理解 ShardingSphere 的各种事务实现（XA, Seata AT, BASE）以及排查分布式事务问题打下坚实的基础。继续加油！