sentinel的限流操作：快速失败、Warm UP、排队等待

1、配置说明

(1)、资源名：请求的资源名称
(2)、QPS：每秒请求数量
(3)、线程数：并发处理的线程数量
(4)、单机阈值：限制的请求数量或者线程数量
(5)、流控模式：

• 直接：针对当前资源进行处理
• 关联：当前资源关联一个B资源，请求发给B，如果B达到阈值，对当前资源进行限流。
• 链路：以调用链路为单位做限流处理，如：A --> B --> C这个链路的总体流量只按入口A的请求量作为计算。

2、流控效果：

(1)、快速失败：当求情达到阈值时，直接抛出异常Blocked by Sentinel(flow limiting)，服务器返回状态码429

postman测试20个，只有7个请求通过



服务器中，只有7个日志记录

(2)、Warm UP：预热/冷启动

QPS为20，冷加载因子为3，系统从阈值为20/3缓慢加到阈值为20，时间为8s。该方式是为了防止长期处于低水平的系统，突然来了大流量，系统突然拉升至高水平导致系统估。



postman给500个请求进行测试



可以看到QPS从6-20用了10s时间，并稳定在20

(3)、排队等待：

采用匀速器的方式

单机阈值设为5，1秒内通过5个，每200ms通过一次。
该限流好比一个漏斗，每隔200ms向漏斗中丢一个令牌，当请求拿到令牌就通过该漏斗，没有拿到令牌就在漏斗中等候令牌(队列的形式)，直到请求的等待时间超过100ms(超时时间)，该请求原地消失。
如果有高并发的请求进入：按照如上的配置只有第一个请求通过，其余请求全部超时消失。

• 前提：postman的runner是依次发送请求，postman的runner是串行的，上一个请求结束后才开始下一个请求，只能算连续测试但不是并发测试
  验证如下：
  100个请求测试，第一个请求时间
  
  最后一个请求时间：
  

• 测试：
  postman发送600个请求进行测试：
  
  

• 结果：
  开始
  
  
  结束