Sharding JDBC 实战：分布式事务处理

青旅半醒 2023-09-23 16:36 114阅读 0赞

在我们使用Sharding JDBC分库分表的时候，会带来另外一个问题，就是分布式事务问题，如下图所示。用户采购商品业务，整个业务包含3个微服务：

*  **库存服务:** 扣减给定商品的库存数量。
 *  **订单服务:** 根据采购请求生成订单。
 *  **账户服务:** 用户账户金额扣减。

这三个业务操作应该属于同一个事务，但是这些数据却分配在不同的数据库上，所以没办法采用数据库的事务来保证数据一致性。

![a0d521514c350255599aaad3df2bb732.png][]

这个时候，要解决分布式事务问题，就需要引入全局事务。

### 1. 什么是全局事务呢？ ###

全局事务是一个DTP模型的事务，所谓DTP模型指的是 X/Open DTP (`X/Open Distributed Transaction Processing Reference Model`)，是 X/Open 这个组织定义的一套分布式事务的标准。

X/Open，即现在的open group，是一个独立的组织，主要负责制定各种行业技术标准。

> 官网地址：http://www.opengroup.org/

X/Open组织主要由各大知名公司或者厂商进行支持，这些组织不光遵循X/Open组织定义的行业技术标准，也参与到标准的制定。

X/Open了定义了规范和API接口，由这个厂商进行具体的实现，这个标准提出了使用二阶段提交(`2PC –Two-Phase-Commit`)来保证分布式事务的完整性。后来J2EE也遵循了X/OpenDTP规范，设计并实现了java里的分布式事务编程接口规范-JTA，如下图所示，表示一个X/Open DTP模型。

X/Open DTP模型定义了三个角色和两个协议，其中三个角色分别如下：

*  **AP（Application Program）**，表示应用程序，也可以理解成使用DTP模型的程序
 *  **RM（Resource Manager）**，资源管理器，这个资源可以是数据库， 应用程序通过资源管理器对资源进行控制，资源管理器必须实现XA定义的接口
 *  **TM（Transaction Manager）**，表示事务管理器，负责协调和管理全局事务，事务管理器控制整个全局事务，管理事务的生命周期，并且协调资源。

两个协议分别是：

**XA协议：** XA 是X/Open DTP定义的资源管理器和事务管理器之间的接口规范，TM用它来通知和协调相关RM事务的开始、结束、提交或回滚。

目前Oracle、Mysql、DB2都提供了对XA的支持；XA接口是双向的系统接口，在事务管理器(TM ) 以及多个资源管理器之间形成通信的桥梁（XA不能自动 提交）

*  https://dev.mysql.com/doc/refman/8.0/en/xa.html
 *  https://dev.mysql.com/doc/refman/8.0/en/xa-statements.html

XA协议的语法，主流的数据库都支持 XA协议，从而能够实现跨数据库事务。

XA {START|BEGIN} xid [JOIN|RESUME] --负责开启或者恢复一个事务分支，并且管理XID 到调用线程 
    XA END xid [SUSPEND [FOR MIGRATE]] --负责取消当前线程与事务分支的关联 
    XA PREPARE xid --负责询问RM 是否准备好了提交事务分支 
    XA COMMIT xid [ONE PHASE] --知RM提交事务分支 
    XA ROLLBACK xid --通知RM回滚事务分支 
    XA RECOVER [CONVERT XID]

**TX协议：** 全局事务管理器与资源管理器之间通信的接口

在分布式系统中，每一个机器节点虽然都能够明确知道自己在进行事务操作过程中的结果是成功还是失败，但却无法直接获取到其他分布式节点的操作结果。

因此当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID特性，就需要引入一个“协调者”（TM）来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点被称为AP。TM负责调度AP的行为，并最终决定这些AP是否要把事务真正进行提交到（RM）。

### 2. 2pc提交协议 ###

在X/OpenDTP模型中，一个分布式事务所涉及的SQL逻辑都执行完成，并到了（RM）要最后提交事务的关键时刻，为了避免分布式系统所固有的不可靠性导致提交事务意外失败，TM 果断决定实施两步走的方案，这个就称为二阶提交，如下图所示。另外，搜索公众号技术社区后台回复“壁纸”，获取一份惊喜礼包。

