ShardingSphere 的事务管理-优快云博客

本文链接：https://blog.youkuaiyun.com/csdn_tom_168/article/details/149160746

ShardingSphere 的事务管理是其核心特性之一，尤其是在分布式环境下保证数据一致性至关重要。我们来深入探讨一下文档中关于事务的核心内容：

核心概念回顾

本地事务 (Local Transaction)： 针对单个物理数据库节点（一个分片）内执行的操作。ShardingSphere 默认支持并会透明处理单个分片上的事务。
分布式事务 (Distributed Transaction / XA Transaction)： 当操作跨越多个物理数据库节点（多个分片）时，需要协调这些节点上的操作，保证所有节点要么全部成功提交，要么全部失败回滚。这是 ShardingSphere 事务管理的重点和难点。
ACID： 事务的四大特性（原子性、一致性、隔离性、持久性），分布式环境下保证 ACID 更具挑战性。
柔性事务 (BASE)： 为了性能和高可用性，分布式系统中常采用最终一致性（Eventually Consistent）的事务模型（Basically Available, Soft state, Eventually consistent）。ShardingSphere 也支持这种模式（通过 Seata AT 和本地事务表）。

ShardingSphere 支持的事务类型详解

文档主要介绍了三种主要的事务类型/集成：

柔性事务 - Seata AT 模式集成
- 原理： 基于 Seata (Simple Extensible Autonomous Transaction Architecture) 的 AT (Automatic Transaction) 模式实现。这是一种无侵入的分布式事务解决方案。
- 工作机制：
  - TM (Transaction Manager)： 定义全局事务边界（@GlobalTransactional）。
  - RM (Resource Manager)： ShardingSphere 代理的数据源充当 RM，负责分支事务的注册、状态报告，以及根据 TC 的指令执行提交或回滚。
  - TC (Transaction Coordinator)： Seata Server，协调全局事务状态，驱动分支事务的提交或回滚。
  - 执行流程： 业务执行 SQL -> RM 拦截 SQL，解析语义，生成 UNDO LOG（前镜像、后镜像） -> 注册分支事务到 TC -> 报告分支状态 -> 全局事务结束时，TC 根据结果驱动所有分支提交（异步删除 UNDO LOG）或回滚（根据 UNDO LOG 恢复数据）。
- 优点： 对业务代码侵入性低（只需加注解），性能较好（大部分场景下），支持跨多种异构数据源。
- 缺点： 需要额外部署 Seata TC Server；存在全局行锁，高并发下可能成为瓶颈；读未提交隔离级别（默认）；回滚依赖 UNDO LOG 的完整性。
- 配置关键：
  - 引入 shardingsphere-transaction-seata-at 依赖。
  - 配置 seata.enabled=true 和 seata.application-id（通常与微服务应用名一致）。
  - 配置 seata.service.vgroup-mapping.${application-id}-tx-group=default (指向 TC 集群名)。
  - 配置 seata.service.grouplist (TC Server 地址列表)。
  - 在业务方法上使用 @GlobalTransactional 注解开启全局事务。
柔性事务 - 本地事务表 (Transaction Log)
- 原理： 利用数据库自身的本地事务能力。当业务操作涉及多个分片时，ShardingSphere 会为每个分片上的操作生成对应的“事务日志”记录，并将这些日志记录与业务操作放在同一个本地事务中执行。
- 工作机制：
  - 业务发起跨分片操作。
  - ShardingSphere 在每个参与的分片所在的数据库上，开启一个本地事务。
  - 在同一个本地事务内：
    - 执行实际的业务 SQL。
    - 向一个预创建的事务日志表中插入一条日志记录（记录全局事务ID-XID、分支事务状态等）。
  - 提交该本地事务。业务操作和日志记录的插入在同一个本地事务中完成，保证了强一致性。
  - 后台有一个异步作业，扫描所有分片上的事务日志表。
  - 作业根据日志状态（如 init），调用用户配置的事件通知接口（如发消息给消息队列或调用回调API）。
  - 事件消费者根据 XID 查询所有分片的日志状态，如果所有日志状态都是成功，则执行业务确认逻辑；如果有失败，则执行业务补偿逻辑。
- 优点： 实现简单，不需要额外中间件（如 Seata TC）；利用数据库本地事务保证业务操作和日志写入的强一致性；天然支持最终一致性。
- 缺点： 需要业务方自行实现并配置事件通知接口和补偿/确认逻辑；是最终一致性模型，存在延迟；需要创建额外的事务日志表；对业务有一定侵入（需要理解补偿逻辑）。
- 配置关键：
  - 引入 shardingsphere-transaction-base-seata-at (基础API) 或对应数据库的实现依赖。
  - 配置事务规则：指定事务类型为 BASE。
  - 配置提供者类型：LOCAL。
  - （可选）配置 props，如 store-db（存储日志的数据库名，默认当前逻辑库）、store-table（日志表名，默认 transaction_log）。
  - 必须实现 TransactionLogEventListener 接口并注册为 Bean，用于接收日志事件并触发后续处理（如发消息）。
  - 创建事务日志表 CREATE TABLE IF NOT EXISTS transaction_log (...)
