一、本地事务才分布式环境下的问题
本地事务,也就是传统的单机事务。在传统数据库事务中,必须要满足四个原则:
分布式事务,就是指不是在单个服务或单个数据库架构下,产生的事务,例如:
- 跨数据源的分布式事务
- 跨服务的分布式事务
- 综合情况
在数据库水平拆分、服务垂直拆分之后,一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例,包括下面几个行为:
- 创建新订单
- 扣减商品库存
- 从用户账户余额扣除金额
完成上面的操作需要访问三个不同的微服务和三个不同的数据库。
订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务,可以保证ACID原则。但是当我们把三件事情看做一个"业务",要满足保证“业务”的原子性,要么所有操作全部成功,要么全部失败,不允许出现部分成功部分失败的现象,这就是分布式系统下的事务了。
而在分布式系统环境下,使用本地事务,很难保证事务的原子性,从而引发出分布式环境下的事务问题。
二、CAP定理
在解决分布式事务问题前,需要介绍一些分布式系统下的理论知识。
1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标。
- Consistency(一致性)
- Availability(可用性)
- Partition tolerance (分区容错性)
Eric Brewer 说,这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
(一) 一致性
Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致。
(二) 可用性
Availability (可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。
(三) 分区容错
Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务。
在分布式系统中,系统间的网络不能100%保证健康,一定会有故障的时候,而服务有必须对外保证服务。因此Partition Tolerance不可避免。
当节点接收到新的数据变更时,就会出现问题了:
如果此时要保证一致性,就必须等待网络恢复,完成数据同步后,整个集群才对外提供服务,服务处于阻塞状态,不可用。如果此时要保证可用性,就不能等待网络恢复,那node01、node02与node03之间就会出现数据不一致。也就是说,在P一定会出现的情况下,A和C之间只能实现一个。
三、BASE理论
BASE理论是对CAP的一种解决思路,包含三个思想:
- Basically Available (基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
- Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。
- Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。
四、分布式事务思路
分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP定理和BASE理论,有两种解决思路:
- AP模式:各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致。
- CP模式:各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。
但不管是哪一种模式,都需要在子系统事务之间互相通讯,协调事务状态,也就是需要一个事务协调者(TC):
这里的子系统事务,称为分支事务;有关联的各个分支事务在一起称为全局事务。
五、Seata
Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务,为用户打造一站式的分布式解决方案。
官网地址:http://seata.io/,其中的文档、播客中提供了大量的使用说明、源码分析。
(一) 架构
Seata事务管理中有三个重要的角色:
- TC (Transaction Coordinator) - 事务协调者:维护全局和分支事务的状态,协调全局事务提交或回滚。
- TM (Transaction Manager) - 事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
- RM (Resource Manager) - 资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
整体的架构如图:
Seata基于上述架构提供了四种不同的分布式事务解决方案:
- XA模式:强一致性分阶段事务模式,牺牲了一定的可用性,无业务侵入
- TCC模式:最终一致的分阶段事务模式,有业务侵入
- AT模式:最终一致的分阶段事务模式,无业务侵入,也是Seata的默认模式
- SAGA模式:长事务模式,有业务侵入
无论哪种方案,都离不开TC,也就是事务的协调者。
(二) 部署
采用docker进行部署安装:
部署配置seata服务
- 创建docker-compose.yml
version: "3"
services:
seata-server:
image: seataio/seata-server:1.4.2
hostname: seata-server
container_name: seata
ports:
- "8091:8091"
environment:
- SEATA_PORT=8091
- SEATA_IP=192.168.0.240
volumes:
- /root/seata/config:/root/seata-config
- 创建容器 docker-compose up -d
- 修改参数
-
- 进入容器内部 docker exec -it seata sh
- 进入resources目录下 cd resources
- 修改registry.conf配置 vi registry.conf
- 注册中心配置:
-
- 配置中心配置:
- 退出容器 exit
- 重启容器 docker restart seata
- 查看日志 docker logs -f seata
- 添加nacos配置
# 数据存储方式,db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://192.168.200.148:3306/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=root
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000
# 事务、日志等配置
server.recovery.committingRetryPeriod=1000
server.recovery.asynCommittingRetryPeriod=1000
server.recovery.rollbackingRetryPeriod=1000
server.recovery.timeoutRetryPeriod=1000
server.maxCommitRetryTimeout=-1
server.maxRollbackRetryTimeout=-1
server.rollbackRetryTimeoutUnlockEnable=false
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000
# 客户端与服务端传输方式
transport.serialization=seata
transport.compressor=none
# 关闭metrics功能,提高性能
metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898
- 创建数据库和表
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- 分支事务表
-- ----------------------------
DROP TABLE IF EXISTS `branch_table`;
CREATE TABLE `branch_table` (
`branch_id` bigint(20) NOT NULL,
`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`transaction_id` bigint(20) NULL DEFAULT NULL,
`resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`status` tinyint(4) NULL DEFAULT NULL,
`client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` datetime(6) NULL DEFAULT NULL,
`gmt_modified` datetime(6) NULL DEFAULT NULL,
PRIMARY KEY (`branch_id`) USING BTREE,
INDEX `idx_xid`(`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
-- ----------------------------
-- 全局事务表
-- ----------------------------
DROP TABLE IF EXISTS `global_table`;
CREATE TABLE `global_table` (
`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`transaction_id` bigint(20) NULL DEFAULT NULL,
`status` tinyint(4) NOT NULL,
`application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`timeout` int(11) NULL DEFAULT NULL,
`begin_time` bigint(20) NULL DEFAULT NULL,
`application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` datetime NULL DEFAULT NULL,
`gmt_modified` datetime NULL DEFAULT NULL,
PRIMARY KEY (`xid`) USING BTREE,
INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
SET FOREIGN_KEY_CHECKS = 1;
(三) 使用
- 引入依赖
<!--seata-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-seata</artifactId>
<exclusions>
<!--版本较低,1.3.0,因此排除-->
<exclusion>
<artifactId>seata-spring-boot-starter</artifactId>
<groupId>io.seata</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-spring-boot-starter</artifactId>
<!--seata starter 采用1.4.2版本-->
<version>${seata.version}</version>
</dependency>
- 配置TC
seata:
registry: # TC服务注册中心的配置,微服务根据这些信息去注册中心获取tc服务地址
type: nacos # 注册中心类型 nacos
nacos:
server-addr: 127.0.0.1:8848 # nacos地址
namespace: "" # namespace,默认为空
group: SEATA_GROUP # 分组,默认是SEATA_GROUP
application: seata-tc-server # seata服务名称
username: nacos
password: nacos
tx-service-group: seata-demo # 事务组名称
service:
vgroup-mapping: # 事务组与cluster的映射关系
seata-demo: SH
1. XA模式
XA 规范 是 X/Open 组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准,XA 规范 描述了全局的TM与局部的RM之间的接口,几乎所有主流的数据库都对 XA 规范 提供了支持。
XA是规范,目前主流数据库都实现了这种规范,实现的原理都是基于两阶段提交。
正常情况:
异常情况:
一阶段:
- 事务协调者通知每个事物参与者执行本地事务。
- 本地事务执行完成后报告事务执行状态给事务协调者,此时事务不提交,继续持有数据库锁。
二阶段:
- 事务协调者基于一阶段的报告来判断下一步操作 。
-
- 如果一阶段都成功,则通知所有事务参与者,提交事务。
- 如果一阶段任意一个参与者失败,则通知所有事务参与者回滚事务。
Seata对原始的XA模式做了简单的封装和改造,以适应自己的事务模型,基本架构如图:
执行流程:
RM 一阶段的工作:
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC
TC 二阶段的工作:
- TC检测各分支事务执行状态
a. 如果都成功,通知所有RM提交事务
b. 如果有失败,通知所有RM回滚事务
RM 二阶段的工作:
- 接收TC指令,提交或回滚事务
优缺点:
XA模式的优点是什么?
- 事务的强一致性,满足ACID原则。
- 常用数据库都支持,实现简单,并且没有代码侵入
XA模式的缺点是什么?
- 因为一阶段需要锁定数据库资源,等待二阶段结束才释放,性能较差
- 依赖关系型数据库实现事务
Seata的starter已经完成了XA模式的自动装配,实现非常简单,步骤如下:
- 修改application.yml文件(每个参与事务的微服务),开启XA模式:
seata:
data-source-proxy-mode: XA
2. AT模式
AT模式同样是分阶段提交的事务模型,不过缺弥补了XA模型中资源锁定周期过长的缺陷。
执行流程:
阶段一RM的工作:
- 注册分支事务
- 记录undo-log(数据快照)
- 执行业务sql并提交
- 报告事务状态
阶段二提交时RM的工作:
- 删除undo-log即可
阶段二回滚时RM的工作:
- 根据undo-log恢复数据到更新前
简述AT模式与XA模式最大的区别是什么?
- XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。
- XA模式依赖数据库机制实现回滚;AT模式利用数据快照实现数据回滚。
- XA模式强一致;AT模式最终一致
在多线程并发访问AT模式的分布式事务时,有可能出现脏写问题,如图:
解决思路:引入了全局锁的概念。在释放DB锁之前,先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。
非seate管理的事务,无法进行处理,发出警告,人工介入。
AT模式的优点:
- 一阶段完成直接提交事务,释放数据库资源,性能比较好。
- 利用全局锁实现读写隔离。
- 没有代码侵入,框架自动完成回滚和提交。
AT模式的缺点:
- 两阶段之间属于软状态,属于最终一致。
- 框架的快照功能会影响性能,但比XA模式要好很多。
AT模式中的快照生成、回滚等动作都是由框架自动完成,没有任何代码侵入,因此实现非常简单。只不过,AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。
实现步骤:
- 创建数据库表(其中lock_table导入到TC服务关联的数据库),undo_log表导入到微服务关联的数据库)
- 修改配置文件
seata:
data-source-proxy-mode: AT # 默认就是AT
- 重启服务测试
3. TCC模式
TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法:
- Try:资源的检测和预留。
- Confirm:完成资源操作业务;要求 Try 成功 Confirm 一定要能成功。
- Cancel:预留资源释放,可以理解为try的反向操作。
扣减用户余额的业务举例
假设账户A原来余额是100,需要余额扣减30元。
- 阶段一( Try ):检查余额是否充足,如果充足则冻结金额增加30元,可用余额扣除30。此时,总金额 = 冻结金额 + 可用金额,数量依然是100不变。事务直接提交无需等待其它事务。
- 阶段二(Confirm):假如要提交(Confirm),则冻结金额扣减30。确认可以提交,不过之前可用金额已经扣减过了,这里只要清除冻结金额就好了:此时,总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元。
- 阶段二(Canncel):如果要回滚(Cancel),则冻结金额扣减30,可用余额增加30。需要回滚,那么就要释放冻结金额,恢复可用金额。
Seata中的TCC模型依然延续之前的事务架构:
TCC模式的每个阶段是做什么的?
- Try:资源检查和预留
- Confirm:业务执行和提交
- Cancel:预留资源的释放
TCC的优点是什么?
- 一阶段完成直接提交事务,释放数据库资源,性能好
- 相比AT模型,无需生成快照,无需使用全局锁,性能最强
- 不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库
TCC的缺点是什么?
- 有代码侵入,需要人为编写try、Confirm和Cancel接口,太麻烦
- 软状态,事务是最终一致
- 需要考虑Confirm和Cancel的失败情况,做好幂等处理
空回滚:当某分支事务的try阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作,这时cancel不能做回滚,就是空回滚。
执行cancel操作时,应当判断try是否已经执行,如果尚未执行,则应该空回滚。
事务悬挂:对于已经空回滚的业务,之前被阻塞的try操作恢复,继续执行try,就永远不可能confirm或cancel ,事务一直处于中间状态,这就是业务悬挂。执行try操作时,应当判断cancel是否已经执行过了,如果已经执行,应当阻止空回滚后的try操作,避免悬挂。
实现步骤:
CREATE TABLE `account_freeze_tbl` (
`xid` varchar(128) NOT NULL,
`user_id` varchar(255) DEFAULT NULL COMMENT '用户id',
`freeze_money` int(11) unsigned DEFAULT '0' COMMENT '冻结金额',
`state` int(1) DEFAULT NULL COMMENT '事务状态,0:try,1:confirm,2:cancel',
PRIMARY KEY (`xid`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;
实现逻辑步骤
- Try业务:
-
- 记录冻结金额和事务状态到account_freeze表。
- 扣减account表可用金额。
- Confirm业务
-
- 根据xid删除account_freeze表的冻结记录。
- Cancel业务
-
- 修改account_freeze表,冻结金额为0,state为2。
- 修改account表,恢复可用金额。
- 如何判断是否空回滚?
-
- cancel业务中,根据xid查询account_freeze,如果为null则说明try还没做,需要空回滚。
- 如何避免业务悬挂?
-
- try业务中,根据xid查询account_freeze ,如果已经存在则证明Cancel已经执行,拒绝执行try业务。
实现代码步骤
- 声明TCC接口
@LocalTCC
public interface AccountTCCService {
@TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
@BusinessActionContextParameter(paramName = "money")int money);
boolean confirm(BusinessActionContext ctx);
boolean cancel(BusinessActionContext ctx);
}
- 实现类
@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {
@Autowired
private AccountMapper accountMapper;
@Autowired
private AccountFreezeMapper freezeMapper;
@Override
@Transactional
public void deduct(String userId, int money) {
// 0.获取事务id
String xid = RootContext.getXID();
// 1.扣减可用余额
accountMapper.deduct(userId, money);
// 2.记录冻结金额,事务状态
AccountFreeze freeze = new AccountFreeze();
freeze.setUserId(userId);
freeze.setFreezeMoney(money);
freeze.setState(AccountFreeze.State.TRY);
freeze.setXid(xid);
freezeMapper.insert(freeze);
}
@Override
public boolean confirm(BusinessActionContext ctx) {
// 1.获取事务id
String xid = ctx.getXid();
// 2.根据id删除冻结记录
int count = freezeMapper.deleteById(xid);
return count == 1;
}
@Override
public boolean cancel(BusinessActionContext ctx) {
// 0.查询冻结记录
String xid = ctx.getXid();
AccountFreeze freeze = freezeMapper.selectById(xid);
// 1.恢复可用余额
accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
// 2.将冻结金额清零,状态改为CANCEL
freeze.setFreezeMoney(0);
freeze.setState(AccountFreeze.State.CANCEL);
int count = freezeMapper.updateById(freeze);
return count == 1;
}
}
- 实现空回滚和避免业务悬挂功能
/**
* 回滚阶段 cancel+判断是否回滚
* @param context
* @return
*/
@Override
public boolean cancel(BusinessActionContext context) {
//0.根据事务id查询表数据
AccountFreeze accountFreeze = freezeMapper.selectById(context.getXid());
//进行判断空回滚
if (accountFreeze == null) {
//对account_freeze表进行插入数据
accountFreeze=new AccountFreeze();
accountFreeze.setState(AccountFreeze.State.CANCEL);
accountFreeze.setFreezeMoney(0); //金额设置0
//获取用户id
String userId = context.getActionContext("userId").toString();
accountFreeze.setUserId(userId);
//获取事务id,从上下文中
String xid = RootContext.getXID();
accountFreeze.setXid(xid);
freezeMapper.insert(accountFreeze);
return true;
}
//判断业务幂等性处理
if(accountFreeze.getState()== AccountFreeze.State.CANCEL){
return true;
}
//1.修改account表,恢复可用金额
accountMapper.refund(accountFreeze.getUserId(),accountFreeze.getFreezeMoney());
//2.修改account_freeze表,冻结金额为0,state为2
accountFreeze.setState(AccountFreeze.State.CANCEL);
accountFreeze.setFreezeMoney(0);
int i = freezeMapper.updateById(accountFreeze);
return i==1;
}
/**
* Try阶段 扣减金额
*
* @param userId
* @param money
*/
@Override
@Transactional
public void deduct(String userId, int money) {
//0获取事务id
String xid = RootContext.getXID();
//业务悬挂问题处理
AccountFreeze accountFreeze = freezeMapper.selectById(xid);
if(accountFreeze!=null){
return;
}
//1.扣减金额
accountMapper.deduct(userId,money);
//2.记录冻结金额和事务状态到account_freeze表中
AccountFreeze entity=new AccountFreeze();
entity.setState(AccountFreeze.State.TRY);
entity.setFreezeMoney(money);
entity.setUserId(userId);
entity.setXid(xid);
freezeMapper.insert(entity);
}
@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {
@Autowired
private AccountMapper accountMapper;
@Autowired
private AccountFreezeMapper freezeMapper;
/**
* Try阶段 扣减金额
*
* @param userId
* @param money
*/
@Override
@Transactional
public void deduct(String userId, int money) {
//0获取事务id
String xid = RootContext.getXID();
//业务悬挂问题处理
AccountFreeze accountFreeze = freezeMapper.selectById(xid);
if(accountFreeze!=null){
return;
}
//1.扣减金额
accountMapper.deduct(userId,money);
//2.记录冻结金额和事务状态到account_freeze表中
AccountFreeze entity=new AccountFreeze();
entity.setState(AccountFreeze.State.TRY);
entity.setFreezeMoney(money);
entity.setUserId(userId);
entity.setXid(xid);
freezeMapper.insert(entity);
}
/**
* 提交阶段confirm
*
* @param context 上下文,可以传递try方法的参数
* @return
*/
@Override
public boolean confirm(BusinessActionContext context) {
//1.根据xid删除account_freeze表的冻结记录
int i = freezeMapper.deleteById(context.getXid());
return i==1;
}
/**
* 回滚阶段 cancel+判断是否回滚+业务幂等处理
* @param context
* @return
*/
@Override
public boolean cancel(BusinessActionContext context) {
//0.根据事务id查询表数据
AccountFreeze accountFreeze = freezeMapper.selectById(context.getXid());
//进行判断空回滚
if (accountFreeze == null) {
//对account_freeze表进行插入数据
accountFreeze=new AccountFreeze();
accountFreeze.setState(AccountFreeze.State.CANCEL);
accountFreeze.setFreezeMoney(0);
//获取用户id
String userId = context.getActionContext("userId").toString();
accountFreeze.setUserId(userId);
//获取事务id,从上下文中
String xid = RootContext.getXID();
accountFreeze.setXid(xid);
freezeMapper.insert(accountFreeze);
return true;
}
//判断业务幂等性处理
if(accountFreeze.getState()== AccountFreeze.State.CANCEL){
return true;
}
//1.修改account表,恢复可用金额
accountMapper.refund(accountFreeze.getUserId(),accountFreeze.getFreezeMoney());
//2.修改account_freeze表,冻结金额为0,state为2
accountFreeze.setState(AccountFreeze.State.CANCEL);
accountFreeze.setFreezeMoney(0);
int i = freezeMapper.updateById(accountFreeze);
return i==1;
}
}
4. SAGA模式
Saga 模式是 Seata 即将开源的长事务解决方案,将由蚂蚁金服主要贡献。其理论基础是Hector & Kenneth 在1987年发表的论文Sagas。Seata官网对于Saga的指南:https://seata.io/zh-cn/docs/user/saga.html
在 Saga 模式下,分布式事务内有多个参与者,每一个参与者都是一个冲正补偿服务,需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中,依次执行各参与者的正向操作,如果所有正向操作均执行成功,那么分布式事务提交。如果任何一个正向操作执行失败,那么分布式事务会去退回去执行前面各参与者的逆向回滚操作,回滚已提交的参与者,使分布式事务回到初始状态。
Saga也分为两个阶段:
- 一阶段:直接提交本地事务
- 二阶段:成功则什么都不做;失败则通过编写补偿业务来回滚
优点:
- 事务参与者可以基于事件驱动实现异步调用,吞吐高
- 一阶段直接提交事务,无锁,性能好
- 不用编写TCC中的三个阶段,实现简单
缺点:
- 软状态持续时间不确定,时效性差
- 没有锁,没有事务隔离,会有脏写