【微服务系列笔记】Seata

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: Seata是一种开源的分布式事务解决方案,旨在解决分布式事务管理的挑战。它提供了高性能和高可靠性的分布式事务服务,支持XA、TCC、AT等多种事务模式,并提供了全局唯一的事务ID,以确保事务的一致性和隔离性。Seata还提供了分布式事务的协调、事务日志、事务恢复等功能,帮助开发人员简化分布式事务的管理和实现。

1. 分布式事务

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

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

在数据库水平拆分、服务垂直拆分之后,一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例,包括下面几个行为:

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

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务,可以保证ACID原则。

但是当我们把三件事情看做一个"业务",要满足保证“业务”的原子性,要么所有操作全部成功,要么全部失败,不允许出现部分成功部分失败的现象,这就是分布式系统下的事务了。此时有可能出现此种情况:当库存不足时,订单创建失败;但账户余额已经扣减,并不会回滚,此时就出现了分布式事务问题。

解决分布式事务问题,需要以下一些分布式系统的基础知识作为理论指导。

2. 理论

2.1. CAP原理

  • Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致
  • Availability(可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝
  • Partition tolerance (分区容错性):
  • Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
  • Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务

在分布式系统中,系统间的网络不能100%保证健康,一定会有故障的时候,而服务有必须对外保证服务。因此Partition Tolerance不可避免。

当节点接收到新的数据变更时,就会出现问题了:

如果此时要保证一致性,就必须等待网络恢复,完成数据同步后,整个集群才对外提供服务,服务处于阻塞状态,不可用。

如果此时要保证可用性,就不能等待网络恢复,那node01、node02与node03之间就会出现数据不一致。也就是说,在P一定会出现的情况下,A和C之间只能实现一个。

2.2. Base理论

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

2.3. 解决分布式事务的思路

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

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

但不管是哪一种模式,都需要在子系统事务之间互相通讯,协调事务状态,也就是需要一个事务协调者(TC)

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

2.4. 总结

简述CAP定理内容?

分布式系统节点通过网络连接,一定会出现分区问题(P)

当分区出现时,系统的一致性(C)和可用性(A)就无法同时满足

elasticsearch集群是CP还是AP?

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

Nacos作为注册中心和配置中心分别是什么模式?

作为配置中心时是CP,保证一致性

作为注册中心时是AP,保证可用性

3. Seata入门

3.1. 概述

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

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

Seata基于上述架构提供了四种不同的分布式事务解决方案:

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

模式

XA

AT

TCC

SAGA

一致性

强一致

弱一致

弱一致

最终一致

隔离性

完全隔离

基于全局锁隔离

基于资源预留隔离

无隔离

代码侵入

有,要编写三个接口

性能

非常好

非常好

非常好

场景

对一致性、隔离性有高要求的业务

基于关系型数据库的大多数分布式事务场景都可以

  • 对性能要求较高的事务
  • 有非关系型数据库要参与的事务。
  • 业务流程长、业务流程多
  • 参与者包含其它公司或遗留系统服务,无法提供TCC模式要求的三个接口

3.2. Seata部署TC

  1. 修改seata.conf
  2. nacos加配置
  3. 引依赖
  4. 本地加配置
registry {
  # tc服务的注册中心类,这里选择nacos,也可以是eureka、zookeeper等
  type = "nacos"
  nacos {
    # seata tc 服务注册到 nacos的服务名称,可以自定义
    application = "seata-tc-server"
    serverAddr = "127.0.0.1:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "SH"
    username = "nacos"
    password = "nacos"
  }
}
config {
  # 读取tc服务端的配置文件的方式,这里是从nacos配置中心读取,这样如果tc是集群,可以共享配置
  type = "nacos"
  # 配置nacos地址等信息
  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}
<!--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>
<dependency>
  <groupId>io.seata</groupId>
  <artifactId>seata-spring-boot-starter</artifactId>
  <!--seata starter 采用1.4.2版本-->
  <version>${seata.version}</version>
</dependency>
# 数据存储方式,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
seata:
  registry: # TC服务注册中心的配置,微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 127.0.0.1:8848 # nacos地址
      namespace: "" # namespace,默认为空
      group: DEFAULT_GROUP # 分组,默认是DEFAULT_GROUP
      application: seata-tc-server # seata服务名称
      username: nacos
      password: nacos
  tx-service-group: seata-demo # 事务组名称
  service:
    vgroup-mapping: # 事务组与cluster的映射关系
      seata-demo: SH

3.3. XA模式

流程

RM一阶段的工作:

① 注册分支事务到TC

② 执行分支业务sql但不提交

③ 报告执行状态到TC

TC二阶段的工作:

  • TC检测各分支事务执行状态a.如果都成功,通知所有RM提交事务b.如果有失败,通知所有RM回滚事务

RM二阶段的工作:

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

特点

XA模式的优点是什么?

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

XA模式的缺点是什么?

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

实现方式

  1. 方法加@GobalTransactional
  2. 修改配置

seata:

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

3.4. AT模式

流程

阶段一RM的工作:

  • 注册分支事务
  • 记录undo-log(数据快照)
  • 执行业务sql并提交
  • 报告事务状态

阶段二提交时RM的工作:

  • 删除undo-log即可

阶段二回滚时RM的工作:

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

特点

AT模式的优点:

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

AT模式的缺点:

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

实现方式

  1. 方法加@GobalTransactional
  2. 修改配置

seata:

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

seata事务与seata事务

一阶段

  1. 事务A获取DB锁,进行更新前快照;执行SQL;获取全局锁,并在TC插入一条记录(事务id,操作表table,主键pk),提交事务,并进行更新后快照,释放DB锁
  2. 事务B获取DB锁,进行更新前快照;执行SQL;获取全局锁,但因为TC存在记录,获取失败;采用乐观锁思想,进行30次重试,间隔10ms;获取全局锁失败,超时释放DB锁

二阶段

  1. 事务A获取DB锁,将更新后快照与当前数据库记录比对,若一致,则进行事务提交,删除快照;若不一致,则进行事务回滚,根据更新前快照恢复数据,并删除快照。

注意点:

当非seata事务与seata事务同时进行时,由于非seata事务没有获取全局锁;二阶段seata事务进行更新后快照比对失败后会进行记录异常,由人工介入。

3.5. TCC模式(难点)

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

  • Try:资源检查和预留
  • Confirm:业务执行和提交
  • Cancel:预留资源的释放

特点

TCC的优点是什么?

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

TCC的缺点是什么?

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

3.5.1. 空回滚与业务悬挂

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

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

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

3.5.2. 实现

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 javax.annotation.Resource;
import java.util.Objects;
import static cn.itcast.account.entity.AccountFreeze.State.CANCEL;
@Slf4j
@Service
public class AccountTCCServiceImpl implements AccountTCCService {
    @Autowired
    private AccountMapper accountMapper;
    @Resource
    private AccountFreezeMapper accountFreezeMapper;
    /**
     * TCC模式第一阶段Try
     *(1)扣减正常的account表的余额
     *(2)冻结资源:freeze——tbl
     * (3) 业务悬挂: try阶段cancel已经做了,
     *      我查找一次本地DB如果有一条状态为cancel的数据,就做业务悬挂
     * @param userId
     * @param money
     */
    @Override
    public void deduct(String userId, int money) {
        //获取事务id
        String xid = RootContext.getXID();
        //处理业务悬挂
        AccountFreeze freeze = accountFreezeMapper.selectById(xid);
        if (Objects.nonNull(freeze)) {
            // 说明并发场景下,别的线程提前执行完了try
            if (freeze.getState() == AccountFreeze.State.TRY ||
                // 真正的业务悬挂:尾巴比头先做
                freeze.getState() == CANCEL) {
                return;
            }
        }
        //1.扣减可用金额
        accountMapper.deduct(userId,money);
        //2.新增冻结资源
        AccountFreeze entity = new AccountFreeze();
        entity.setXid(xid);
        entity.setUserId(userId);
        entity.setFreezeMoney(money);
        entity.setState(AccountFreeze.State.TRY);
        accountFreezeMapper.insert(entity);
    }
    /**
     * 第二阶段confirm函数
     * (1)删除冻结资源-xid
     * (2) 幂等:多次相同操作返回相同的结果
     *  第一次:返回true,数据成功删除,符合预期
     *  第二次:返回false,数据没有删除成功说明已经被人删除了,所以我本身就可以不删除,符合预期
     *  N次:SQL执行异常,应该删除但是没删除所以返回false,刚好需要重试
     * @param context
     * @return
     */
    @Override
    public boolean confirm(BusinessActionContext context) {
        //1.删除冻结资源
        int rows = accountFreezeMapper.deleteById(context.getXid());
        //2.返回结果
        return rows == 1;
    }
    /**
     * 第二阶段cancel函数
     * (1)根据冻结资源恢复account表数据
     * (2)释放冻结资源
     * (3)空回滚: cancel阶段try没做
     * (4)幂等
     * @param context
     * @return
     */
    @Override
    public boolean cancel(BusinessActionContext context) {
        // 1-根据冻结资源恢复account表数据
        // 1.1 查找当前冻结资源信息
        AccountFreeze freeze = accountFreezeMapper.selectById(context.getXid());
        //空回滚
        if (Objects.isNull(freeze)) {
            AccountFreeze entity = new AccountFreeze();
            entity.setXid(context.getXid());
            entity.setUserId(context.getActionContext("userId").toString());
            entity.setFreezeMoney(0);
            entity.setState(CANCEL);
            accountFreezeMapper.insert(entity);
            return true;
        }
        //幂等
        if (freeze.getState() == CANCEL) {
            return true;
        }
        //1.2恢复数据
        String userId = freeze.getUserId();
        Integer money = freeze.getFreezeMoney();
        accountMapper.refund(userId,money);
        //2.释放冻结资源
        AccountFreeze updateEntity = new AccountFreeze();
        updateEntity.setXid(context.getXid());
        updateEntity.setState(CANCEL);
        updateEntity.setFreezeMoney(0);
        int rows = accountFreezeMapper.updateById(updateEntity);
        return rows == 1;
    }
}

资源怎么预留?

将传入的资源(userId,money)存在资源冻结表里,并标记执行状态(try,confirm,cannel)

怎么处理空回滚,业务悬挂以及幂等?

处理业务悬挂,先根据事务id查询资源冻结表,若查询结果不为空且状态为try,说明并发场景下其他线程先进行了try操作;若不为空且状态为cannel,说明发生了业务悬挂,两种情况直接return;

3.6. SAGA模式

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

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

Saga也分为两个阶段:

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

3.6.1. 特点

优点:

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

缺点:

  • 软状态持续时间不确定,时效性差
  • 没有锁,没有事务隔离,会有脏写

目录
相关文章
|
5天前
|
负载均衡 安全 Java
【微服务系列笔记】Gateway
Gateway是Spring Cloud生态系统中的网关服务,作为微服务架构的入口,提供路由、负载均衡、限流、鉴权等功能。借助于过滤器和路由器,Gateway能够动态地管理请求流量,保障系统的安全和性能。
38 7
|
5天前
|
Linux Docker 容器
【微服务系列笔记】Docker
docker是一种容器技术,它主要是用来解决软件跨环境迁移的问题和同一环境下依赖冲突问题。 Docker可以运行在Mac, Windows, linux等操作系统上,常用于适用于构建和部署分布式应用、微服务架构。
45 0
【微服务系列笔记】Docker
|
5天前
|
监控 Java 应用服务中间件
【微服务系列笔记】Sentinel入门-微服务保护
Sentinel是一个开源的分布式系统和应用程序的运维监控平台。它提供了实时数据收集、可视化、告警和自动化响应等功能,帮助用户监控和管理复杂的IT环境。本文简单介绍了微服务保护以及常见雪崩问题,解决方案。以及利用sentinel进行入门案例。
32 3
|
5天前
|
负载均衡 Java Apache
【微服务系列笔记】Feign
Feign是一个声明式的伪HTTP客户端,它使得HTTP请求变得更简单。使用Feign,只需要创建一个接口并注解。Feign默认集成了Ribbon,并和Eureka结合,默认实现了负载均衡的效果。 OpenFeign 是SpringCloud在Feign的基础上支持了SpringMVC的注解。
39 8
|
5天前
|
存储 负载均衡 Cloud Native
【微服务系列笔记】Nacos
Nacos 是阿里巴巴开源的项目,用于构建云原生应用的动态服务发现、配置管理和服务管理平台。它支持动态服务发现、服务配置、服务元数据和流量管理,旨在更敏捷和方便地构建、交付和管理微服务平台。可作为注册中心与配置中心。
45 5
|
5天前
|
Nacos 微服务
【微服务系列笔记】Eureka
该文档介绍了微服务注册中心的重要性和流行选项,如Eureka、Nacos、Consul和Zookeeper,强调Eureka是唯一支持跨区域调用的AP系统。接着,它提供了一个Eureka入门案例,包括设置Eureka服务器和客户端的步骤,并展示了多实例部署的效果。最后,简要总结了学习Eureka的意义,并提出了几个思考问题,如Eureka的功能、工作原理以及其他服务发现技术。
31 5
|
5天前
|
负载均衡 算法 应用服务中间件
【微服务系列笔记】负载均衡
本文介绍了负载均衡的概念和重要性,指出随着流量增长,通过垂直扩展和水平扩展来提升系统性能,其中水平扩展引入了负载均衡的需求。负载均衡的目标是将流量分布到多台服务器以提高响应速度和可用性,常见的硬件和软件负载均衡器包括F5、A10、Nginx、HAProxy和LVS等。 文章接着提到了Ribbon,这是一个客户端实现的负载均衡器,用于Spring Cloud中。Ribbon在发起REST请求时进行拦截,根据预设的负载均衡算法(如随机算法)选择服务器,并重构请求URI。文中还介绍了如何通过代码和配置文件两种方式自定义Ribbon的负载均衡策略。
42 3
|
5天前
|
存储 Java 数据库
【微服务系列笔记】微服务概述
本文对比了单体应用和微服务架构。单体应用中所有功能模块在一个工程中,而微服务则按领域模型拆分为独立服务,每个服务有明确边界,可独立开发、部署和扩展。微服务允许使用不同语言和技术栈,每个服务有自己的数据库。微服务架构的优点包括易于开发维护、技术栈开放和错误隔离,但缺点包括增加运维成本、调用链路复杂、分布式事务处理困难以及学习成本高。实现微服务通常涉及SpringCloud等开发框架和Docker等运行平台。
44 2
|
5天前
|
消息中间件 Java API
【微服务系列笔记】MQ消息可靠性
消息可靠性涉及防止丢失,包括生产者发送时丢失、未到达队列以及消费者消费失败处理后丢失。 确保RabbitMQ消息可靠性的方法有:开启生产者确认机制,确保消息到达队列;启用消息持久化以防止未消费时丢失;使用消费者确认机制,如设置为auto,由Spring确认处理成功后ack。此外,可开启消费者失败重试机制,多次失败后将消息投递到异常交换机。
42 1
|
5天前
|
Dubbo Java 应用服务中间件
已跪,Java全能笔记爆火,分布式/开源框架/微服务/性能调优全有
程序员,立之根本还是技术,一个程序员的好坏,虽然不能完全用技术强弱来判断,但是技术水平一定是基础,技术差的程序员只能CRUD,技术不深的程序员也成不了架构师。程序员对于技术的掌握,除了从了解-熟悉-熟练-精通的过程以外,还应该从基础出发,到进阶,到源码,到实战。所以,程序员想要成功,首先要成就自己。