【SpringCloud——Seata分布式事务管理框架】

一、分布式事务存在的问题

在分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样的事务就是分布式事务。

分布式事务和传统形式的事务区别有什么?众所周知,我们采用微服务框架开发项目时,不同服务之间通过相互调用的方式完成业务处理,用以下案例来描述分布式业务存在的问题:

假设我们此时现在有一个商城系统,其中包括下单系统、用户系统、仓库系统。当我们进行下单时,就需要创建订单信息,同时需要对用户的余额进行扣减,还需要对仓储系统的商品数量进行减少,由于每个系统分别负责一部分的业务,且其拥有独立的数据库信息,因此我们就会有三个事务,订单创建、余额扣减、商品剩余量扣减。

下单系统主要代码如下:

    public Long create(Order order) {
        // 创建订单
        orderMapper.insert(order);
        try {
            // 扣用户余额
            accountClient.deduct(order.getUserId(), order.getMoney());
            // 扣库存
            storageClient.deduct(order.getCommodityCode(), order.getCount());

        } catch (FeignException e) {
            log.error("下单失败,原因:{}", e.contentUTF8(), e);
            throw new RuntimeException(e.contentUTF8(), e);
        }
        return order.getId();
    }

用户余额扣减代码:

    public void deduct(String userId, int money) {
        log.info("开始扣款");
        try {
            accountMapper.deduct(userId, money);
        } catch (Exception e) {
            throw new RuntimeException("扣款失败,可能是余额不足!", e);
        }
        log.info("扣款成功");
    }

商品数量扣减代码:

    public void deduct(String commodityCode, int count) {
        log.info("开始扣减库存");
        try {
            storageMapper.deduct(commodityCode, count);
        } catch (Exception e) {
            throw new RuntimeException("扣减库存失败,可能是库存不足!", e);
        }
        log.info("扣减库存成功");
    }

数据库信息如下:

用户:

【SpringCloud——Seata分布式事务管理框架】_第1张图片

订单:

【SpringCloud——Seata分布式事务管理框架】_第2张图片

商品:

【SpringCloud——Seata分布式事务管理框架】_第3张图片

 我们假设每件商品为200元,此时账户余额为1000元,当我们下单一件商品时,此时就会创建一个订单,且用户余额和商品数量分别减少200元和1件,当我们再次同时下单五件该商品时,此时显然用户的余额已经不足以支付1000元了,但是我们的订单已经创建,且事务已经提交,此时余额扣减就会触发事务回滚操作,即扣减失败了,但是订单已经生成了,且商品剩余量也已经减少了,这三个操作分别是独立的事务,任意一个失败都无法使其余两个事务回滚,那这显然不是我们想要的效果,我们理想的状态就是任意一个事务回滚了,其余两个事务也将进行回滚。

二、分布式事务理论基础

1、CAP定理

CAP是指:

  • Consistency(一致性)
  • Availability(可用性)
  • Partition tolerance(分区容错性)

分布式系统无法同时满足这三个指标,这个结论就叫做CAP定理。

【SpringCloud——Seata分布式事务管理框架】_第4张图片

1、一致性

用户访问分布式系统中的任意节点,得到的数据必须是一致的。

【SpringCloud——Seata分布式事务管理框架】_第5张图片

 节点1的数据一旦发生修改,节点2的数据必须进行同步,与节点1的数据保持一致。

2、可用性

用户访问集群中的任意健康节点时,必须能得到响应,而不是超时或者拒绝。

【SpringCloud——Seata分布式事务管理框架】_第6张图片

 当节点3发生故障时,就会对请求进行阻塞或者拒绝,此时节点3就是不可用的。

3、分区容错性

分区:因为网络故障或其它原因导致分布式系统中的部分系欸DNA与其它节点失去连接,形成独立分区。

【SpringCloud——Seata分布式事务管理框架】_第7张图片