二阶段提交，是计算机网络尤其是在数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法。通常，二阶段提交协议也被认为是一种一致性协议，用来保证分布式系统数据的一致性。

目前，绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的，利用该协议能够非常方便地完成所有分布式事务AP的协调，统一决定事务的提交或回滚，从而能够有效保证分布式数据一致性，因此2pc也被广泛运用在许多分布式系统中。

### 3. XA事务存在的问题 ###

上述基于XA协议的全局事务，是属于强一致性事务，因为在全局事务中，只要有任何一个RM出现异常，都会导致全局事务回滚。同时，本地事务在Prepare阶段锁定资源时，如果有其他事务要要修改相同的数据，就必须要等待前面的事务完成，这本身是无可厚非的设计，但是由于多个RM节点是跨网络，一旦出现网络延迟，就导致该事务一直占用资源使得整体性能下降。

另外，在XA COMMIT阶段，如果其中一个RM因为网络超时没有收到数据提交的指令，会导致数据不一致，为了解决这个问题，很多开源分布式事务框架都会提供重试机制来保证数据一致性。

### 4. CAP理论 ###

说到强一致性的问题，必然要提到CAP理论。

CAP的含义：

*  C：Consistency 一致性 同一数据的多个副本是否实时相同。
 *  A：Availability 可用性 可用性：一定时间内 & 系统返回一个明确的结果 则称为该系统可用。
 *  P：Partition tolerance 分区容错性 将同一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务。

CAP理论告诉我们，在分布式系统中，C、A、P三个条件中我们最多只能选择两个。那么问题来了，究竟选择哪两个条件较为合适呢？

对于一个业务系统来说，分区容错性是必须要满足的条件。业务系统之所以使用分布式系统，主要原因有两个：

*  **提升整体性能** 当业务量猛增，单个服务器已经无法满足我们的业务需求的时候，就需要使用分布式系统，使用多个节点提供相同的功能，从而整体上提升系统的性能，这就是使用分布式系统的第一个原因。
 *  **实现分区容错性** 单一节点 或 多个节点处于相同的网络环境下，那么会存在一定的风险，万一该机房断电、该地区发生自然灾害，那么业务系统就全面瘫痪了。为了防止这一问题，采用分布式系统，将多个子系统分布在不同的地域、不同的机房中，从而保证系统高可用性。

所以我们需要根据自己的业务需求，选择采取CP还是AP。

### 5. Sharding-JDBC分布式事务支持 ###

了解了X/Open DTP模型的全局事务解决方案，就必然需要一个成熟的技术中间件来简化我们对于分布式事务的开发逻辑，而Sharding-JDBC提供了分布式事务解决方案。

Sharding-JDBC支持以下四种事务模型，实际上这些分布式事务模式都是集成开源的事务组件做的集成。

*  Atomikos事务
 *  Narayana事务
 *  Bitronix事务
 *  Seata事务

Apache ShardingSphere 默认的 XA 事务管理器为 Atomikos，下面我们通过Atomikos来配置一个分布式事务的使用模型。

5.1 Atomikos事务

Atomikos是为Java平台提供的开源的事务管理工具，它包含收费和开源两个版本，开源版本基本能满足我们的需求。

Atomikos实现了JTA/XA规范中的事务管理器(`Transaction Manager`)应该实现的相关接口。

JTA，即`Java Transaction API`，JTA允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据，JDBC驱动程序的JTA支持极大地增强了数据访问能力。

*  **TransactionManager** : 常用方法，可以开启、回滚、获取事务。`begin(),rollback()…`
 *  **XAResouce** : 资源管理，通过Session来进行事务管理。`commit(xid)…`
 *  **XID** : 每一个事务都分配一个特定的XID

**JTA是如何实现多数据源的事务管理呢?**

主要的原理是两阶段提交，以上面的请求业务为例，当整个业务完成了之后只是第一阶段提交,在第二阶段提交之前会检查其他所有事务是否已经提交，如果前面出现了错误或是没有提交，那么第二阶段就不会提交，而是直接rollback操作，这样所有的事务都会做Rollback操作。

