SpringCloud微服务入门(二)

在微服务远程调用的过程中，还存在几个问题需要解决。

首先是业务健壮性问题：

例如在之前的查询购物车列表业务中，购物车服务需要查询最新的商品信息，与购物车数据做对比，提醒用户。大家设想一下，如果商品服务查询时发生故障，查询购物车列表在调用商品服 务时，是不是也会异常？从而导致购物车查询失败。但从业务角度来说，为了提升用户体验，即便是商品查询失败，购物车列表也应该正确展示出来，哪怕是不包含最新的商品信息。

还有级联失败问题：

还是查询购物车的业务，假如商品服务业务并发较高，占用过多Tomcat连接。可能会导致商品服务的所有接口响应时间增加，延迟变高，甚至是长时间阻塞直至查询失败。

此时查询购物车业务需要查询并等待商品查询结果，从而导致查询购物车列表业务的响应时间也变长，甚至也阻塞直至无法访问。而此时如果查询购物车的请求较多，可能导致购物车服务的Tomcat连接占用较多，所有接口的响应时间都会增加，整个服务性能很差， 甚至不可用。

暂时无法在飞书文档外展示此内容

依次类推，整个微服务群中与购物车服务、商品服务等有调用关系的服务可能都会出现问题，最终导致整个集群不可用。

暂时无法在飞书文档外展示此内容

这就是级联失败问题，或者叫雪崩问题。

微服务保护

保证服务运行的健壮性，避免级联失败导致的雪崩问题（整个微服务群中有调用关系的服务出现问题，最终导致整个集群不可用），就属于微服务保护

服务保护方案

微服务保护的方案有很多，比如：

• 请求限流
• 线程隔离
• 服务熔断

这些方案或多或少都会导致服务的体验上略有下降，比如请求限流，降低了并发上限；线程隔离，降低了可用资源数量；服务熔断，降低了服务的完整度，部分服务变的不可用或弱可用。因此这些方案都属于服务降级的方案。但通过这些方案，服务的健壮性得到了提升，

请求限流

服务故障最重要原因，就是并发太高。解决了这个问题，就能避免大部分故障。当然，接口的并发不是一直很高，而是突发的。因此请求限流，就是限制或控制接口访问的并发流量，避免服务因流量激增而出现故障。

请求限流往往会有一个限流器，数量高低起伏的并发请求曲线，经过限流器就变的非常平稳。

线程隔离

当一个业务接口响应时间长，而且并发高时，就可能耗尽服务器的线程资源，导致服务内的其它接口受到影响。所以必须把这种影响降低，或者缩减影响的范围，线程隔离正是解决这个问题的好办法。

其原理就是为了避免某个接口故障或压力过大导致整个服务不可用，限定每个接口可以使用的资源范围，也就是将其“隔离”起来。

服务熔断

线程隔离虽然避免了雪崩问题，但故障服务依然会拖慢服务调用方的接口响应速度，而且其故障可能会导致接下来要调用的其他服务也变得不可用。

所以要做两件事情：

• 编写服务降级逻辑：就是服务调用失败后的处理逻辑，根据业务场景，可以抛出异常，也可以返回友好提示或默认数据。
• 异常统计和熔断：统计服务提供方的异常比例，当比例过高表明该接口会影响到其它服务，应该拒绝调用该接口，而是直接走降级逻辑。

Sentinel

Sentinel是阿里巴巴开源的一款服务保护框架，目前已经加入SpringCloudAlibaba中

Sentinel的使用可以分为两个部分:

• 核心库（Jar包）：不依赖任何框架/库，能够运行于 ava8及以上的版本的运行时环境，同时对Dubbo/Spring Cloud等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。
• 控制台（Dashboard）：Dashboard主要负责管理推送规则、监控、管理机器信息等。

为了方便监控微服务，需要先把Sentinel的控制台搭建出来。

1）下载jar包

2）运行

将jar包放在任意非中文、不包含特殊字符的目录下,运行如下命令启动控制台：

java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

其它启动时可配置参数可参考官方文档

3）访问

访问http://localhost:8090页面，就可以看到sentinel的控制台了，需要输入账号和密码，默认都是：sentinel，登录后，即可看到控制台，默认会监控sentinel-dashboard服务本身

微服务整合

想要在微服务连接sentinel-dashboard控制台，步骤如下：

1）引入sentinel依赖

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

2）配置控制台

修改application.yaml文件：

spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8090

3）访问微服务任意端点

重启微服务，然后访问查询购物车接口，sentinel的客户端就会将服务访问的信息提交到sentinel-dashboard控制台。并展示出统计信息

