springCloud-seata

1.分布式事务理论θ

1.1 CAP定理

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：

• Consistency（一致性）

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

• Availability（可用性）

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

• Partition tolerance （分区容错性）

  • Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

  • Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

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

• 这个和病毒的,致死性,传播性,和变异性好像啊.

总结 : 分布式系统节点通过网络连接，一定会出现分区问题（P）, 当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足 , 所以只能选择AP的策略 , 或AP的策略.

1.2 BASE理论

• 鱼(A)和熊掌(C)何以兼得?

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

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。

• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

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

• AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

1.3 解决

• 引入一个事务协调者来协调每一个事务的参与者(子系统事务),让各个子系统之间必须能感知到彼此的事务状态,才能保证状态一致.

2.Seata

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

  • TC(Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

  • TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

  • RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

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

  • XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入

  • TCC模式：最终一致的分阶段事务模式，有业务侵入

  • AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式

  • SAGA模式：长事务模式，有业务侵入

2.1 部署TC服务

• SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，史上最全面的微服务全技术栈课程|黑马程序员Java微服务教程_哔哩哔哩_bilibili

2.2 微服务集成Seata

• 所有参与远程调用的服务都需要添加和配置

2.2.1 引入seata相关依赖

    com.alibaba.cloud
    spring-cloud-starter-alibaba-seata
    
        
        
            seata-spring-boot-starter
            io.seata
        
    



    io.seata
    seata-spring-boot-starter
    ${seata.version}

2.2.2 配置application.yml

• 让微服务通过注册中心找到seata-tc-server

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos
    nacos:
      server-addr: localhost:8848
      namespace: "" #空就是默认 public
      group: DEFAULT_GROUP
      application: seata-tc-server # tc服务在nacos中的服务名称
      username: nacos
      password: nacos
      cluster: SH
  tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
  service:
    vgroup-mapping: #事务组与cluster的映射关系
      seata-demo: SH

3.分布式事务模式 - XA

3.1 概述

描述了全局的TM与局部的RM之间的接口.基于数据库本身特性.

• RM一阶段的工作 :

  • 注册分支事务到TC

  • 执行分支业务sql但是不提交

  • 报告执行状态到tc

• TC二阶段的工作 : TC检测各分支事务执行状态

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

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

• RM二阶段的工作

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

• XA模式的优点

  • 事务的强一致性,满足ACID原则

  • 常用数据库都支持,实现简单,并且没有代码入侵

• XA模式的缺点

  • 因为一阶段需要锁定数据库资源,等待二阶段结束才能释放,性能较差

  • 需要等到分支业务全部提交完成,才能统一检查

  • 依赖关系型数据库

3.2 实现

• 修改application.yml文件(每个参与事务的微服务都需要修改),开启XA模式

seata:  
   data-source-proxy-mode: XA #开启数据源代理的XA模式

• 给发起全局事物的入口方法(服务调用者)添加@GlobalTransactional注解,本例中时OrderServiceImpl中的create方法.

    @Override
    @GloabalTransactional
    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();
    }

• 重启服务并测试

4.分布式事务模式 - AT

• AT模式同样是分阶段提交的事务模型,不过弥补了XA模式中资源锁定周期过长的缺陷

• 阶段一RM的工作:

  • 注册分支事务

  • 记录undo-log(数据快照)

  • 执行业务sql并且提交

  • 报告事务状态

• 阶段而提交时RM的工作

  • 删除undo-log即可

• 阶段而回滚时RM的工作

  • 根据undo-log恢复数据到更新前.

4.1 AT模式的脏写问题

• 事务一进行了回滚,相当于事务2没有进行操作.(根本原因:一阶段和二阶段是非原子性的)

4.2 全局锁 X(两个事务都由seata管理)

解决 : 引入全局锁

• 全局锁 : 又TC记录当前正在操作某行数据的事务,该事务持有全局锁,具备执行权.

  xid	table	pk

  pk : 主键 : 表名操作的是数据表中的哪一行数据

  table : 表名

  xid : 事务id : 表示当前是哪个事务正在操作.

• 效果 : 这个表中的这一行只能被xid的事务操作,别的事务不能操作.

4.2 全局锁 Ω(一个事务都由seata管理,另一个不是)

解决 : 引入全局锁