5.2 实战

**5.2.1 项目搭建**

使用IDEA直接创建Spring boot 项目即可。

**5.2.2 依赖**

由于使用XA事务，所以除了Sharding依赖外还需要引入事务依赖。

<dependency>
        <groupId>org.apache.shardingsphere</groupId>
        <artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId>
        <version>5.0.0-alpha</version>
    </dependency>
    <dependency>
        <groupId>com.zaxxer</groupId>
        <artifactId>HikariCP</artifactId>
        <version>3.4.2</version>
    </dependency>
    <dependency>
        <groupId>org.freemarker</groupId>
        <artifactId>freemarker</artifactId>
    </dependency>
    
    <dependency>
        <groupId>org.apache.shardingsphere</groupId>
        <artifactId>shardingsphere-transaction-xa-core</artifactId>
        <version>5.0.0-alpha</version>
    </dependency>

**5.2.3 配置**

接下来就是配置相关数据库连接信息以及分片规则；

在这里主要做的是创建了两个数据源（数据源最好设置两台服务器的数据库）以及设置好了相应的分库规则。

server.port=8080
    spring.mvc.view.prefix=classpath:/templates/
    spring.mvc.view.suffix=.html
    
    spring.shardingsphere.props.sql-show=true
    spring.shardingsphere.datasource.names="ds-0,ds-1"
    spring.shardingsphere.datasource.common.type=com.zaxxer.hikari.HikariDataSource
    spring.shardingsphere.datasource.common.driver-class-name=com.mysql.jdbc.Driver
    
    spring.shardingsphere.datasource.ds-0.jdbc-url=jdbc:mysql://localhost:3306/shard01?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    spring.shardingsphere.datasource.ds-0.username=root
    spring.shardingsphere.datasource.ds-0.password=123456
    
    spring.shardingsphere.datasource.ds-1.jdbc-url=jdbc:mysql://localhost:3306/shard02?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    spring.shardingsphere.datasource.ds-1.username=root
    spring.shardingsphere.datasource.ds-1.password=123456
    
    spring.shardingsphere.rules.sharding.default-database-strategy.standard.sharding-column=user_id
    spring.shardingsphere.rules.sharding.default-database-strategy.standard.sharding-algorithm-name=database-inline
    spring.shardingsphere.rules.sharding.sharding-algorithms.database-inline.type=INLINE
    spring.shardingsphere.rules.sharding.sharding-algorithms.database-inline.props.algorithm-expression=ds-$->{user_id % 2}
    
    spring.shardingsphere.rules.sharding.tables.t_order.key-generate-strategy.column=order_id
    spring.shardingsphere.rules.sharding.tables.t_order.key-generate-strategy.key-generator-name=snowflake
    
    spring.shardingsphere.rules.sharding.key-generators.snowflake.type=SNOWFLAKE
    spring.shardingsphere.rules.sharding.key-generators.snowflake.props.worker-id=123

**5.2.4 事务一致性注解**

Sharding jdbc解决事务一致性可以直接通过`@ShardingTransactionType(TransactionType.XA)`注解实现，我们只需要在对应的方法上加上即可。

比如下图，由于我们在配置文件中是通过`user_id`进行分库的，然后我们在这里通过随机数，会根据分片规则往两个数据库中插入数据。

当i=4的时候，我们人为的制造异常，如果我们不采用全局事务的话，则之前插入的数据还会再数据库中。所以这个时候我们只需要加上`@ShardingTransactionType(TransactionType.XA)`注解即可，XA属于强一致性。

![412d5785a822c8e8ba69342c7281c7b3.png][]

### 6. 项目地址 ###

> https://gitee.com/cl1429745331/sharding-jdbc-demo

[a0d521514c350255599aaad3df2bb732.png]: https://img-blog.csdnimg.cn/img_convert/a0d521514c350255599aaad3df2bb732.png
[412d5785a822c8e8ba69342c7281c7b3.png]: https://img-blog.csdnimg.cn/img_convert/412d5785a822c8e8ba69342c7281c7b3.png