容错:在集群出现分区时,整个系统也要持续对外提供服务。

 起初节点1、2、3是互相连接的,即任意节点数据发生变化,其余两个节点的数据也将进行同步修改,但是假设节点3与其他两个节点的网络连接断开了,但是节点本身并没有故障,就会形成新的分区,此时一旦有人对节点2的数据进行了修改,并将修改信息同步到了节点1,此时用户访问不同的节点,假设访问节点1之后我们又访问了节点3,此时拿到的结果就是不一致的。此时就不满足一致性,如果我们非要满足一致性,我们怎么办?让节点3进入短暂的禁止访问状态,等待和节点2的网络通信回复,在此期间对于到来的一切请求都进行拒绝或者阻塞,这样一来确实一致性问题得到了解决,但是我们又说了可用性,即系统健康时就必须对请求做出响应,此时我们的节点3只是和其余两个节点不通,并没有不健康,所以这就是一种悖论,我们只能在一致性和可用性之间做出抉择!

CAP定理的主要内容:

  • 分布式系统节点通过网络连接,一定会出现分区问题(P)
  • 当分区出现时,系统的一致性(C)和可用性(A)就无法同时满足

CP:保证了系统的一致性,但是牺牲了系统的可用性。

AP:保证了系统的可用性,但是牺牲了系统的一致性。

ES是CP还是AP:

此前我们搭建的ES集群,当其中某一个节点挂掉时,另外两个节点会把该节点的数据复制到自己本地,当出现故障的节点重新上线了,又会将copy过来的数据返还给该节点,这样做的目的是为了保证系统的一致性,从而牺牲掉了可用性,因此ES是CP。

2、BASE理论

BASE理论是对CAP的一种解决思路,包含三个思想:

  • Basically Available (基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
  • Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。
  • Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。

 而分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP定理和BASE理论:

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

解决分布式事务,各个子系统之间必须能感知到彼此的事务状态,才能保证状态一致,因此需要一个事务协调者来协调每一个事务的参与者(子系统事务)。 这里的子系统事务,称为分支事务;有关联的各个分支事务在一起称为全局事务。

 【SpringCloud——Seata分布式事务管理框架】_第8张图片

三、认识Seata

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

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

 【SpringCloud——Seata分布式事务管理框架】_第9张图片

四、分布式事务实践

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

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

1、XA模式

XA 规范 是 X/Open 组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准,XA 规范 描述了全局的TM与局部的RM之间的接口,几乎所有主流的数据库都对 XA 规范 提供了支持。

XA是规范,目前主流的数据库都实现了这种规范,实现的原理都是基于两阶段提交。

  • 正常情况:

【SpringCloud——Seata分布式事务管理框架】_第10张图片

  • 异常情况:

【SpringCloud——Seata分布式事务管理框架】_第11张图片

一阶段:

  • 事务协调者通知每个事务参与者分别执行本地事务
  • 本地事务执行完成后向事务协调者告知事务的执行状态,此时本地事务并没有提交,继续持有数据库锁

二阶段:

  • 事务协调者根据一阶段的报告判断下一步操作

     ①、如果一阶段所有分支事务都执行成功,则告知所有事务参与者提交事务。

     ②、如果一阶段任意一个事务失败,则告知所有事务参与者回滚事务。

下面我们来看看Seata当中的XA模型:

【SpringCloud——Seata分布式事务管理框架】_第12张图片

RM一阶段的工作:

  1. 注册分支事务到TC
  2. 执行分支业务sql但不提交
  3. 报告执行状态给TC

TC二阶段的工作:

  • TC检测各分支事务的执行状态

       a.如果都成功,通知所有RM提交事务

       b.如果有失败,通知所有RM回滚事务

RM二阶段的工作:

  • 接收TC的指令,提交或回滚事务。

 XA模式的优缺点:

  • 优点:
  1. 事务的强一致性,满足ACID原则。
  2. 常用数据库都支持,实现简单,并且没有代码侵入。
  • 缺点:
  1. 因为一阶段需要锁定数据库资源,等待二阶段结束才会释放,性能较差。
  2. 依赖关系型数据库实现事务。

如何利用Seata实现XA模式:

1、修改配置文件(每个参与事务的微服务),开启XA模式

seata:
  data-source-proxy-mode: XA

2、给发起全局事务的入口方法添加@GlobalTransactional注解

3、重启服务测试

2、AT模式

AT模式是对XA模式的弊端进行了完善(执行事务完并不会持续占有数据库资源)。我们来看看AT模式具体是怎么做的:

【SpringCloud——Seata分布式事务管理框架】_第13张图片

        在XA模式当中,一阶段分支事务执行完事务后会等待TC的通知进行事务的提交或者事务的回滚,等待过程中会持有DB锁防止其他事务进行操作,这样会大大降低性能,在AT模式下,分支事务不需要等待TC的通知即可提交事务,但是会生成一份数据快照(undo_log),该快照记录了数据修改前和修改后的值,当TC通知分支事务进行事务提交或者回滚时,如果是提交,分支事务则仅需要删除生成的快照即可,如果是回滚,则需要根据快照当中的信息恢复数据。

案例:用户余额扣减

ID money
1 100

有一个分支事务要执行的SQL为:

update tb_account set money = money - 10 where id = 1

AT模式下,该分支事务的执行流程如下:

一阶段:

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

2)TM调用分支事务

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

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