XA 事务
- 原理： 基于 X/Open DTP 模型的标准两阶段提交 (2PC) 协议。需要一个全局的事务协调器（Transaction Manager, TM）。
- 工作机制：
  - 阶段一 (Prepare)： TM 询问所有参与的资源管理器（RM，即各个数据库分片）：“是否可以提交？” 各 RM 执行操作但不提交，锁定资源，并回复 Yes (准备好) 或 No (无法准备)。
  - 阶段二 (Commit/Rollback)：
    - 如果所有 RM 都回复 Yes，TM 发送 Commit 指令，所有 RM 正式提交事务，释放锁。
    - 如果任何一个 RM 回复 No 或超时，TM 发送 Rollback 指令，所有 RM 回滚事务，释放锁。
- 优点： 强一致性，满足 ACID；是工业标准，得到数据库广泛支持。
- 缺点： 性能较差（网络通信次数多，锁持有时间长）；存在单点故障（TM）；协调者故障可能导致数据不一致（阻塞问题）。
- ShardingSphere 实现：
  - 内嵌了一个轻量级的 TM。
  - 支持多种 XA 实现：
    - Narayana XA: 成熟的开源实现（默认）。
    - Atomikos XA: 另一个成熟的开源实现。
  - 支持配置属性（如超时时间）。
- 配置关键：
  - 引入 shardingsphere-transaction-xa 依赖。
  - 配置事务规则：指定事务类型为 XA。
  - （可选）配置提供者类型：Narayana (默认) 或 Atomikos。
  - （可选）配置对应提供者的属性（如超时时间）。
Saga 事务 (通常在柔性事务中提到，文档可能未深入)
- 概念： 一种长事务解决方案。将一个分布式事务分解为一系列本地事务。每个本地事务都有对应的补偿事务。如果事务链中某一步失败，则按相反顺序执行前面所有已成功步骤的补偿事务进行回滚。
- ShardingSphere 支持： 理论上可以通过集成 Saga 框架（如 ServiceComb Saga）来实现，但核心文档中 Seata 的 Saga 模式集成通常不是 ShardingSphere 默认事务模块的重点。Seata 本身也支持 Saga 模式。

如何选择事务类型？

特性	Seata AT (柔性)	本地事务表 (柔性)	XA (强一致)	Saga (柔性)
一致性模型	最终一致 (默认读未提交)	最终一致	强一致	最终一致
性能	较好	较好 (本地事务保证日志写入)	较差 (2PC阻塞)	取决于实现
侵入性	低 (注解)	中 (需实现补偿逻辑)	低 (API)	高 (需定义补偿)
额外组件	Seata TC Server	无 (只需DB表)	无 (内嵌TM)	Saga 协调器 (如Seata)
锁机制	全局行锁	无锁 (最终一致)	数据库锁 (时间长)	无锁 (最终一致)
适用场景	大部分微服务场景，对一致性要求可放宽	简单跨分片操作，可接受异步补偿	强一致性要求高，可接受性能损失	长流程业务，复杂补偿
复杂度	中	中 (实现补偿逻辑)	低 (配置简单)	高

学习建议与实践

动手实验：
- 分别搭建 Seata AT、本地事务表、XA 的最小化 Demo。
- 模拟跨分片操作（如转账：A分片扣款，B分片加款）。
- 观察正常提交和异常回滚（如B分片操作前手动抛异常）时，数据的变化、日志的生成、Seata TC 控制台的状态。
- 对于本地事务表，模拟事件监听和补偿逻辑的执行。
深入配置： 仔细阅读文档中关于每种事务的配置项说明，尝试调整参数（如 XA 超时时间、Seata 的通信参数、本地事务表的表名等）。
理解隔离级别： 特别注意 Seata AT 默认的读未提交隔离级别及其影响。思考在需要更高隔离级别（如读已提交）时如何处理（通常需要业务侧配合或使用其他方案）。
思考优缺点与选型： 结合你项目的具体需求（数据一致性要求、性能要求、复杂度容忍度、团队熟悉度、基础设施）反复权衡哪种事务类型最合适。没有银弹。
结合其他特性： 思考事务如何与 ShardingSphere 的分片、读写分离、数据加密、影子库等特性协同工作。
查看源码 (进阶)： 如果感兴趣，可以查看 shardingsphere-transaction-* 模块的源码，了解其如何拦截 SQL、生成 UNDO LOG、与 Seata 交互、管理 XA 连接等。

关键注意事项

混合使用： 一个应用内可以同时使用多种事务类型（如大部分用本地事务，特定跨分片业务用 Seata AT 或 XA）。需要清晰界定边界。
连接管理与上下文传递： ShardingSphere 需要确保在分布式事务上下文中，同一个线程对同一物理分片的操作使用同一个数据库连接，并且 XID 需要在调用链中正确传递（特别是在 RPC 场景下，Seata 通过拦截器自动处理）。
超时与重试： 分布式事务更容易发生超时。合理设置超时时间，并考虑幂等性和重试策略（尤其在柔性事务的补偿阶段）。
监控： 对分布式事务进行监控至关重要（Seata TC 控制台、事务日志表的记录、自定义的监控指标），以便及时发现和处理悬挂事务、失败补偿等问题。
DDL 支持： 分布式事务（特别是 XA 和某些 Seata 版本）对 DDL 语句的支持可能有限或不一致，需特别注意和测试。

继续深入学习时，建议：