SpringCloud Alibaba-Seata
- 1 常用事务解决方案模型
- 1.1 DTP模型
- 1.2 2PC
- 1.3 3PC
- 1.4 TCC
- 2 Seata
- 2.1 Seata术语
- 2.1 Seata AT模式
- 2.1.1 AT模式及工作流程
- 2.1.2 Seata-Server安装
- 2.1.3 集成springcloud-alibaba
- 4.2 Seata TCC模式
- 3 Seata注册中心
- 3.1 服务端注册中心配置
- 3.2 客户端注册中心配置
- 4 Seata高可用
1 常用事务解决方案模型
维基百科：https://zh.wikipedia.org/wiki/X/Open_XA
分布式事务的实现有许多种，其中较经典是由Tuxedo提出的XA分布式事务协议，XA协议包含二阶段提交（2PC）和三阶段提交（3PC）两种实现。其他还有 TCC、MQ 等最终一致性解决方案。
1.1 DTP模型
https://www.ibm.com/docs/zh/db2/10.5?topic=managers-designing-xa-compliant-transaction
X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由厂商进行具体的实现
X/Open DTP中的角色
- AP(Application Program)：应用程序，主要是定义事务边界以及那些组成事务的特定于应用程序的操作。
- RM(Resouces Manager)：资源管理器，管理一些共享资源的自治域，如提供对诸如数据库之类的共享资源的访问。譬如：数据库、文件系统等，并且提供了这些资源的访问方式。
- TM(Transaction Manager)：事务管理器，管理全局事务，协调事务的提交或者回滚，并协调故障恢复。
DTP模型里面定义了XA协议接口，TM 和 RM 通过XA接口进行双向通信, 后面SpringCloud Seata中也有这样的角色
1.2 2PC
2PC、3PC，都是基于 XA 协议的
- 方案简介
二阶段提交协议（Two-phase Commit，即2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者
在分布式系统里，每个节点都可以知晓自己操作的成功或者失败，却无法知道其他节点操作的成功或失败。当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示它们是否要把操作结果进行真正的提交或者回滚（rollback）。
二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
核心思想就是对每一个事务都采用先尝试后提交的处理方式，处理后所有的读操作都要能获得最新的数据，因此也可以将二阶段提交看作是一个强一致性算法。
- 处理流程
简单一点理解，可以把协调者节点比喻为带头大哥，参与者理解比喻为跟班小弟，带头大哥统一协调跟班小弟的任务执行。
-
阶段1：准备阶段
1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
2、各参与者执行事务操作，将undo和redo信息记入事务日志中（但不提交事务）。
3、如参与者执行成功，给协调者反馈yes，即可以提交；如执行失败，给协调者反馈no，即不可提交。 -
阶段2：提交阶段
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息；释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
接下来分两种情况分别讨论提交阶段的过程
— 情况1，当所有参与者均反馈yes，提交事务：
1、协调者向所有参与者发出正式提交事务的请求（即commit请求）。
2、参与者执行commit请求，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈ack(应答)完成的消息。
4、协调者收到所有参与者反馈的ack消息后，即完成事务提交。
— 情况2，当任何阶段1一个参与者反馈no，中断事务：
1、协调者向所有参与者发出回滚请求（即rollback请求）。
2、参与者使用阶段1中的undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈ack完成的消息。
4、协调者收到所有参与者反馈的ack消息后，即完成事务中断。
方案总结
2PC是一个强一致性的同步阻塞协议，事务执⾏过程中需要将所需资源全部锁定，也就是俗称的 刚性事务
2PC方案实现起来简单，实际项目中使用比较少，主要因为以下问题：
- 性能问题
– 所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。 - 可靠性问题
– 如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态。 - 数据一致性问题
– 在阶段2中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。
1.3 3PC
- 方案简介
三阶段提交协议，是二阶段提交协议的改进版本，与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制（2PC 中只有协调者有超时机制）。
三阶段提交将二阶段的准备阶段拆分为2个阶段，插入了一个preCommit阶段，使得原先在二阶段提交中，参与者在准备之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
- 处理流程
-
阶段1：canCommit
协调者向参与者发送canCommit请求，参与者如果可以提交就返回yes响应(参与者不执行事务操作)，否则返回no响应：
1、协调者向所有参与者发出包含事务内容的canCommit请求，询问是否可以提交事务，并等待所有参与者答复。
2、参与者收到canCommit请求后，如果认为可以执行事务操作，则反馈yes并进入预备状态，否则反馈no。 -
阶段2：preCommit
协调者根据阶段1 canCommit参与者的反应情况来决定是否可以基于事务的preCommit操作。根据响应情况，有以下两种可能。
情况1，阶段1所有参与者均反馈yes，参与者预执行事务：
1、协调者向所有参与者发出preCommit请求，进入准备阶段。
2、参与者收到preCommit请求后，执行事务操作，将undo和redo信息记入事务日志中（但不提交事务）。
3、各参与者向协调者反馈ack响应或no响应，并等待最终指令。
情况2，阶段1任何一个参与者反馈no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务:
1、协调者向所有参与者发出abort请求。
2、无论收到协调者发出的abort请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。
- 阶段3：do Commit
该阶段进行真正的事务提交，也可以分为以下两种情况：
情况1：阶段2所有参与者均反馈ack响应，执行真正的事务提交：
1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。
2、参与者收到do Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈ack完成的消息。
4、协调者收到所有参与者反馈的ack消息后，即完成事务提交。
阶段2任何一个参与者反馈no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务：
1、如果协调者处于工作状态，向所有参与者发出abort请求。
2、参与者使用阶段1中的undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈ack完成的消息。
4、协调者收到所有参与者反馈的ack消息后，即完成事务中断
注意：进入阶段3后，如果协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的do Commit请求或rollback请求。此时，参与者都会在等待超时之后，继续执行事务提交。
阶段三 只允许成功不允许失败，如果服务器宕机或者停电，因为记录的阶段二的数据，重启服务后在提交事务，所以，到了阶段三，失败了也不进行回滚。
方案总结
- 优点
– 相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。 - 缺点
– 数据不一致问题依然存在，当在参与者收到preCommit请求后等待do commite指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
1.4 TCC
方案简介
TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
TCC是服务化的二阶段编程模型，其Try、Confirm、Cancel 3个方法均由业务编码实现，基本类似两阶段提交
- Try操作作为一阶段，负责资源的检查和预留。
- Confirm操作作为二阶段提交操作，执行真正的业务。
- Cancel是预留资源的取消。
TCC事务的Try、Confirm、Cancel可以理解为SQL事务中的Lock、Commit、Rollback。
TCC 为在业务层编写代码实现的两阶段提交。TCC 分别指 Try、Confirm、Cancel ，一个业务操作要对应的写这三个方法
Github 上有具体的实现，例如 点击跳转
处理流程
- 阶段1：Try 阶段
从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑，这个阶段主要完成：
- 完成所有业务检查( 一致性 )
- 预留必须业务资源( 准隔离性 )
TCC事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。因此，Try阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其执行结果撤销。
假设商品库存为100，购买数量为2，这里检查和更新库存的同时，冻结用户购买数量的库存，同时创建订单，订单状态为待确认。
- 阶段2：Confirm / Cancel 阶段
根据Try阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。
Confirm和Cancel操作满足幂等性，如果Confirm或Cancel操作执行失败，将会不断重试直到执行完成。
- Confirm：确认
当Try阶段服务全部正常执行， 执行确认业务逻辑操作
这里使用的资源一定是Try阶段预留的业务资源。在TCC事务机制中认为，如果在Try阶段能正常的预留资源，那Confirm一定能完整正确的提交。Confirm阶段也可以看成是对Try阶段的一个补充，Try+Confirm一起组成了一个完整的业务逻辑。 - Cancel：取消
当Try阶段存在服务执行失败， 进入Cancel阶段
Cancel取消执行，释放Try阶段预留的业务资源，上面的例子中，Cancel操作会把冻结的库存释放，并更新订单状态为取消。
方案总结
TCC事务机制相对于传统事务机制（X/Open XA），TCC事务机制相比于上面介绍的XA事务机制，有以下优点:
- 性能提升
– 具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。 - 数据最终一致性
– 基于Confirm和Cancel的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。 - 可靠性
– 解决了XA协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。
缺点：
- TCC的Try、Confirm和Cancel操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。
2 Seata
Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。在 Seata 开源之前，Seata 对应的内部版本在阿里经济体内部一直扮演着分布式一致性中间件的角色，帮助经济体平稳的度过历年的双11，对各BU业务进行了有力的支撑。经过多年沉淀与积累，商业化产品先后在阿里云、金融云进行售卖。2019.1 为了打造更加完善的技术生态和普惠技术成果，Seata 正式宣布对外开源，开放以来，广受欢迎，不到一年已经成为最受欢迎的分布式事务解决方案。
官方中文网：https://seata.io/zh-cn
github项目地址：https://github.com/seata/seata
官方example：https://github.com/seata/seata-samples
2.1 Seata术语
- TC (Transaction Coordinator) - 事务协调者
– 维护全局和分支事务的状态，驱动全局事务提交或回滚。 - TM (Transaction Manager) - 事务管理器
– 定义全局事务的范围：开始全局事务、提交或回滚全局事务。 - RM (Resource Manager) - 资源管理器
– 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata 致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
2.1 Seata AT模式
Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。其中AT模式最受欢迎
AT模式的相关资料请参考官方文档说明：https://seata.io/zh-cn/docs/overview/what-is-seata.html
下图是AT模式的执行流程：
2.1.1 AT模式及工作流程
见官方文档：https://seata.io/zh-cn/docs/overview/what-is-seata.html
2.1.2 Seata-Server安装
在选择用Seata版本的时候，可以先参考下官方给出的版本匹配（Seata版本也可以按自己的要求选择）：跳转
直接基于docker启动：
docker run --name seata-server -p 8091:8091 -d -e SEATA_IP=192.168.200.200 -e SEATA_PORT=8091 --restart=on-failure seataio/seata-server:1.3.0
2.1.3 集成springcloud-alibaba
官方示例, 可以 跳转
各种集成模式自行的去看对应的samples
集成可以按照如下步骤实现：
1: 引入依赖包spring-cloud-starter-alibaba-seata
2: 配置Seata
3: 创建代理数据源
4: @GlobalTransactional全局事务控制
集成SpringCloud Alibaba需求：
- 创建undo_log表
在每个数据库中都需要创建该表：
CREATE TABLE `undo_log` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`branch_id` bigint(20) NOT NULL,
`xid` varchar(100) NOT NULL,
`context` varchar(128) NOT NULL,
`rollback_info` longblob NOT NULL,
`log_status` int(11) NOT NULL,
`log_created` datetime NOT NULL,
`log_modified` datetime NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
- 依赖引入
<!--seata-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-seata</artifactId>
<version>2.2.7.RELEASE</version>
</dependency>
- 配置Seata
依赖引入后，需要在项目中配置SeataClient 端信息，关于SeataClient端配置信息, 可以参考官方项目：script，如下图：
seata:
enabled: true
application-id: ${spring.application.name}
tx-service-group: default_tx_group
enable-auto-data-source-proxy: true
use-jdk-proxy: false
excludes-for-auto-proxying: firstClassNameForExclude,secondClassNameForExclude
client:
rm:
async-commit-buffer-limit: 1000
report-retry-count: 5
table-meta-check-enable: false
report-success-enable: false
saga-branch-register-enable: false
lock:
retry-interval: 10
retry-times: 30
retry-policy-branch-rollback-on-conflict: true
tm:
degrade-check: false
degrade-check-period: 2000
degrade-check-allow-times: 10
commit-retry-count: 5
rollback-retry-count: 5
undo:
data-validation: true
log-serialization: jackson
log-table: undo_log
only-care-update-columns: true
log:
exceptionRate: 100
service:
vgroup-mapping:
default_tx_group: default
grouplist:
default: 192.168.200.200:8091
enable-degrade: false
disable-global-transaction: false
transport:
shutdown:
wait: 3
thread-factory:
boss-thread-prefix: NettyBoss
worker-thread-prefix: NettyServerNIOWorker
server-executor-thread-prefix: NettyServerBizHandler
share-boss-worker: false
client-selector-thread-prefix: NettyClientSelector
client-selector-thread-size: 1
client-worker-thread-prefix: NettyClientWorkerThread
worker-thread-size: default
boss-thread-size: 1
type: TCP
server: NIO
heartbeat: true
serialization: seata
compressor: none
enable-client-batch-send-request: true
配置文件内容参数比较多，注意部分：
- seata_transaction: default:事务分组，前面的seata_transaction可以自定义，通过事务分组很方便找到集群节点信息。
- tx-service-group: default_tx_group:指定应用的事务分组，和上面定义的分组前部分保持一致。
- default: 192.168.200.200:8091:服务地址，seata-server服务地址。
- 代理数据源
通过代理数据源可以保障事务日志数据和业务数据能同步，关于代理数据源早期需要手动创建，但是随着Seata版本升级，不同版本实现方案不一样了，下面是官方的介绍：
1.1.0: seata-all取消属性配置，改由注解@EnableAutoDataSourceProxy开启，并可选择jdk proxy或者cglib proxy
1.0.0: client.support.spring.datasource.autoproxy=true
0.9.0: support.spring.datasource.autoproxy=true
@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients(basePackages = {"com.demo.driver.feign"})
@EnableAutoDataSourceProxy
public class OrderApplication {
}
- 全局事务控制
@Override
@GlobalTransactional
public OrderInfo addOrder(String id) {
...
}
关于使用feign降级功能导致seata事务无法回滚的问题请看：移步
4.2 Seata TCC模式
一个分布式的全局事务，整体是 两阶段提交 的模型。全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自己的：
- 一阶段 prepare 行为
- 二阶段 commit 或 rollback 行为
根据两阶段行为模式的不同，将分支事务划分为 Automatic Transaction Mode 和 Manual Transaction Mode.
AT 模式（参考链接 TBD）基于 支持本地 ACID事务 的 关系型数据库：
- 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
- 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。
- 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。
相应的，TCC 模式，不依赖于底层数据资源的事务支持：
- 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
- 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
- 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。
所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。
TCC实现原理：
有一个 TCC 拦截器，它会封装 Confirm 和 Cancel 方法作为资源（用于后面 TC 来 commit 或 rollback 操作）
封装完，它会本地缓存到 RM （缓存的是方法的描述信息），可以简单认为是放到一个 Map 里面
当 TC 想调用的时候，就可以从 Map 里找到这个方法，用反射调用就可以了
另外，RM 不光是注册分支事务（分支事务是注册到 TC 里的 GlobalSession 中的）
它还会把刚才封装的资源里的重要属性（事务ID、归属的事务组等）以资源的形式注册到 TC 中的 RpcContext
这样，TC 就知道当前全局事务都有哪些分支事务了（这都是分支事务初始化阶段做的事情）
举个例子：RpcContext里面有资源 123，但是 GlobalSession 里只有分支事务 12
于是 TC 就知道分支事务 3 的资源已经注册进来了，但是分支事务 3 还没注册进来
这时若 TM 告诉 TC 提交或回滚，那 GlobalSession 就会通过 RpcContext 找到 1 和 2 的分支事务的位置（比如该调用哪个方法）
当 RM 收到提交或回滚后，就会通过自己的本地缓存找到对应方法，最后通过反射或其他机制去调用真正的 Confirm 或 Cancel
3 Seata注册中心
参看：https://github.com/seata/seata/tree/1.3.0/script/config-center 可以看到seata支持多种注册中心！
3.1 服务端注册中心配置
服务端注册中心(位于seata-server的registry.conf配置文件中的registry.type参数)，为了实现seata-server集群高可用不会使用file类型，一般会采用第三方注册中心，例如zookeeper、redis、eureka、nacos等。
以下使用nacos
seata-server的registry.conf配置如下：
由于是基于docker启动的seata，故可以直接进入到容器内部修改配置文件/resources/registry.conf
registry {
# file ...nacos ...eureka...redis...zk...consul...etcd3...sofa
type = "nacos"
nacos {
application = "seata-server"
serverAddr = "192.168.200.200:8848"
group = "SEATA_GROUP"
namespace = "1ebba5f6-49da-40cc-950b-f75c8f7d07b3"
cluster = "default"
username = "nacos"
password = "nacos"
}
}
此时再重新启动容器，访问：http://192.168.200.200:8848/nacos 看seata是否已注册到nacos中
3.2 客户端注册中心配置
项目中，我们需要使用注册中心，添加如下配置即可:
参看：https://github.com/seata/seata/blob/1.3.0/script/client/spring/application.yml
registry:
type: nacos
nacos:
application: seata-server
server-addr: 192.168.200.200:8848
group : "SEATA_GROUP"
namespace: 52abf927-d578-45f2-ade5-144a59c93a29
username: "nacos"
password: "nacos"
此时就可以注释掉配置中的default.grouplist=“192.168.200.200:8091”
4 Seata高可用
上面配置也只是将注册中心换成了nacos，而且是单机版的，如果要想实现高可用，就得实现集群，集群就需要做一些动作来保证集群节点间的数据同步（会话共享）等操作
需要准备2个seata-server节点，并且seata-server的事务日志存储模式，共支持3种方式
- file【集群不可用】
- redis
- db
这里选择redis存储会话信息实现共享。
1、启动第二个seata-server节点
docker run --name seata-server-n2 -p 8092:8092 -d -e SEATA_IP=192.168.200.200 -e SEATA_PORT=8092 --restart=on-failure seataio/seata-server:1.3.0
2、进入容器修改配置文件 registry.conf，添加注册中心的配置
registry {
# file ...nacos ...eureka...redis...zk...consul...etcd3...sofa
type = "nacos"
nacos {
application = "seata-server"
serverAddr = "192.168.200.200:8848"
group = "SEATA_GROUP"
namespace = "1ebba5f6-49da-40cc-950b-f75c8f7d07b3"
cluster = "default"
username = "nacos"
password = "nacos"
}
}
3、修改seata-server 事务日志的存储模式，resources/file.conf
基于redis来存储集群每个节点的事务日志，通过docker运行一个redis
docker run --name redis6.2 --restart=on-failure -p 6379:6379 -d redis:6.2
然后修改seata-server的file.conf，修改如下：
## transaction log store, only used in seata-server
store {
## store mode: file...db...redis
mode = "redis"
## file store property
file {
## store location dir
dir = "sessionStore"
# branch session size , if exceeded first try compress lockkey, still exceeded throws exceptions
maxBranchSessionSize = 16384
# globe session size , if exceeded throws exceptions
maxGlobalSessionSize = 512
# file buffer size , if exceeded allocate new buffer
fileWriteBufferCacheSize = 16384
# when recover batch read size
sessionReloadReadSize = 100
# async, sync
flushDiskMode = async
}
## database store property
db {
## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp)/HikariDataSource(hikari) etc.
datasource = "druid"
## mysql/oracle/postgresql/h2/oceanbase etc.
dbType = "mysql"
driverClassName = "com.mysql.jdbc.Driver"
url = "jdbc:mysql://127.0.0.1:3306/seata"
user = "mysql"
password = "mysql"
minConn = 5
maxConn = 30
globalTable = "global_table"
branchTable = "branch_table"
lockTable = "lock_table"
queryLimit = 100
maxWait = 5000
}
## redis store property
redis {
host = "192.168.200.200"
port = "6379"
password = ""
database = "0"
minConn = 1
maxConn = 10
queryLimit = 100
}
}
如果基于DB来存储seata-server的事务日志数据，则需要创建数据库seata，表信息如下：
https://github.com/seata/seata/blob/1.3.0/script/server/db/mysql.sql
