分布式事务

目录

目录

 一、理论基础

1.1 CAP定理

1.2 Base理论

二、初始Seata

2.1 部署TC服务

2.2 动手实践

2.2.1 XA模式

2.2.2 AT模式

2.2.3 TCC模式

---

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

 一、理论基础

1.1 CAP定理

分布式系统有三个指标：

1. Consistency（一致性）
2. Availability（可用性）
3. Partition tolerance （分区容错性）

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

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致

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

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

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

 分布式系统节点通过网络连接，一定会出现分区问题（P）； 当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足。剔除故障节点，即CP，不剔除，则属于AP。

ES集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其它节点，保证数据一致。因此是低可用性，高一致性，属于CP

1.2 Base理论

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

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

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

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

解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务

1.3 总结

简述BASE理论三个思想：

1. 基本可用
2. 软状态
3. 最终一致

解决分布式事务的思想和模型：

1. 全局事务：整个分布式事务
2. 分支事务：分布式事务中包含的每个子系统的事务
3. 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据
4. 强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚

二、初始Seata

官网地址：http://seata.io/

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

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

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

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

2.1 部署TC服务

微服务集成Seata

（1）引入依赖

        <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>
        <!--seata starter 采用1.4.2版本-->
        <dependency>
            <groupId>io.seata</groupId>
            <artifactId>seata-spring-boot-starter</artifactId>
            <version>1.4.2</version>
        </dependency>

（2）配置application.yml，让微服务通过注册中心找到seata-tc-server

seata:
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-server
      username: nacos
      password: nacos
  tx-service-group: seata-demo #事务组名称
  service:
    vgroup-mapping: #事务组与cluster的映射关系
      seata-demo: SH

nacos服务名称组成包括？

namespace + group + serviceName + cluster

seata客户端获取tc的cluster名称方式？

以tx-group-service的值为key到vgroupMapping中查找

2.2 动手实践

2.2.1 XA模式

 RM（资源管理器)一阶段的工作：

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

TC(事务协调者)二阶段的工作：

1. TC检测各分支事务执行状态
2. 如果都成功，通知所有RM提交事务
3. 如果有失败，通知所有RM回滚事务

RM二阶段的工作：

接收TC指令，提交或回滚事务

XA模式的优点是什么？

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

XA模式的缺点是什么？

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

实现XA模式

1.修改application.yml文件（每个参与事务的微服务），开启XA模式

seata:
  data-source-proxy-mode: XA

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

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

 

 可以看到在订单出错时，进行了回滚。并且数据库内数据也保持了一致性

2.2.2 AT模式

阶段一RM的工作：

1. 注册分支事务
2. 记录undo-log（数据快照）
3. 执行业务sql并提交
4. 报告事务状态

阶段二提交时RM的工作：

1. 删除undo-log即可

阶段二回滚时RM的工作：

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

简述AT模式与XA模式最大的区别是什么？

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

脏读问题：

 多线程操作时，未做到环境隔离，造成脏读。

全局锁：由TC记录当前正在操作某行数据的事务，该事务持有全局锁，具备执行权。

 

保存快照时会保存两份快照

 AT模式的优点：

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

AT模式的缺点：

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

实现AT模式：

AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单

 修改application.yml文件，将事务模式修改为AT模式即可：

seata:
  data-source-proxy-mode: AT

2.2.3 TCC模式

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

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

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

1. Try：资源检查和预留
2. Confirm：业务执行和提交
3. Cancel：预留资源的释放

TCC的优点是什么？

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

TCC的缺点是什么？

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

TCC的空回滚和业务悬挂

1. 当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
2. 对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel，这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂

实现TCC

TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明

@LocalTCC
public interface AccountTCCService {
    @TwoPhaseBusinessAction(name = "deduct",commitMethod = "confirm",rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId")String userId,
                @BusinessActionContextParameter(paramName = "money")int money);

    // 二阶段confirm确认方法、可以另命名，但要保证与commitMethod一致 
    boolean confirm(BusinessActionContext ctx);

    boolean cancel(BusinessActionContext ctx);
}

public class AcconutTCCServiceImpl implements AccountTCCService {

    @Autowired
    private AccountMapper accountMapper;

    @Autowired
    private AccountFreezeMapper accountFreezeMapper;

    @Override
    public void deduct(String userId, int money) {
        //0.获取事务id
        String xid = RootContext.getXID();
        //1.判断freeze中是否有冻结记录，如果有，一定是cancel执行过，我要拒绝业务
        AccountFreeze oldFreeze = accountFreezeMapper.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);
        accountFreezeMapper.insert(freeze);
    }

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

    @Override
    public boolean cancel(BusinessActionContext ctx) {
        //0.查询冻结记录
        String xid = ctx.getXid();
        String userId = ctx.getActionContext("userId").toString();
        AccountFreeze freeze = accountFreezeMapper.selectById(xid);
        //1.空回滚的判断，判断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);
            accountFreezeMapper.insert(freeze);
            return true;
        }
        //2.幂等判断
        if (freeze.getState() == AccountFreeze.State.CANCEL) {
            // 已经处理过一次cancel，无需重复处理
            return true;
        }
        //1.恢复可用余额
        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
        //2.将冻结金额清零，并状态改为CANCEL
        freeze.setFreezeMoney(0);
        freeze.setState(AccountFreeze.State.CANCEL);
        int count = accountFreezeMapper.updateById(freeze);
        return count == 1;
    }
}

2.2.4 Saga模式

Saga模式是SEATA提供的长事务解决方案。也分为两个阶段：

1. 一阶段：直接提交本地事务
2. 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

Saga模式优点：

1. 事务参与者可以基于事件驱动实现异步调用，
2. 吞吐高 一阶段直接提交事务，无锁，
3. 性能好 不用编写TCC中的三个阶段，实现简单

缺点：

1. 软状态持续时间不确定，时效性差
2. 没有锁，没有事务隔离，会有脏写

2.2.5 模式对比