点击簇点链路菜单，会看到下面的页面：

簇点链路，就是单机调用链路，是一次请求进入服务后经过的每一个被Sentinel监控的资源。默认情况下，Sentinel会监控SpringMVC的每一个Endpoint（接口）

/carts这个接口路径就是其中一个簇点，我们可以对其进行限流、熔断、隔离等保护措施。

默认情况下Sentinel会把路径作为簇点资源的名称，无法区分路径相同但请求方式不同的接口，查询、删除、修改等都被识别为一个簇点资源，这显然是不合适的。

所以可以选择打开Sentinel的请求方式前缀，把请求方式 + 请求路径作为簇点资源名：

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8090
      http-method-specify: true # 开启请求方式前缀

请求限流

在簇点链路后面点击流控按钮，即可对其做限流配置

线程隔离

限流可以降低服务器压力，尽量减少因并发流量引起的服务故障的概率，但并不能完全避免服务故障。一旦某个服务出现故障，我们必须隔离对这个服务的调用，避免发生雪崩。所以要对查询商品的FeignClient接口做线程隔离。

OpenFeign整合Sentinel

开启Feign的sentinel功能：

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持

然后重启cart-service服务，可以看到查询商品的FeignClient自动变成了一个簇点资源

配置线程隔离

点击查询商品的FeignClient对应的簇点资源后面的流控按钮：

这里勾选的是并发线程数限制，也就是说这个查询功能最多使用5个线程，而不是5QPS。如果查询商品的接口每秒处理2个请求，则5个线程的实际QPS在10左右，而超出的请求自然会被拒绝。

服务熔断

通常来说，业务不能只配置线程隔离，还需要搭配服务熔断一起，因为：

• 超出的QPS上限的请求就只能抛出异常，会损失用户体验。需要给查询失败设置一个降级处理逻辑
• 由于查询商品的延迟较高，从而导致其他相关联的业务响应时间也变的很长。对于这种不太健康的接口，应该直接停止调用，直接走降级逻辑，避免影响到当前服务。也就是将商品查询接口熔断。

编写降级逻辑

触发限流或熔断后的请求不一定要直接报错，也可以返回一些默认数据或者友好提示，用户体验会更好。

给FeignClient编写失败后的降级逻辑有两种方式：

• FallbackClass，无法对远程调用的异常做处理
• FallbackFactory，可以对远程调用的异常做处理，我们一般选择这种方式。

定义降级处理类，实现FallbackFactory：

@Slf4j
public class ItemClientFallback implements FallbackFactory<ItemClient> {
    @Override
    public ItemClient create(Throwable cause) {
        return new ItemClient() {
            @Override
            public List<ItemDTO> queryItemByIds(Collection<Long> ids) {
                log.error("远程调用queryItemByIds方法出现异常，参数：{}", ids, cause);
                // 查询购物车允许失败，查询失败，返回空集合
                return CollUtils.emptyList();
            }
            @Override
            public void deductStock(List<OrderDetailDTO> items) {
                // 库存扣减业务需要触发事务回滚，查询失败，抛出异常
                throw new BizIllegalException(cause);
            }
        };
    }
}

将ItemClientFallback注册为一个Bean

在接口中使用ItemClientFallbackFactory：

@FeignClient(value = "item-service", configuration = DefaultFeignConfig.class,fallbackFactory = ItemClientFallbackFactory.class)
public interface ItemClient {
    @GetMapping("/items")
    List<ItemDTO> queryItemByIds(@RequestParam("ids") Collection<Long> ids);

    @PutMapping("/items/stock/deduct")
    void deductStock(@RequestBody List<OrderDetailDTO> items);

    @PutMapping("/stock/add")
    void addStock(@RequestBody List<OrderDetail> items);
}

服务熔断

Sentinel中的断路器不仅可以统计某个接口的慢请求比例，还可以统计异常请求比例。当这些比例超出阈值时，就会熔断该接口，即拦截访问该接口的一切请求，降级处理；当该接口恢复正常时，再放行对于该接口的请求。

断路器的工作状态切换有一个状态机来控制：

状态机包括三个状态：

• closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
• open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态持续一段时间后会进入half-open状态
• half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
  • 请求成功：则切换到closed状态
  • 请求失败：则切换到open状态

我们可以在控制台通过点击簇点后的熔断按钮来配置熔断策略，这种是按照慢调用比例来做熔断，上述配置的含义是：

• RT超过200毫秒的请求调用就是慢调用
• 统计最近1000ms内的最少5次请求，如果慢调用比例不低于0.5，则触发熔断
• 熔断持续时长20s