{

  “id”:1,“money”:100

}

5)RM执行业务SQL,提交本地事务,释放DB锁,此时money=90

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

二阶段:

1)TM通知TC事务结束

2)TC检查分支事务状态

   a)都成功,则通知RM删除快照

   b)有失败,通知RM根据快照恢复数据

流程图:

【SpringCloud——Seata分布式事务管理框架】_第14张图片

 XA模式与AT模式的区别:

  • XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。

  • XA模式依赖数据库机制实现回滚;AT模式利用数据快照实现数据回滚。

  • XA模式强一致;AT模式最终一致

 AT模式的弊端——脏写问题

【SpringCloud——Seata分布式事务管理框架】_第15张图片

 解决方案就是引入全局锁的概念,在释放DB锁之前,先要拿到全局锁,避免同一时刻有另外一个事务来操作当前持有的数据。

【SpringCloud——Seata分布式事务管理框架】_第16张图片

 这个全局锁就限制了哪个事务可以操作该数据,当事务1执行业务SQL前,会先获取全局锁,TC就会进行记录,此时事务1释放DB锁去等待TC的通知(删除快照或根据快照修复数据),事务2拿到了DB锁开始执行业务SQL,当事务2尝试获取全局锁时,就会发现获取不到,因为全局锁现在被事务1所持有,此时假设恰好TC告知事务1进行数据回滚,事务1则会重新获取DB锁,但是DB锁此时被事务2所持有,这样就形成了死锁,怎么办?事务2在尝试获取一段时间全局锁后一直拿不到,就会放弃获取全局锁,此时事务1就拿到了DB锁,进行快照修复即可。前提是两个事务均是由seata控制的事务才会这样。假设事务2不是由seata控制的事务将会是怎样的?

我们上面说过,事务1记录undo_log时会记录数据修改前后的值,当我们进行数据恢复时,发现money此时为80,此时需要我们进行报警处理,人工的根据undo_log当中的数据进行数据恢复。

AT模式的优缺点:

AT模式的优点:

  • 一阶段完成直接提交事务,释放数据库资源,性能比较好

  • 利用全局锁实现读写隔离

  • 没有代码侵入,框架自动完成回滚和提交

AT模式的缺点:

  • 两阶段之间属于软状态,属于最终一致

  • 框架的快照功能会影响性能,但比XA模式要好很多

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

需要回滚,那么就要释放冻结金额,恢复可用金额:

TCC模型:

【SpringCloud——Seata分布式事务管理框架】_第17张图片

 可以看到,TCC模式和AT模式极其相似,但是区别在于,AT模式采用全局锁+undo_log的方式进行事务提交和回滚,这里我们不再使用锁,而是使用try-confirm-cancel的方式对操作进行记录。当TC通知分支事务可以提交的时候,分支事务直接执行confirm方法即可,通知回滚时则执行cancel方法。

TCC模式的优缺点:

TCC模式的每个阶段是做什么的?

  • Try:资源检查和预留

  • Confirm:业务执行和提交

  • Cancel:预留资源的释放

TCC的优点是什么?

  • 一阶段完成直接提交事务,释放数据库资源,性能好

  • 相比AT模型,无需生成快照,无需使用全局锁,性能最强

  • 不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库

TCC的缺点是什么?

  • 有代码侵入,需要人为编写try、Confirm和Cancel接口,太麻烦

  • 软状态,事务是最终一致

  • 需要考虑Confirm和Cancel的失败情况,做好幂等处理

 TCC模式的两个重要问题:事务悬挂和空回滚

  • 事务悬挂