• 着这个模式下,会保存两个快照,分别是执行业务前的快照,和执行业务之后的快照,当二阶段回滚完毕后,发现执行业务后的快照(90)与数据库当前状态(80)不一致,这时候就应该进行2.2步,发送警告,人工接入.

4.3 AT模式的优缺点

• AT模式的优点

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

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

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

• AT模式的缺点

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

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

4.4 实现

• 导入课前资料提供的Sql文件：seata-at.sql，其中lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库：

• 修改application.yml文件，将事务模式修改为AT模式即可 (所有参与远程调用的都添加)

seata:
  data-source-proxy-mode: AT

• 加注解@GalbalTranscational

5.分布式事务模式 - TCC

5.1 概述

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

  • Try：资源的检测和预留

  • Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功

  • Cancel：预留资源释放，可以理解为try的反向操作

• 举例

  • 一个扣减用户余额的业务,假设账户A原来余额是100,需要扣减30元

    • 阶段一(Try) : 检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30

      

    • 阶段二：假如要提交（Confirm），则冻结金额扣减30

      

    • 阶段二：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30

      
• 二阶段大家各自操作各自预留的资源(冻结部分),各事务之间互不影响,自然就实现了隔离效果.

5.2 流程

5.3 优缺点

• 优点 :

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

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

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

• 缺点:

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

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

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

5.4 实现

• 需求如下

  • 修改account-service，编写try、confirm、cancel逻辑,因为创建订单不会对同一条事务产生影响,扣减余额和减少库存逻辑类似,这里只演示一个.

  • try业务：添加冻结金额，扣减可用金额

  • confirm业务：删除冻结金额

  • cancel业务：删除冻结金额，恢复可用金额

  • 保证confirm、cancel接口的幂等性

  • 允许空回滚

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

  • 拒绝业务悬挂

    • (二阶段已经执行完毕)对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel,就只进行了业务冻结，这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂

• 为了实现空回滚,防止业务悬挂,以及幂等性的要求,我们必须在数据库记录冻结金额的同时,记录当前事务id和执行状态,为此我们设计了一张表.

DROP TABLE IF EXISTS `account_freeze_tbl`;
CREATE TABLE `account_freeze_tbl`  (
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `freeze_money` int(11) UNSIGNED NULL DEFAULT 0,
  `state` int(1) NULL DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',
  PRIMARY KEY (`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci 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业务

5.4.1 AccountTCCService

@BusinessActionContextParameter(paramName = "userId")  //传入上下文对象,可以在三个方法中通过ctx获取里面的值

@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);
}

5.4.2 AccountTCCServiceImpl

@Service
public class AccountTCCServiceImpl implements AccountTCCService {


    @Autowired
    private AccountMapper accountMapper;

    @Autowired
    private AccountFreezeMapper freezeMapper;

    @Override
    @Transactional
    public void deduct(String userId, int money) {
        //判断 : 因为数据库中money字段为unsigned 所以这里不用作余额判断
        //0.获取事务id
        String xid = RootContext.getXID();

        //X判断freeze中是否有冻结记录,如果有,一定CANCEL执行过,我要拒绝业务
        AccountFreeze oldFreeze = freezeMapper.selectById(xid);
        if(oldFreeze != null){
         //CANCEL执行过,我要拒绝业务
         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);
    }

    @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();
        String userId = ctx.getActionContext("userId").toString();

        AccountFreeze freeze = freezeMapper.selectById(xid);

        //X 空回滚的判断,判断freeze是否为null,为null证明try没执行
        if(freeze == null){
            //证明try没执行,需要空回滚
            freeze = new AccountFreeze();
            freeze.setUserId(userId);
            freeze.setFreezeMoney(0);
            freeze.setState(AccountFreeze.State.CANCEL);
            freeze.setXid(xid);
            freezeMapper.insert(freeze);
            return true;
        }

        //Ω  幂等判断
        if (freeze.getState() == AccountFreeze.State.CANCEL){
         //已经处理过一次了,无需重复处理
         return true;
        }


        //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;
    }
}

5.4.3 controller

• 这里调用的是TCC的Service

@RestController
@RequestMapping("account")
public class AccountController {

    @Autowired
    private AccountTCCService accountService;

    @PutMapping("/{userId}/{money}")
    public ResponseEntity deduct(@PathVariable("userId") String userId, @PathVariable("money") Integer money){
        accountService.deduct(userId, money);
        return ResponseEntity.noContent().build();
    }
}