【分布式事务】

文章目录

解决分布式事务的思路
seata四种模式
- 1. XA模式
- 2. AT模式
- - AT模式与XA模式的区别是什么？
  - 脏写问题
- 3. TCC模式
- - 事务悬挂和空回滚
- 4. SAGA模式
四种模式对比
口述AT模式与TCC模式
高可用

什么是分布式事务？

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

跨数据源的分布式事务
跨服务的分布式事务
综合情况

例如电商行业中比较常见的下单付款案例，包括下面几个行为：

创建新订单
扣减商品库存
从用户账户余额扣除金额

在这里插入图片描述
订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

此时ACID难以满足，这是分布式事务要解决的问题

CAP理论：
Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
Partition（分区）**：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

seata事务管理：

Seata事务管理中有三个重要的角色：

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

在这里插入图片描述

微服务集成seata：

引入依赖
配置TC地址

seata四种模式

Seata提供了四种不同的分布式事务解决方案：

XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
TCC模式：最终一致的分阶段事务模式，有业务侵入
SAGA模式：长事务模式，有业务侵入

1. XA模式

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：
在这里插入图片描述

XA模式的优点是什么？

事务的强一致性，满足ACID原则。
常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
依赖关系型数据库实现事务

实现XA模式：
在这里插入图片描述

2. AT模式

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
在这里插入图片描述

AT模式下执行流程：

一阶段：

1）TM发起并注册全局事务到TC

2）TM调用分支事务

3）分支事务准备执行业务SQL

4）RM拦截业务SQL，根据where条件查询原始数据，形成快照。

{"id": 1, "money": 100
}

5）RM执行业务SQL，提交本地事务，释放数据库锁。此时 money = 90

6）RM报告本地事务状态给TC

二阶段：

1）TM通知TC事务结束

2）TC检查分支事务状态

a）如果都成功，则立即删除快照

b）如果有分支事务失败，需要回滚。读取快照数据（{"id": 1, "money": 100}），将快照恢复到数据库。此时数据库再次恢复为100

AT模式与XA模式的区别是什么？

XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
XA模式强一致；AT模式最终一致

脏写问题

口述：因为AT模式是两阶段的事务模型，在第一个阶段分支事务执行之前首先会记录数据快照，然后执行对应sql，然后就释放了数据库锁，那么在他释放后这一时刻，另一个事务就能拿到数据库锁然后对同一个数据又进行了修改，那么第一个事务在第二阶段回滚恢复快照时，就会覆盖另一个事务的修改。

在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题，如图：
在这里插入图片描述

解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。
在这里插入图片描述
AT模式的优点：

一阶段完成直接提交事务，释放数据库资源，性能比较好
利用全局锁实现读写隔离
没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

两阶段之间属于软状态，属于最终一致
框架的快照功能会影响性能，但比XA模式要好很多

3. TCC模式

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

在这里插入图片描述

TCC的优点是什么？

一阶段完成直接提交事务，释放数据库资源，性能好
相比AT模型，无需生成快照，无需使用全局锁，性能最强
不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC的缺点是什么？

有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
软状态，事务是最终一致
需要考虑Confirm和Cancel的失败情况，做好幂等处理

事务悬挂和空回滚

空回滚：
当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
在这里插入图片描述
业务悬挂：
对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。

执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂

实现TCC模式案例：
解决空回滚和业务悬挂问题，必须要记录当前事务状态，是在try、还是cancel？

这里我们定义一张冻结表：

其中：

xid：是全局事务id
freeze_money：用来记录用户冻结金额
state：用来记录事务状

那此时，我们的业务开怎么做呢？

Try业务：
- 记录冻结金额和事务状态（state=0）到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接口
TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明，
我们在account-service项目中的cn.itcast.account.service包中新建一个接口，声明TCC三个接口：

package cn.itcast.account.service;import io.seata.rm.tcc.api.BusinessActionContext;
import io.seata.rm.tcc.api.BusinessActionContextParameter;
import io.seata.rm.tcc.api.LocalTCC;
import io.seata.rm.tcc.api.TwoPhaseBusinessAction;@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);
}

编写实体类
在account-service服务中的cn.itcast.account.service.impl包下新建一个类，实现TCC业务：

package cn.itcast.account.service.impl;import cn.itcast.account.entity.AccountFreeze;
import cn.itcast.account.mapper.AccountFreezeMapper;
import cn.itcast.account.mapper.AccountMapper;
import cn.itcast.account.service.AccountTCCService;
import io.seata.core.context.RootContext;
import io.seata.rm.tcc.api.BusinessActionContext;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {@Autowiredprivate AccountMapper accountMapper;@Autowiredprivate AccountFreezeMapper freezeMapper;@Override@Transactionalpublic void deduct(String userId, int money) {// 0.获取事务idString xid = RootContext.getXID();// 避免特务悬挂，判断freeze表中是否有冻结记录，如果有一定是CANDEL执行过了，拒绝执行tryAccountFreezeMapper oldFreeze = freezeMapper.selectById(xid);if (oldFreeze != null){return;}// 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);}@Overridepublic boolean confirm(BusinessActionContext ctx) {// 1.获取事务idString xid = ctx.getXid();// 2.根据id删除冻结记录int count = freezeMapper.deleteById(xid);return count == 1;}@Overridepublic boolean cancel(BusinessActionContext ctx) {// 0.查询冻结记录String xid = ctx.getXid();String userId = ctx.getActionContext(userId).toString();AccountFreeze freeze = freezeMapper.selectById(xid);//空回滚的判断，判断freeze是否为null，为null证明还没有try，需要空回滚if (freeze == null){//为null证明还没有try，需要空回滚freeze = new AccountFreeze();freeze.setUserId(userId);freeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);freeze.setXid(xid);freezeMapper.insert(freeze);}//判断幂等性if (freeze.getState() == AccountFreeze.State.CANCEL){// 已经处理过一次CANCEL了，无需重复处理return true;}// 1.恢复可用余额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());// 2.将冻结金额清零，状态改为CANCELfreeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);int count = freezeMapper.updateById(freeze);return count == 1;}
}

4. SAGA模式

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
在这里插入图片描述

四种模式对比

在这里插入图片描述

口述AT模式与TCC模式

AT模式与TCC模式都是二阶段的分布式事务模型，每个分支事务在第一阶段它们执行完后都可以立即提交或回滚，当=当然有的分支事务能成功有的就回滚了，当TC（事务调度者）来对这些分支事务做统计，看看最终是将这些事务提交还是回滚，AT模式下的话它是基于数据快照形式的，在操作数据库之前会保存数据库修改前的数据快照，当需要回滚时恢复这些快照就可以，AT下的话还使用了全局锁，来避免第一阶段与第二阶段这个时间内的脏写问题; TCC模式的话其实核心就是三个接口Try、confirm、cancel，它在第一阶段是会进行try操作就是资源的预留的，就是吧对应想操作的数据记录到一张表中，
第二个阶段如果要是提交的话就是执行confirm里面的代码，它直接删除我们表中的数据就可以，如果要回滚的话其实就是执行cancel这个方法的代码，其实类似于执行try的反向操作。这里面的话需要注意空回滚与业务悬挂，就是在try与cancel中来进行具体的判断。