对于已经空回滚的业务,之前被阻塞的try操作恢复,继续执行try,就永远不可能confirm或cancel ,事务一直处于中间状态,这就是业务悬挂

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

  • 空回滚

当某分支事务的try阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作,这时cancel不能做回滚,就是空回滚

【SpringCloud——Seata分布式事务管理框架】_第18张图片

 执行cancel操作时,应当判断try是否已经执行,如果尚未执行,则应该空回

TCC模式代码实现: 

  • 引入资源预留表
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;

其中:

  1. xid:是全局事务id

  2. freeze_money:用来记录用户冻结金额

  3. state:用来记录事务状态

  • 声明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 context);

    boolean cancel(BusinessActionContext context);
}
  • 编写实现类
@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {
    @Autowired
    private AccountMapper accountMapper;

    @Autowired
    private AccountFreezeMapper accountFreezeMapper;


    @Override
    public void deduct(String userId, int money) {
        //0、获取事务ID
        String xid = RootContext.getXID();
        //判断业务悬挂,判断freeze中是否有冻结记录,如果有,一定是CANCEL执行过,我要拒绝业务
        AccountFreeze oldFreeze = accountFreezeMapper.selectById(xid);
        if (oldFreeze == null){
            //1、扣减可用余额
            accountMapper.deduct(userId,money);
            //2、冻结余额数据新增,事务状态
            AccountFreeze accountFreeze = new AccountFreeze();
            accountFreeze.setUserId(userId);
            accountFreeze.setFreezeMoney(money);
            accountFreeze.setState(AccountFreeze.State.TRY);
            accountFreeze.setXid(xid);
            accountFreezeMapper.insert(accountFreeze);
        }
    }

    @Override
    public boolean confirm(BusinessActionContext context) {
        //1、获取事务ID
        String xid = context.getXid();
        //2、根据ID删除冻结记录
        int count = accountFreezeMapper.deleteById(xid);
        return count == 1;

    }

    @Override
    public boolean cancel(BusinessActionContext context) {
        //1、获取事务ID
        String xid = context.getXid();
        //获取参数
        Map actionContext = context.getActionContext();
        String userId = (String) actionContext.get("userId");
        Integer money = (Integer) actionContext.get("money");
        //空回滚的判断,判断
        AccountFreeze accountFreeze1 = accountFreezeMapper.selectById(xid);
        if (accountFreeze1 == null){
            //证明try没执行,需要空回滚
            accountFreeze1 = new AccountFreeze();
            accountFreeze1.setUserId(userId);
            accountFreeze1.setFreezeMoney(0);
            accountFreeze1.setState(AccountFreeze.State.CANCEL);
            accountFreeze1.setXid(xid);
            accountFreezeMapper.insert(accountFreeze1);
            return true;
        }
        //判断幂等
        if (accountFreeze1.getState() == 2){
            //已经处理过CANCEL,无需重复处理
            return true;
        }
        //2、反向更新,恢复可用金额
        accountMapper.refund(userId,money);
        //3、将冻结金额清零,状态改为cancel
        AccountFreeze accountFreeze = new AccountFreeze();
        accountFreeze.setXid(xid);
        accountFreeze.setUserId(userId);
        accountFreeze.setFreezeMoney(0);
        accountFreeze.setState(AccountFreeze.State.CANCEL);
        int count = accountFreezeMapper.updateById(accountFreeze);
        return count == 1;
    }
}

4、SAGA模式

原理:

在 Saga 模式下,分布式事务内有多个参与者,每一个参与者都是一个冲正补偿服务,需要用户根据业务场景实现其正向操作和逆向回滚操作。

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

Saga也分为两个阶段:

  • 一阶段:直接提交本地事务

  • 二阶段:成功则什么都不做;失败则通过编写补偿业务来回滚

【SpringCloud——Seata分布式事务管理框架】_第19张图片

 SAGA模式优缺点:

优点:

  • 事务参与者可以基于事件驱动实现异步调用,吞吐高

  • 一阶段直接提交事务,无锁,性能好

  • 不用编写TCC中的三个阶段,实现简单

缺点:

  • 软状态持续时间不确定,时效性差

  • 没有锁,没有事务隔离,会有脏写

 5、四种模式对比

【SpringCloud——Seata分布式事务管理框架】_第20张图片

 

你可能感兴趣的:(SpringCloud,spring,cloud,分布式,java)