分布式事务

整个业务中，各个本地事务是有关联的。因此每个微服务的本地事务，也可以称为分支事务。多个有关联的分支事务一起就组成了全局事务。必须保证整个全局事务同时成功或失败。

我们知道每一个分支事务就是传统的单体事务，都可以满足ACID(原子性，一致性，隔离性，持久性)，但全局事务跨越多个服务、多个数据库，如何满足ACID呢？

Seata

解决分布式事务的方案有很多，但实现起来都比较复杂，因此一般会使用开源的框架来解决分布式事务问题。

在众多的开源分布式事务框架中，功能最完善、使用最多的是Seata。

其实分布式事务产生的一个重要原因，就是参与事务的多个分支事务互相无感知，不知道彼此的执行状态。

因此解决分布式事务的思想为：就是找一个统一的事务协调者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败即可。

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

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

Seata的工作架构为：

其中，TM和RM可以理解为Seata的客户端部分，引入到参与事务的微服务依赖中即可。将来TM和RM就会协助微服务，实现本地分支事务与TC之间交互，实现事务的提交或回滚。

而TC服务则是事务协调中心，是一个独立的微服务，需要单独部署。

部署TC服务

需要准备数据库表、导入配置文件、使用Docker命令部署，详见这篇博客

Docker部署

需要注意，要确保nacos、mysql都在同一网络中。如果某个容器不在同一网络，可以参考下面的命令将某容器加入指定网络：

docker network connect [网络名] [容器名]

微服务集成Seata

参与分布式事务的每一个微服务都需要集成Seata，我们以trade-service为例。

引入依赖

为了方便各个微服务集成seata，我们需要把seata配置共享到nacos，因此不仅仅要引入seata依赖，还要引入nacos依赖:

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
<!--读取bootstrap文件-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
<!--seata-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</dependency>

添加配置：

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 192.168.150.101:8848 # nacos地址
      namespace: "" # namespace，默认为空
      group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP
      application: seata-server # seata服务名称
      username: nacos
      password: nacos
  tx-service-group: hmall # 事务组名称
  service:
    vgroup-mapping: # 事务组与tc集群的映射关系
      hmall: "default"

添加数据库表

seata的客户端在解决分布式事务的时候需要记录一些中间数据，保存在数据库中。因此我们要先准备一个这样的表。加入到需要分布式事务的微服务的数据库中：

CREATE TABLE IF NOT EXISTS `undo_log`
(
    `branch_id`     BIGINT       NOT NULL COMMENT 'branch transaction id',
    `xid`           VARCHAR(128) NOT NULL COMMENT 'global transaction id',
    `context`       VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
    `rollback_info` LONGBLOB     NOT NULL COMMENT 'rollback info',
    `log_status`    INT(11)      NOT NULL COMMENT '0:normal status,1:defense status',
    `log_created`   DATETIME(6)  NOT NULL COMMENT 'create datetime',
    `log_modified`  DATETIME(6)  NOT NULL COMMENT 'modify datetime',
    UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB
  AUTO_INCREMENT = 1
  DEFAULT CHARSET = utf8mb4 COMMENT ='AT transaction mode undo table';

至此为止，微服务整合的工作就完成了

那么，Seata是如何解决分布式事务的呢？

XA模式

Seata支持四种不同的分布式事务解决方案：

• XA
• TCC
• AT
• SAGA

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对XA规范提供了支持。

两阶段提交

正常情况：

异常情况：

一阶段：

• 事务协调者通知每个事务参与者执行本地事务
• 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

• 事务协调者基于一阶段的报告来判断下一步操作
• 如果一阶段都成功，则通知所有事务参与者，提交事务
• 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

RM一阶段的工作：

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

TC二阶段的工作：

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

RM二阶段的工作：

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

优缺点

XA模式的优点是什么？

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

XA模式的缺点是什么？

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

实现步骤

首先，在配置文件中设置：

seata:
  data-source-proxy-mode: XA

其次，我们要利用@GlobalTransactional标记分布式事务的入口方法：

@GlobalTransactional
public Long createOrder(OrderFormDTO orderFormDTO) {
    // ...
}

AT模式

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

Seata的AT模型

阶段一RM的工作：

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

阶段二提交时RM的工作：

• 删除undo-log即可

阶段二回滚时RM的工作：

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

流程梳理

我们用一个真实的业务来梳理下AT模式的原理。

比如，现在有一个数据库表，记录用户余额：

id	money
1	100

其中一个分支业务要执行的SQL为：

update tb_account set money = money - 10 where id = 1

AT模式下，当前分支事务执行流程如下：

一阶段：

1. TM发起并注册全局事务到TC
2. TM调用分支事务
3. 分支事务准备执行业务SQL
4. RM拦截业务SQL，根据where条件查询原始数据，形成快照。

{
  "id": 1, "money": 100
}

1. RM执行业务SQL，提交本地事务，释放数据库锁。此时 money = 90
2. RM报告本地事务状态给TC

二阶段：

1. TM通知TC事务结束
2. TC检查分支事务状态
   1. 如果都成功，则删除快照
   2. 如果有分支事务失败，需要回滚。读取快照数据（{“id”: 1, “money”: 100}），将快照恢复到数据库。此时数据库再次恢复为100

AT模式的脏写问题

在极端情况下，特别是多线程并发访问AT模式的分布式事务时，有可能出现脏写问题，比如一个事物A获取DB锁，保存快照，执行set money = 90然后提交事务，释放DB锁，但是这是有另一个事务B接着获取DB锁，保存快照后执行set money = 80然后提交事务，释放DB锁。但是这时事务A需要回滚，事务A的快照保存的money=100，这就造成了脏写。

解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。

AT与XA的区别

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

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

可见，AT模式使用起来更加简单，无业务侵入，性能更好。

TCC模式

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

• try：资源的检测和预留
• confirm：完成资源操作业务；要求 try 成功 confirm 一定要能成功
• cancel：预留资源释放，可以理解为try的反向操作

举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。

阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30，此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务

**阶段二（Confirm)**：假如要提交（Confirm），之前可用金额已经扣减，并转移到冻结金额。因此可用金额不变，直接冻结金额扣减30即可。此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元

