装潢设计网站,国家网站域名,网络公司名字大全,ap课程培训哪家机构好目录 1.微服务保护 1.1.服务保护方案 1.1.1 请求限流 1.1.2 线程隔离 1.1.3 服务熔断 1.2 Sentinel 1.2.1.介绍和安装 1.2.2 微服务整合 1.2.2.1 引入sentinel依赖 1.2.2.2 配置控制台 1.2.2.3 访问cart-service的任意端点 1.3 请求限流 1.4 线程隔离 1.4.1 OpenFeign整合Senti… 目录 1.微服务保护 1.1.服务保护方案 1.1.1 请求限流 1.1.2 线程隔离 1.1.3 服务熔断 1.2 Sentinel 1.2.1.介绍和安装 1.2.2 微服务整合 1.2.2.1 引入sentinel依赖 1.2.2.2 配置控制台 1.2.2.3 访问cart-service的任意端点 1.3 请求限流 1.4 线程隔离 1.4.1 OpenFeign整合Sentinel 1.4.2 配置线程隔离 1.5.服务熔断 1.5.1 编写降级逻辑fallback 1.5.2 服务熔断 2.分布式事务 2.1 认识Seata 2.2 部署TC微服务 2.2.1 准备数据库表 2.2.2 准备配置文件 2.2.3 Docker部署 2.3 微服务集成Seata 2.3.1.引入依赖 2.3.2.改造配置 2.3.3 添加数据库表 2.3.4 测试 2.4 XA模式 2.4.1 两阶段提交 2.4.2 Seata的XA模型 2.4.3 优缺点 2.4.4 实现步骤 2.5 AT模式 2.5.1 Seata的AT模型 2.5.2 流程梳理 2.5.3 AT与XA的区别 思维导图 1.微服务保护 保证服务运行的健壮性避免级联失败导致的雪崩问题就属于微服务保护。 1.1.服务保护方案 微服务保护的方案有很多比如 请求限流 线程隔离 服务熔断 这些方案或多或少都会导致服务的体验上略有下降比如请求限流降低了并发上限线程隔离降低了可用资源数量服务熔断降低了服务的完整度部分服务变的不可用或弱可用。因此这些方案都属于服务降级的方案。但通过这些方案服务的健壮性得到了提升 1.1.1 请求限流 服务故障最重要原因就是并发太高解决了这个问题就能避免大部分故障。当然接口的并发不是一直很高而是突发的。因此请求限流就是限制或控制接口访问的并发流量避免服务因流量激增而出现故障。 请求限流往往会有一个限流器数量高低起伏的并发请求曲线经过限流器就变的非常平稳。 1.1.2 线程隔离 当一个业务接口响应时间长而且并发高时就可能耗尽服务器的线程资源导致服务内的其它接口受到影响。所以我们必须把这种影响降低或者缩减影响的范围。线程隔离正是解决这个问题的好办法。 线程隔离为了避免服务器的线程资源被某个接口全部占用导致其他接口拿不到线程资源而引起的访问异常。 如图所示我们给查询购物车业务限定可用线程数量上限为20这样即便查询购物车的请求因为查询商品服务而出现故障也不会导致服务器的线程资源被耗尽不会影响到其它接口。 1.1.3 服务熔断 线程隔离虽然避免了雪崩问题但故障服务商品服务依然会拖慢购物车服务服务调用方的接口响应速度。 服务熔断对异常或者慢接口进行统计超过阈值就熔断接口此时在熔断的时间内会拒绝该接口的所有请求。 所以我们要做两件事情 编写服务降级逻辑就是服务调用失败后的处理逻辑根据业务场景可以抛出异常也可以返回友好提示或默认数据fallback逻辑。 异常统计和熔断统计服务提供方的异常比例当异常比例过高表明该接口会影响到其它服务应该拒绝调用该接口而是直接走降级逻辑。 熔断了 就进入fallback了 fangback 返回了 空集合 所以前端显示null。 1.2 Sentinel 1.2.1.介绍和安装 Sentinel是一款服务保护框架目前已经加入SpringCloudAlibaba中。
官方网站https://sentinelguard.io/zh-cn/ Sentinel 的使用可以分为两个部分: 核心库Jar包不依赖任何框架/库能够运行于 Java 8 及以上的版本的运行时环境同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。 控制台DashboardDashboard 主要负责管理推送规则、监控、管理机器信息等。 为了方便监控微服务我们先把Sentinel的控制台搭建出来。
1下载jar包
下载地址https://github.com/alibaba/Sentinel/releases 也可以直接使用课前资料提供的版本 2运行
将jar包放在任意非中文、不包含特殊字符的目录下然后运行如下命令启动控制台
java -Dserver.port8090 -Dcsp.sentinel.dashboard.serverlocalhost:8090 -Dproject.namesentinel-dashboard -jar sentinel-dashboard.jar 其它启动时可配置参数可参考官方文档https://github.com/alibaba/Sentinel/wiki/%E5%90%AF%E5%8A%A8%E9%85%8D%E7%BD%AE%E9%A1%B9 3访问
访问http://localhost:8090页面就可以看到sentinel的控制台了 需要输入账号和密码默认都是sentinel。
登录后即可看到控制台默认会监控sentinel-dashboard服务本身 1.2.2 微服务整合 我们在cart-service模块中整合sentinel连接sentinel-dashboard控制台步骤如下 1.2.2.1 引入sentinel依赖 !--sentinel--
dependencygroupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId
/dependency 1.2.2.2 配置控制台 修改application.yaml文件添加下面内容
spring:cloud: sentinel:transport:dashboard: localhost:8090 1.2.2.3 访问cart-service的任意端点 重启cart-service然后访问查询购物车接口sentinel的客户端就会将服务访问的信息提交到sentinel-dashboard控制台。并展示出统计信息 点击簇点链路菜单会看到下面的页面 簇点链路就是单机调用链路是一次请求进入服务后经过的每一个被Sentinel监控的资源。
默认情况下Sentinel会监控SpringMVC的每一个Endpoint接口。
因此我们看到/carts这个接口路径就是其中一个簇点可以对其进行限流、熔断、隔离等保护措施。 注意事项SpringMVC接口是按照Restful风格设计因此购物车的查询、删除、修改等接口全部都是/carts路径 默认情况下Sentinel会把路径作为簇点资源的名称无法区分路径相同但请求方式不同的接口查询、删除、修改等都被识别为一个簇点资源这显然是不合适的。 所以我们可以选择打开Sentinel的请求方式前缀把请求方式 请求路径作为簇点资源名
首先在cart-service的application.yml中添加下面的配置
spring:cloud:sentinel:transport:dashboard: localhost:8090http-method-specify: true # 开启请求方式前缀 然后重启服务通过页面访问购物车的相关接口可以看到sentinel控制台的簇点链路发生了变化 1.3 请求限流 在簇点链路后面点击流控按钮即可对其做限流配置 在弹出的菜单中这样填写 这样就把查询购物车列表这个簇点资源的流量限制在了每秒6个也就是最大QPS为6。 定义 QPSQueries Per Second每秒查询率是对服务器在规定时间内所处理流量多少的衡量标准。并发线程数指的是在同一时刻系统中正在运行的线程数量。在服务器环境下线程是处理请求的基本执行单元并发线程数体现了系统同时处理多个任务的能力。 计算方式 QPS 计算方式通常通过统计一段时间内如 1 秒成功处理的请求数量来计算。例如在 10 秒内服务器成功处理了 100 个请求那么平均 QPS 就是 100/10 10。它更关注系统的处理能力和吞吐量重点在于单位时间内系统能够完成的任务数量。5个并发线程如果单线程的QPS为2则5个线程的QPS则为10。并发线程数计算方式通过统计系统中同时处于运行状态的线程数量来确定。它更关注系统资源的分配和利用情况例如 CPU、内存等资源在多个线程之间的分配。如果系统中有 10 个线程同时在运行那么并发线程数就是 10。 我们利用Jemeter做限流测试我们每秒发出10个请求 最终监控结果如下 可以看出GET:/carts这个接口的通过QPS稳定在6附近而拒绝的QPS在4附近符合我们的预期。 1.4 线程隔离 限流可以降低服务器压力尽量减少因并发流量引起的服务故障的概率但并不能完全避免服务故障。一旦某个服务出现故障我们必须隔离对这个服务的调用避免发生雪崩。 比如查询购物车的时候需要查询商品为了避免因商品服务出现故障导致购物车服务级联失败我们可以把购物车业务中查询商品的部分隔离起来限制可用的线程资源 这样即便商品服务出现故障最多导致查询购物车业务故障并且可用的线程资源也被限定在一定范围不会导致整个购物车服务崩溃。 没有做线程隔离的结果 在Item-service的查询商品添加休眠时间 Jmeter 没开启Jmeter前测试 开启Jmeter后测试 在高并发的情况下该服务下的其他接口也会受到影响原因就是tomcat资源被耗尽。 做了线程隔离 超出的QPS上限的请求就只能抛出异常从而导致购物车的查询失败。 接下来我们要对查询商品的FeignClient接口做线程隔离。 1.4.1 OpenFeign整合Sentinel 修改cart-service模块的application.yml文件开启Feign的sentinel功能
默认只扫描SpringMVC的接口因此要配置一下
feign:sentinel:enabled: true # 开启feign对sentinel的支持 注意事项默认情况下SpringBoot项目的tomcat最大线程数是200允许的最大连接是8492单机测试很难打满。 所以我们需要配置一下cart-service模块的application.yml文件修改tomcat连接
server:port: 8082tomcat:threads:max: 25 # 允许的最大线程数accept-count: 25 # 最大排队等待数量max-connections: 100 # 允许的最大连接 然后重启cart-service服务可以看到查询商品的FeignClient自动变成了一个簇点资源 1.4.2 配置线程隔离 接下来点击查询商品的FeignClient对应的簇点资源后面的流控按钮 在弹出的表单中填写下面内容 注意事项这里勾选的是并发线程数限制也就是说这个查询功能最多使用5个线程而不是5QPS。如果查询商品的接口每秒处理2个请求则5个线程的实际QPS在10左右而超出的请求自然会被拒绝。 我们利用Jemeter测试每秒发送100个请求 最终测试结果如下 进入查询购物车的请求每秒大概在100而在查询商品时却只剩下每秒10左右符合我们的预期。 此时如果我们通过页面访问购物车的其它接口例如添加购物车、修改购物车商品数量发现不受影响 响应时间非常短这就证明线程隔离起到了作用尽管查询购物车这个接口并发很高但是它能使用的线程资源被限制了因此不会影响到其它接口。 做了线程隔离 超出的QPS上限的请求就只能抛出异常从而导致购物车的查询失败。 1.5.服务熔断 在上节课我们利用线程隔离对查询购物车业务进行隔离保护了购物车服务的其它接口。由于查询商品的功能耗时较高我们模拟了500毫秒延时再加上线程隔离限定了线程数为5导致接口吞吐能力有限最终QPS只有10左右。 这就导致了几个问题
1、超出的QPS上限的请求就只能抛出异常从而导致购物车的查询失败。但从业务角度来说即便没有查询到最新的商品信息购物车也应该展示给用户用户体验更好。也就是给查询失败设置一个降级处理逻辑。
2、由于查询商品的延迟较高模拟的500ms从而导致查询购物车的响应时间也变的很长。这样不仅拖慢了购物车服务消耗了购物车服务的更多资源而且用户体验也很差。对于商品服务这种不太健康的接口我们应该直接停止调用直接走降级逻辑避免影响到当前服务。也就是将商品查询接口熔断。 1.5.1 编写降级逻辑fallback 触发限流或熔断后的请求不一定要直接报错也可以返回一些默认数据或者友好提示用户体验会更好。
给FeignClient编写失败后的降级逻辑有两种方式 方式一FallbackClass无法对远程调用的异常做处理 方式二FallbackFactory可以对远程调用的异常做处理我们一般选择这种方式。 这里我们演示方式二的失败降级处理。 步骤一在hm-api模块中给ItemClient定义降级处理类实现FallbackFactory 代码如下
fallback逻辑查询购物车允许失败查询失败返回空集合。 Slf4j
public class ItemClientFallback implements FallbackFactoryItemClient {Overridepublic ItemClient create(Throwable cause) {return new ItemClient() {Overridepublic ListItemDTO queryItemByIds(CollectionLong ids) {log.error(远程调用ItemClient#queryItemByIds方法出现异常参数{}, ids, cause);// 查询购物车允许失败查询失败返回空集合return CollUtils.emptyList();}Overridepublic void deductStock(ListOrderDetailDTO items) {// 库存扣减业务需要触发事务回滚查询失败抛出异常throw new BizIllegalException(cause);}};}
} 步骤二在hm-api模块中的com.hmall.api.config.DefaultFeignConfig类中将ItemClientFallback注册为一个Bean 步骤三在hm-api模块中的ItemClient接口中使用ItemClientFallbackFactory 重启后再次测试发现被限流的请求不再报错走了降级逻辑 但是未被限流的请求延时依然很高 导致最终的平局响应时间较长。 1.5.2 服务熔断 查询商品的RT较高模拟的500ms从而导致查询购物车的RT也变的很长。这样不仅拖慢了购物车服务消耗了购物车服务的更多资源而且用户体验也很差。
对于商品服务这种不太健康的接口我们应该停止调用直接走降级逻辑避免影响到当前服务。也就是将商品查询接口熔断。当商品服务接口恢复正常后再允许调用。这其实就是断路器的工作模式了。 Sentinel中的断路器不仅可以统计某个接口的慢请求比例还可以统计异常请求比例。当这些比例超出阈值时就会熔断该接口即拦截访问该接口的一切请求降级处理当该接口恢复正常时再放行对于该接口的请求。 断路器的工作状态切换有一个状态机来控制 状态机包括三个状态 closed关闭状态断路器放行所有请求并开始统计异常比例、慢请求比例。超过阈值则切换到open状态 open打开状态服务调用被熔断访问被熔断服务的请求会被拒绝快速失败直接走降级逻辑。Open状态持续一段时间后会进入half-open状态 half-open半开状态放行一次请求根据执行结果来判断接下来的操作。 请求成功则切换到closed状态 请求失败则切换到open状态 我们可以在控制台通过点击簇点后的熔断按钮来配置熔断策略 在弹出的表格中这样填写 这种是按照慢调用比例来做熔断上述配置的含义是 RT超过200毫秒的请求调用就是慢调用 统计最近1000ms内的最少5次请求如果慢调用比例不低于0.5则触发熔断 熔断持续时长20s 配置完成后再次利用Jemeter测试可以发现 在一开始一段时间是允许访问的后来触发熔断后查询商品服务的接口通过QPS直接为0所有请求都被熔断了。而查询购物车的本身并没有受到影响。 此时整个购物车查询服务的平均RT影响不大 2.分布式事务 首先我们看看项目中的下单业务整体流程 应用场景由于订单、购物车、商品分别在三个不同的微服务而每个微服务都有自己独立的数据库因此下单过程中就会跨多个数据库完成业务。 而每个微服务都会执行自己的本地事务 交易服务下单事务 购物车服务清理购物车事务 库存服务扣减库存事务
整个业务中各个本地事务是有关联的。因此每个微服务的本地事务也可以称为分支事务。多个有关联的分支事务一起就组成了全局事务。因此我们必须保证整个全局事务同时成功或失败。 问题每一个分支事务就是传统的单体事务都可以满足ACID特性但全局事务跨越多个服务、多个数据库是否还能满足ACID呢 我们来做一个测试先进入购物车页面 目前有4个购物车然结算下单进入订单结算页面 然后将购物车中某个商品的库存修改为0 然后提交订单最终因库存不足导致下单失败 然后我们去查看购物车列表发现购物车数据依然被清空了并未回滚 答案事务并未遵循ACID的原则归其原因就是参与事务的多个子业务在不同的微服务跨越了不同的数据库。虽然每个单独的业务都能在本地遵循ACID但是它们互相之间没有感知不知道有人失败了无法保证最终结果的统一也就无法遵循ACID的事务特性了。 这就是分布式事务问题出现以下情况之一就可能产生分布式事务问题 业务跨多个服务实现 业务跨多个数据源实现 接下来我们就一起来研究下如何解决分布式事务问题。 2.1 认识Seata 解决分布式事务的方案有很多在众多的开源分布式事务框架中功能最完善、使用最多的就是阿里巴巴在2019年开源的Seata了。 官方地址https://seata.apache.org/zh-cn/docs/overview/what-is-seata/ 其实分布式事务产生的一个重要原因就是参与事务的多个分支事务互相无感知不知道彼此的执行状态。 解决分布式事务的思想
就是找一个统一的事务协调者与多个分支事务通信检测每个分支事务的执行状态保证全局事务下的每一个分支事务同时成功或失败即可。大多数的分布式事务框架都是基于这个理论来实现的。 Seata也不例外在Seata的事务管理中有三个重要的角色 TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态协调全局事务提交或回滚。 TM (Transaction Manager) - 事务管理器定义全局事务的范围、开始全局事务、提交或回滚全局事务。 RM (Resource Manager) - 资源管理器管理分支事务与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。 Seata的工作架构如图所示 其中TM和RM可以理解为Seata的客户端部分引入到参与事务的微服务依赖中即可。将来TM和RM就会协助微服务实现本地分支事务与TC之间交互实现事务的提交或回滚。 而TC服务则是事务协调中心是一个独立的微服务需要单独部署。 2.2 部署TC微服务 2.2.1 准备数据库表 Seata支持多种存储模式但考虑到持久化的需要我们一般选择基于数据库存储。执行课前资料提供的《seata-tc.sql》导入数据库表 branch_table是分支事务表存储分支事务执行情况。
global_table是全局事务表存储全局的事务信息。 2.2.2 准备配置文件 课前资料准备了一个seata目录其中包含了seata运行时所需要的配置文件 application.yml
server:port: 7099spring:application:name: seata-serverlogging:config: classpath:logback-spring.xmlfile:path: ${user.home}/logs/seata# extend:# logstash-appender:# destination: 127.0.0.1:4560# kafka-appender:# bootstrap-servers: 127.0.0.1:9092# topic: logback_to_logstashconsole:user:username: adminpassword: adminseata:config:# support: nacos, consul, apollo, zk, etcd3type: file# nacos:# server-addr: nacos:8848# group : DEFAULT_GROUP# namespace: # dataId: seataServer.properties# username: nacos# password: nacosregistry:# support: nacos, eureka, redis, zk, consul, etcd3, sofatype: nacosnacos:application: seata-serverserver-addr: nacos:8848group : DEFAULT_GROUPnamespace: username: nacospassword: nacos
# server:
# service-port: 8091 #If not configured, the default is ${server.port} 1000security:secretKey: SeataSecretKey0c382ef121d778043159209298fd40bf3850a017tokenValidityInMilliseconds: 1800000ignore:urls: /,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.ico,/console-fe/public/**,/api/v1/auth/loginserver:# service-port: 8091 #If not configured, the default is ${server.port} 1000max-commit-retry-timeout: -1max-rollback-retry-timeout: -1rollback-retry-timeout-unlock-enable: falseenable-check-auth: trueenable-parallel-request-handle: trueretry-dead-threshold: 130000xaer-nota-retry-timeout: 60000enableParallelRequestHandle: truerecovery:committing-retry-period: 1000async-committing-retry-period: 1000rollbacking-retry-period: 1000timeout-retry-period: 1000undo:log-save-days: 7log-delete-period: 86400000session:branch-async-queue-size: 5000 #branch async remove queue sizeenable-branch-async-remove: false #enable to asynchronous remove branchSessionstore:# support: file 、 db 、 redismode: dbsession:mode: dblock:mode: dbdb:datasource: druiddb-type: mysqldriver-class-name: com.mysql.cj.jdbc.Driverurl: jdbc:mysql://mysql:3306/seata?rewriteBatchedStatementstrueserverTimezoneUTCuser: rootpassword: 123min-conn: 10max-conn: 100global-table: global_tablebranch-table: branch_tablelock-table: lock_tabledistributed-lock-table: distributed_lockquery-limit: 1000max-wait: 5000# redis:# mode: single# database: 0# min-conn: 10# max-conn: 100# password:# max-total: 100# query-limit: 1000# single:# host: 192.168.150.101# port: 6379metrics:enabled: falseregistry-type: compactexporter-list: prometheusexporter-prometheus-port: 9898transport:rpc-tc-request-timeout: 15000enable-tc-server-batch-send-response: falseshutdown:wait: 3thread-factory:boss-thread-prefix: NettyBossworker-thread-prefix: NettyServerNIOWorkerboss-thread-size: 1我们将整个seata文件夹拷贝到虚拟机的/root目录 2.2.3 Docker部署 注意事项要确保nacos、mysql都在hm-net网络中因为配置都是利用容器名来映射地址因此需要在同一个网络才能相互访问。 如果某个容器不再hm-net网络可以参考下面的命令将某容器加入指定网络
docker network connect [网络名] [容器名] 在虚拟机的/root目录执行下面的命令
docker run --name seata \
-p 8099:8099 \
-p 7099:7099 \
-e SEATA_IP192.168.150.101 \
-v ./seata:/seata-server/resources \
--privilegedtrue \
--network hm-net \
-d \
seataio/seata-server:1.5.2 如果镜像下载困难也可以把课前资料提供的镜像上传到虚拟机并加载 2.3 微服务集成Seata 参与分布式事务的每一个微服务都需要集成Seata我们以trade-service为例。 注意事项nacos访问不了的重启一下就可以了。 2.3.1.引入依赖 为了方便各个微服务集成seata我们需要把seata配置共享到nacos因此trade-service模块不仅仅要引入seata依赖还要引入nacos依赖:
!--统一配置管理--dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-config/artifactId/dependency!--读取bootstrap文件--dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-bootstrap/artifactId/dependency!--seata--dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-seata/artifactId/dependency 2.3.2.改造配置 首先在nacos上添加一个共享的seata配置命名为shared-seata.yaml 内容如下
seata:registry: # TC服务注册中心的配置微服务根据这些信息去注册中心获取tc服务地址type: nacos # 注册中心类型 nacosnacos:server-addr: 192.168.150.101:8848 # nacos地址namespace: # namespace默认为空group: DEFAULT_GROUP # 分组默认是DEFAULT_GROUPapplication: seata-server # seata服务名称username: nacospassword: nacostx-service-group: hmall # 事务组名称service:vgroup-mapping: # 事务组与tc集群的映射关系hmall: default 然后改造trade-service模块添加bootstrap.yaml 内容如下:
spring:application:name: trade-service # 服务名称profiles:active: devcloud:nacos:server-addr: 192.168.150.101 # nacos地址config:file-extension: yaml # 文件后缀名shared-configs: # 共享配置- dataId: shared-jdbc.yaml # 共享mybatis配置- dataId: shared-log.yaml # 共享日志配置- dataId: shared-swagger.yaml # 共享日志配置- dataId: shared-seata.yaml # 共享seata配置 可以看到这里加载了共享的seata配置。
然后改造application.yaml文件内容如下
server:port: 8085
feign:okhttp:enabled: true # 开启OKHttp连接池支持sentinel:enabled: true # 开启Feign对Sentinel的整合
hm:swagger:title: 交易服务接口文档package: com.hmall.trade.controllerdb:database: hm-trade 参考上述办法分别改造hm-cart和hm-item两个微服务模块。同时记得加依赖。 2.3.3 添加数据库表 seata的客户端在解决分布式事务的时候需要记录一些中间数据保存在数据库中。因此我们要先准备一个这样的表。
将课前资料的seata-at.sql分别文件导入hm-trade、hm-cart、hm-item三个数据库中 结果 OK至此为止微服务整合的工作就完成了。 2.3.4 测试 接下来就是测试的分布式事务的时候了。
我们找到trade-service模块下的com.hmall.trade.service.impl.OrderServiceImpl类中的createOrder方法也就是下单业务方法。
将其上的Transactional注解改为Seata提供的GlobalTransactional GlobalTransactional注解就是在标记事务的起点将来TM就会基于这个方法判断全局事务范围初始化全局事务。 我们重启trade-service、item-service、cart-service三个服务。再次测试发现分布式事务的问题解决了 高版本jdk启动服务报错解决方法Edit Configuration 添加Vm Option --add-opens java.base/java.langALL-UNNAMED CartApplication 可以看到事务回滚并不会删除购物车信息。 那么Seata是如何解决分布式事务的呢
答案seata默认的模式是AT模式上面已经加了AT模式的undo表这里走的是默认的分布式事务模式。 2.4 XA模式 Seata支持四种不同的分布式事务解决方案 XA TCC AT SAGA
这里我们以XA模式和AT模式来给大家讲解其实现原理。 XA 规范 是分布式事务处理标准XA 规范 描述了全局的TM与局部的RM之间的接口几乎所有主流的数据库都对 XA 规范 提供了支持。 2.4.1 两阶段提交 A是规范目前主流数据库都实现了这种规范实现的原理都是基于两阶段提交。 正常情况 异常情况 一阶段 事务协调者通知每个事务参与者执行本地事务 本地事务执行完成后报告事务执行状态给事务协调者此时事务不提交继续持有数据库锁 二阶段 事务协调者基于一阶段的报告来判断下一步操作 如果一阶段都成功则通知所有事务参与者提交事务 如果一阶段任意一个参与者失败则通知所有事务参与者回滚事务 2.4.2 Seata的XA模型 Seata对原始的XA模式做了简单的封装和改造以适应自己的事务模型基本架构如图 RM一阶段的工作 注册分支事务到TC 执行分支业务sql但不提交 报告执行状态到TC TC二阶段的工作 TM全局事务执行结束TC检测各分支事务执行状态 如果都成功通知所有RM提交事务 如果有失败通知所有RM回滚事务 RM二阶段的工作 接收TC指令提交或回滚事务 2.4.3 优缺点 XA模式的优点是什么 事务的强一致性满足ACID原则 常用数据库都支持实现简单并且没有代码侵入 XA模式的缺点是什么 因为一阶段需要锁定数据库资源等待二阶段结束才释放性能较差 依赖关系型数据库实现事务 2.4.4 实现步骤 首先我们要在配置文件中指定要采用的分布式事务模式。我们可以在Nacos中的共享shared-seata.yaml配置文件中追加一下配置
seata:data-source-proxy-mode: XA
默认情况下是AT模式。 seata:registry: # TC服务注册中心的配置微服务根据这些信息去注册中心获取tc服务地址type: nacos # 注册中心类型 nacosnacos:server-addr: 192.168.85.144:8848 # nacos地址namespace: # namespace默认为空group: DEFAULT_GROUP # 分组默认是DEFAULT_GROUPapplication: seata-server # seata服务名称username: nacospassword: nacostx-service-group: hmall # 事务组名称service:vgroup-mapping: # 事务组与tc集群的映射关系hmall: defaultdata-source-proxy-mode: XA # XA模式 其次我们要利用GlobalTransactional标记分布式事务的入口方法
这个注解相当于全局事务该方法里面有许多分支事务。 2.5 AT模式 AT模式同样是分阶段提交的事务模型不过缺弥补了XA模型中资源锁定周期过长的缺陷。 2.5.1 Seata的AT模型 基本流程图 阶段一RM的工作 注册分支事务 记录undo-log数据快照 执行业务sql并提交 报告事务状态 阶段二RM的工作 事务状态都成功则删除undo-log即可 事务有其一的失败则根据undo-log恢复数据到更新前 AT模型的优缺点
优点性能高因为直接提交事务而不用锁定资源。
缺点阶段一记录快照信息如果分支事务失败则阶段二根据快照信息回滚事务。这之间有短暂的数据不一致问题。 2.5.2 流程梳理 我们用一个真实的业务来梳理下AT模式的原理。
比如现在有一个数据库表记录用户余额 其中一个分支业务要执行的SQL为 update tb_account set money money - 10 where id 1 AT模式下当前分支事务执行流程如下 一阶段 TM发起并注册全局事务到TC TM调用分支事务 分支事务准备执行业务SQL RM拦截业务SQL根据where条件查询原始数据形成快照。 {id: 1, money: 100
} RM执行业务SQL提交本地事务释放数据库锁。此时 money 90 RM报告本地事务状态给TC 二阶段 TM通知TC事务结束 TC检查分支事务状态 如果都成功则立即删除快照 如果有分支事务失败需要回滚。读取快照数据{id: 1, money: 100}将快照恢复到数据库。此时数据库再次恢复为100 流程图 2.5.3 AT与XA的区别 简述AT模式与XA模式最大的区别是什么 XA模式一阶段不提交事务锁定资源AT模式一阶段直接提交不锁定资源。 XA模式依赖数据库机制实现回滚AT模式利用数据快照实现数据回滚。 XA模式强一致AT模式最终一致 可见AT模式使用起来更加简单无业务侵入性能更好。因此企业90%的分布式事务都可以用AT模式来解决。
