分布式事务(基于Seata)

最新推荐文章于 2024-07-18 19:55:19 发布

白嫖勇者

最新推荐文章于 2024-07-18 19:55:19 发布

阅读量686

点赞数 24

文章标签：分布式

本文链接：https://blog.csdn.net/m0_61571886/article/details/137029656

版权

1.概念

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

1.CAP定理

Consistency(一致性):用户访问分布式系统中的任意节点，得到的数据必须一致。

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

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

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

2.BASE理论

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

1.Basically Available(基本可用):分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

2.Soft State(软状态):在一定时间内，允许出现中间状态，比如临时的不一致状态。

3.Eventually Consistent(最终一致性):虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

3.分布式事务模型

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

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

2.初识Seata

1.Seata架构

三个重要角色

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

2.TM(Transaction Manager)-事务管理器:定义全局事务的范围，开始全局事务，提交或回滚全局事务。

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

四种分布式事务解决方案

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

2.TCC模式:最终一致的分阶段事务模式，有业务侵入。

3.AT模式:最终一致性的分阶段事务模式，无业务侵入，也是Seata的默认模式

4.SAGA模式:长事务模式，有业务侵入

2.部署TC服务

1.下载Seata压缩包，解压

2.进入conf文件，修改registry.conf文件

registry {
  # 注册中心：file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "nacos"   # 选择注册中心

  nacos {     # 上面type配置了nacos，就会取这里的配置
    application = "seata-server"
    serverAddr = "127.0.0.1:8848"
    group = "SEATA_GROUP"   # 当前服务所在的组
    namespace = ""
    cluster = "default"      # 集群名称
    username = ""
    password = ""
  }
  eureka {
    serviceUrl = "http://localhost:8761/eureka"
    application = "default"
    weight = "1"
  }
  redis {
    serverAddr = "localhost:6379"
    db = 0
    password = ""
    cluster = "default"
    timeout = 0
  }
  zk {
    cluster = "default"
    serverAddr = "127.0.0.1:2181"
    sessionTimeout = 6000
    connectTimeout = 2000
    username = ""
    password = ""
  }
  consul {
    cluster = "default"
    serverAddr = "127.0.0.1:8500"
    aclToken = ""
  }
  etcd3 {
    cluster = "default"
    serverAddr = "http://localhost:2379"
  }
  sofa {
    serverAddr = "127.0.0.1:9603"
    application = "default"
    region = "DEFAULT_ZONE"
    datacenter = "DefaultDataCenter"
    cluster = "default"
    group = "SEATA_GROUP"
    addressWaitTime = "3000"
  }
  file {
    name = "file.conf"
  }
}

config {   # 配置文件
  # 配置中心：file、nacos 、apollo、zk、consul、etcd3
  type = "nacos"   # 把配置文件交给nacos管理

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = ""
    password = ""
    dataId = "seataServer.properties"
  }
  consul {
    serverAddr = "127.0.0.1:8500"
    aclToken = ""
  }
  apollo {
    appId = "seata-server"
    ## apolloConfigService will cover apolloMeta
    apolloMeta = "http://192.168.1.204:8801"
    apolloConfigService = "http://192.168.1.204:8080"
    namespace = "application"
    apolloAccesskeySecret = ""
    cluster = "seata"
  }
  zk {
    serverAddr = "127.0.0.1:2181"
    sessionTimeout = 6000
    connectTimeout = 2000
    username = ""
    password = ""
    nodePath = "/seata/seata.properties"
  }
  etcd3 {
    serverAddr = "http://localhost:2379"
  }
  file {
    name = "file.conf"
  }
}

4.在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://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=123
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

5.新建配置文件中指定的数据库和表

6.bin目录下执行seata-server.bat

3.微服务集成Seata

1.引入seata依赖

<!-- 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>
        <!--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:
  registry:
    type: nacos
    nacos:
      server-addr: localhost:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-server
      username: nacos
      password: nacos
  tx-service-group: seata-demo  # 事务组名称
  service:
    vgroup-mapping:  # 事务组与cluster的映射关系
      seata-demo: SH # 集群名称

4.XA模式

1.流程:

RM一阶段工作:

1.注册分支事务到TC

2.执行分支业务sql但不提交

3.报告执行状态到TC

TC二阶段的工作:

TC检测个分支事务执行状态

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

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

RM二阶段工作:

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

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

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

2.实现

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

seata:
  data-source-proxy-mode: XA

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

 @GlobalTransactional

3.重启服务

5.AT模式

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

1.流程

阶段一RM工作:

1.注册分支事务

2.记录undo-log(数据快照)

3.执行业务sql并提交

4.报告事务状态

阶段二提交时RM工作:

删除undo-log即可

阶段二回滚时RM的工作:

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

AR与XA区别:

1.XA模式一阶段不提交事务，锁定资源，AT模式一阶段直接提交，不锁定资源

2.XA模式依赖数据库机制实现回滚，AT模式利用数据快照实现数据回滚

3.XA模式强一致，AT模式最终一致

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

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

2.全局锁

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

3.实现

1.建立loca_table表在TC服务关联的数据库，undo_log表在微服务关联的数据库

2.修改application.yml文件，开启AT模式

seata:
  data-source-proxy-mode: AT

3.重启服务

6.TCC模式

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

1.Try:资源的检测和预留

2.Confirm:完成资源操作业务，要求Try成功Confirm一定要能成功

3.Cancel:预留资源释放，可以理解为try的方向操作

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

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

1.空回滚

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

2.业务悬挂

对于已经空回滚的业务，如果以后继续执行try,就永远不可能confirm或cancel,这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂。

3.实现

@LocalTCC
public interface AccountService {

    /*
    * Try逻辑，注解中的name属性必须与当前方法名一致，用于指定try逻辑对应的方法
    * */
    @TwoPhaseBusinessAction(name = "tryMethod", commitMethod = "confirm", rollbackMethod = "cancel")
    void tryMethod(@BusinessActionContextParameter(paramName = "param") String param);

    /*
    * 二阶段confirm确认方法，可以另命名，但要保证与commitMethod一致
    * 参数为上下文对象，可以通过该对象取到try逻辑中，上下文注解指定的参数，通过注解中的paramName属性值get到
    * */
    boolean confirm(BusinessActionContext businessActionContext);

    /*
    * 二阶段回滚方法，保证与rollbackMethod一致
    * */
    boolean cancel(BusinessActionContext businessActionContext);
}

public class AccountServiceImpl implements AccountService {
    @Override
    @Transactional // 出现异常自动回滚
    public void tryMethod(String param) {
        // 业务代码
    }

    @Override
    public boolean confirm(BusinessActionContext businessActionContext) {
        return false;
    }

    @Override
    public boolean cancel(BusinessActionContext businessActionContext) {
        return false;
    }
}

7.Saga模式

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

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

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

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

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

8.对比

	XA	AT	TCC	SAGA
一致性	强一致	弱一致	弱一致	最终一致
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有，要编写三个接口	有，要编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性，隔离性有高要求的业务	基于关系型数据库的大多数分布式事务场景都可以	对性能要求较高的事务有非关系型数据库要参与的事务	业务流程长，业务流程多参与者包含其它公司或遗留系统服务，无法提供TCC模式要求的三个接口