**阶段三(Canncel)**：如果要回滚（Cancel），则释放之前冻结的金额，也就是冻结金额扣减30，可用余额增加30

假如一个分布式事务中包含两个分支事务，try阶段，一个分支成功执行，另一个分支事务阻塞

事务悬挂和空回滚

假如一个分布式事务中包含两个分支事务，try阶段，一个分支成功执行，另一个分支事务阻塞

如果阻塞时间太长，可能导致全局事务超时而触发二阶段的cancel操作。两个分支事务都会执行cancel操作

要知道，其中一个分支是未执行try操作的，直接执行了cancel操作，反而会导致数据错误。因此，这种情况下，尽管cancel方法要执行，但其中不能做任何回滚操作，这就是空回滚

对于整个空回滚的分支事务，将来try方法阻塞结束依然会执行。但是整个全局事务其实已经结束了，因此永远不会再有confirm或cancel，也就是说这个事务执行了一半，处于悬挂状态，这就是业务悬挂问题

总结

TCC模式的每个阶段

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

TCC的优点

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

TCC的缺点

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

CAP与BASE理论

CAP理论

解决分布式事务问题，需要一些分布式系统的基础知识作为理论指导，首先就是CAP定理

• Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致
• Availability（可用性）：用户访问分布式系统时，读或写操作总能成功
• Partition tolerance （分区容错性）：即便是系统出现网络分区，整个系统也要持续对外提供服务

它们的第一个字母分别是 C、A、P。开发者认为任何分布式系统架构方案都不可能同时满足这3个目标，这个结论就叫做CAP定理

在分布式系统中，网络不能100%保证畅通，也就是说网络分区的情况一定会存在。而我们的系统必须要持续运行，对外提供服务。所以分区容错性（P）是硬性指标，所有分布式系统都要满足。而在设计分布式系统时要取舍的就是一致性（C）和可用性（A）了。

假设有三个node节点，由于网络故障，当我们把数据写入node01时，可以与node02完成数据同步，但是无法同步给node03。现在有两种选择：

• 允许用户任意读写，保证可用性。但由于node03无法完成同步，就会出现数据不一致的情况。满足AP
• 不允许用户写，可以读，直到网络恢复，分区消失。这样就确保了一致性，但牺牲了可用性。满足CP

可见，在分布式系统中，A和C之间只能满足一个

BASE理论

既然分布式系统要遵循CAP定理，那么问题来了，我到底是该牺牲一致性还是可用性呢？如果牺牲了一致性，出现数据不一致该怎么处理？

人们在总结系统设计经验时，最终得到了一些心得：

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

简单来说，BASE理论就是一种取舍的方案，不再追求完美，而是最终达成目标。因此解决分布式事务的思想也是这样，有两个方向：

• AP思想：各个子事务分别执行和提交，无需锁定数据。允许出现结果不一致，然后采用弥补措施恢复，实现最终一致即可。例如AT模式就是如此
• CP思想：各个子事务执行后不要提交，而是等待彼此结果，然后同时提交或回滚。在这个过程中锁定资源，不允许其它人访问，数据处于不可用状态，但能保证一致性。例如XA模式

