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>
<!-- 使用 XA 事务时，需要引入此模块 -->
<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