网关服务限流熔断降级&分布式事务

目录

网关服务限流熔断降级

Seata--分布式事务

分布式事务基础

事务

本地事物

分布式事务

分布式事务的场景

分布式事务解决方案

全局事务

可靠消息服务

最大努力通知

TCC事务

Seata介绍

Seata实现分布式事务控制

案例基本代码（异常模拟）

启动Seata

使用Seata实现事务控制

seata运行流程分析

---

网关服务限流熔断降级

第1步：启动sentinel-dashboard控制台和Nacos注册中心服务

第2步：在网关服务中引入sentinel依赖

<!-- sentinel -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

第3步：在网关服务application.yml中配置sentinel

spring:
  application:
    name: zmall-gateway
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
    sentinel:
      transport:
        port: 9998 #跟控制台交流的端口,随意指定一个未使用的端口即可
        dashboard: localhost:8080 # 指定控制台服务的地址
      eager: true #当服务启动时是否与sentinel建立连接
      web-context-unify: false # 关闭URL PATH聚合

第4步：通过域名直接访问商品服务，并登陆到sentinel控制台配置服务流控等信息

打开浏览器输入地址：http://zmall.com/index.html

进入sentinel控制台，选中簇点链路。在搜索框中输入搜索关键字index

 

这个时候会发现流控操作只能针对具体服务资源链路，而不能针对具体整个服务本身进行流控操作。所以，阿里特此推出了网关限流方式来解决以上问题。

第5步：重新在网关服务模块pom.xml中加入依赖

<!-- sentinel gateway -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>

第6步：重新刷新商品服务，再进入sentinel控制台查看链路情况

 

这是直接针对该微服务进行网关限流等操作。直接点击流控，设置QPS=1、流控模式=直接（默认）、流控效果=快速失败（默认）等，最后快速刷新商品服务地址即可查看流控效果。同时，也可以配置流控的流控效果为排队等待方式，当流量多大时以排队等待方式慢慢去消化请求，从而可以起到一个流量削锋的目的。

Seata--分布式事务

分布式事务基础

事务

事务指的就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作 都成功，要么所有的操作都被撤销。简单地说，事务提供一种“要么什么都不做，要么做全套”机制。

本地事物

本地事物其实可以认为是数据库提供的事务机制。说到数据库事务就不得不说，数据库事务中的四 大特性:

• A：原子性(Atomicity)，一个事务中的所有操作，要么全部完成，要么全部不完成

• C：一致性(Consistency)，在一个事务执行之前和执行之后数据库都必须处于一致性状态

• I：隔离性(Isolation)，在并发环境中，当不同的事务同时操作相同的数据时，事务之间互不影响

• D：持久性(Durability)，指的是只要事务成功结束，它对数据库所做的更新就必须永久的保存下来

数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单 元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚

分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布 式系统的不同节点之上。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同 的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。 本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

分布式事务的场景

• 单体系统访问多个数据库 一个服务需要调用多个数据库实例完成数据的增删改操作

• 

   

• 多个微服务访问同一个数据库 多个服务需要调用一个数据库实例完成数据的增删改操作

• 

   

• 多个微服务访问多个数据库 多个服务需要调用一个数据库实例完成数据的增删改操作

• 

   

分布式事务解决方案

全局事务

全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务，需要三种角色：

• AP: Application 应用系统 (微服务)

• TM: Transaction Manager 事务管理器 (全局事务管理)

• RM: Resource Manager 资源管理器 (数据库)

整个事务分成两个阶段:

• 阶段一: 表决阶段，所有参与者都将本事务执行预提交，并将能否成功的信息反馈发给协调者。

• 阶段二: 执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地执行提交或者回 滚。

• 

   

优点

• 提高了数据一致性的概率，实现成本较低

缺点

• 单点问题: 事务协调者宕机

• 同步阻塞: 延迟了提交时间，加长了资源阻塞时间

• 数据不一致: 提交第二阶段，依然存在commit结果未知的情况，有可能导致数据不一致

  可靠消息服务

  基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。假设有A和B两个 系统，分别可以处理任务A和任务B。此时存在一个业务流程，需要将任务A和任务B在同一个事务中处 理。就可以使用消息中间件来实现这种分布式事务。

 

第一步: 消息由系统A投递到中间件

1. 在系统A处理任务A前，首先向消息中间件发送一条消息

2. 消息中间件收到后将该条消息持久化，但并不投递。持久化成功后，向A回复一个确认应答

3. 系统A收到确认应答后，则可以开始处理任务A

4. 任务A处理完成后，向消息中间件发送Commit或者Rollback请求。该请求发送完成后，对系统A而 言，该事务的处理过程就结束了

5. 如果消息中间件收到Commit，则向B系统投递消息；如果收到Rollback，则直接丢弃消息。但是 如果消息中间件收不到Commit和Rollback指令，那么就要依靠"超时询问机制"。

超时询问机制 系统A除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调 用。当消息中间件收到发布消息便开始计时，如果到了超时没收到确认指令，就会主动调用 系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果，中间件根据三 种结果做出不同反应： 提交:将该消息投递给系统B 回滚:直接将条消息丢弃

处理中:继续等待

第二步: 消息由中间件投递到系统B 消息中间件向下游系统投递完消息后便进入阻塞等待状态，下游系统便立即进行任务的处理，任务 处理完成后便向消息中间件返回应答。

• 如果消息中间件收到确认应答后便认为该事务