服务保护

在SpringCloud的早期版本中采用的服务保护技术叫做Hystix，不过后来被淘汰，替换为Spring Cloud Circuit Breaker，其底层实现可以是Spring Retry和Resilience4J

不过在国内使用较多还是SpringCloudAlibaba中的Sentinel组件

线程隔离

首先我们来看下线程隔离功能，无论是Hystix还是Sentinel都支持线程隔离。不过其实现方式不同。

线程隔离有两种方式实现：

• 线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果，优点是支持主动超时和异步调用，缺点是线程额外开销大
• 信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求，优点是无额外开销，缺点是不支持主动超时和异步调用

Sentinel的线程隔离就是基于信号量隔离实现的，而Hystix两种都支持，但默认是基于线程池隔离

滑动窗口算法

在熔断功能中，需要统计异常请求或慢请求比例，也就是计数。在限流的时候，要统计每秒钟的QPS，同样是计数。可见计数算法在熔断限流中的应用非常多。sentinel中采用的计数器算法就是滑动窗口计数算法

固定窗口计数

固定窗口计数法基本原理是：

• 将时间划分为多个窗口，窗口时间跨度称为Interval
• 每个窗口维护1个计数器，每有1次请求就将计数器+1。限流就是设置计数器阈值
• 如果计数器超过了限流阈值，则超出阈值的请求都被丢弃

但是有一种特殊场景，假设Interval为1s：

• 假如在第5、6秒，请求数量都为3，没有超过阈值，全部放行
• 但是，如果第5秒的三次请求都是在4.55秒之间进来；第6秒的请求是在55.5之间进来。那么从第4.5~5.5之间就有6次请求！也就是说每秒的QPS达到了6，远超阈值

滑动窗口计数

固定时间窗口算法中窗口有很多，其跨度和位置是与时间区间绑定，因此是很多固定不动的窗口。而滑动时间窗口算法中只包含1个固定跨度的窗口，但窗口是可移动的，与时间区间无关

• 窗口时间跨度Interval大小固定，例如1秒
• 时间区间跨度为Interval / n ，例如n=2，则时间区间跨度为500ms
• 窗口会随着当前请求所在时间currentTime移动，窗口范围从currentTime-Interval时刻之后的第一个时区开始，到currentTime所在时区结束

滑动窗口内划分的时区越多，这种统计就越准确。

漏桶算法

漏桶算法可以解释为请求到达后不是直接处理，而是先放入一个队列。而后以固定的速率从队列中取出并处理请求。之所以叫漏桶算法，就是把请求看做水，队列看做是一个漏了的桶，设计上更适合应对并发波动较大的场景

• 将每个请求视作”水滴”放入”漏桶”进行存储
• “漏桶”以固定速率向外”漏”出请求来执行，如果”漏桶”空了则停止”漏水”
• 如果”漏桶”满了则多余的”水滴”会被直接丢弃

漏桶的优势就是流量整型，桶就像是一个大坝，请求就是水。并发量不断波动，就如图水流时大时小，但都会被大坝拦住。而后大坝按照固定的速度放水，避免下游被洪水淹没。

因此，不管并发量如何波动，经过漏桶处理后的请求一定是相对平滑的曲线

令牌桶算法

限流的另一种常见算法是令牌桶算法。Sentinel中的热点参数限流正是基于令牌桶算法实现的。

说明：

• 以固定的速率生成令牌，存入令牌桶中，如果令牌桶满了以后，多余令牌丢弃
• 请求进入后，必须先尝试从桶中获取令牌，获取到令牌后才可以被处理
• 如果令牌桶中没有令牌，则请求等待或丢弃

基于令牌桶算法，每秒产生的令牌数量基本就是QPS上限

当然也有例外情况，例如：

• 某一秒令牌桶中产生了很多令牌，达到令牌桶上限N，缓存在令牌桶中，但是这一秒没有请求进入。
• 下一秒的前半秒涌入了超过2N个请求，之前缓存的令牌桶的令牌耗尽，同时这一秒又生成了N个令牌，于是总共放行了2N个请求。超出了我们设定的QPS阈值。

因此，在使用令牌桶算法时，尽量不要将令牌上限设定到服务能承受的QPS上限。而是预留一定的波动空间，这样我们才能应对突发流量。

什么是热点参数限流？

• 商品ID为参数，统计一段时间内最常购买的商品ID并进行限制

• 用户ID为参数，针对一段时间内频繁访问的用户ID进行限制