一、上集回顾
上级文章地址：【SpringCloud】Sentinel的基础概念及使用_面向架构编程的博客-CSDN博客
雪崩问题虽然有四种方案，但是限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。
所以，这一篇文章我们先来讲讲服务限流（流量控制）
二、簇点链路
当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。
簇点链路中被监控的每一个接口就是一个资源。
默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller中的方法）。
因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。
也就是说Service、Mapper中的方法默认是不会被监控的，除非我们对其使用Sentinel提供的一些注解！
流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则
流控：流量控制
降级：降级熔断
热点：热点参数限流，是限流的一种
授权：请求的权限控制
三、快速入门
【需求】给 /order/{orderId}设置流控规则，QPS<5，然后压测
（1）首先在sentinel控制台添加限流规则
点击资源/order/{orderId}后面的流控按钮，就可以弹出表单，将QPS设置为5即可
（2）利用jmeter测试
右键启动后，在结果树里面看结果：
有成功的，也有失败的，失败的原因是被Sentinel阻塞了，这就说明Sentinel起了作用！！！
Sentinel控制台
这里只是演示了一下Sentinel最基本的用法。然而点击“更多”下面还有——流控模式、流控效果。下面我们就来研究一下它们！
四、流控模式
在添加限流规则时，点击高级选项，可以选择三种流控模式
直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流（指定来源）
1.关联模式
统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。
使用场景
比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。
配置规则
语法说明
当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源。
需求分析
在OrderController新建两个端点：/order/query和/order/update，无需实现业务
配置流控规则，当/order/update资源被访问的QPS超过5时，对/order/query请求限流
代码实现
（1）定义/order/query端点，模拟订单查询
@GetMapping("/query")
public String queryOrder() {
return "查询订单成功";
}（2）定义/order/update端点，模拟订单更新
@GetMapping("/update")
public String updateOrder() {
return "修改订单成功";
}重启order-service服务，然后访问一下
查询业务：localhost:8080/order/query
更新业务：localhost:8080/order/update
（3）配置流控规则
【问】我们现在要给谁添加流控规则呢？query？还是update？
答：给谁限流就给谁添加流控规则！所以，这里给/order/query 添加流控规则！
这么配置的含义是：当/order/update的QPS超过5，则会限制/order/query的访问！
（4）在Jmeter测试
我们现在有Jmeter做一下测试
1000个请求，10s内发完，QPS为10，显然是会大于我们之前设定的值！
启动Jmeter进行压测！
这个时候，访问一下/order/update，会出现异常，如下：
小结
一般满足以下关系可以使用关联模式：
两个有竞争关系的资源
一个优先级高，一个优先级低（优先级高的触发阈值，对优先级低的做限流）
2.链路模式
只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。
配置示例
例如有两条请求链路：
/test1 --> /common
/test2 --> /common
如果只希望统计从/test2进入到/common的请求，则可以这样配置：
需求分析
有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。
步骤：
在OrderService中添加一个queryGoods()方法，不用实现业务
在OrderController中，改造/order/query端点，调用OrderService中的queryGoods方法
在OrderController中添加一个/order/save的端点，调用OrderService的queryGoods方法
给queryGoods设置限流规则，从/order/query进入queryGoods的方法限制QPS必须小于2
代码实现
（1）添加查询商品方法
在order-service服务中，给OrderService类添加一个queryGoods()方法
public void queryGoods() {
System.out.println("查询商品");
}（2）查询订单时，查询商品
在order-service的OrderController中，修改/order/query端点的业务逻辑
@GetMapping("/query")
public String queryOrder() {
// 查询商品
orderService.queryGoods();
// 查询订单
System.out.println("查询订单");
return "查询订单成功";
}（3）新增订单，查询商品
在order-service的OrderController中，修改/order/save端点，模拟新增订单
@GetMapping("/save")
public String saveOrder() {
// 新增商品
orderService.queryGoods();
// 新增订单
System.out.println("新增订单");
return "新增订单成功";
}（4）给查询商品添加资源标记（重点！！！）
默认情况下，OrderService中的方法是不被Sentinel监控的，需要我们自己通过注解来标记要监控的方法。
给OrderService的queryGoods()方法添加注解
@SentinelResource("goods")
public void queryGoods() {
System.out.println("查询商品");
}链路模式中，是对不同来源的两个链路做监控。但是sentinel默认会给进入SpringMVC的所有请求设置同一个root资源，会导致链路模式失效！！！
我们需要关闭这种对SpringMVC的资源聚合，修改order-service服务的application.yml文件：
spring:
cloud:
sentinel:
web-context-unify: false # 关闭context整合
重启服务，访问/order/query和/order/save，可以查看到sentinel的簇点链路规则中，出现了新的资源：
（5）添加流控规则
点击goods资源后面的流控按钮，在弹出的表单中填写下面信息：
只统计从/order/query进入/goods的资源，QPS阈值为2，超出则被限流。
（6）Jmeter测试
200个请求，50s内发完，即每秒4个（QPS为4）
配置/order/save的HTTP请求
配置/order/query的HTTP请求
启动Jmeter
我们可以看到新增业务都是正常的
但是，在查询业务中就会出现异常！！！
总共的QPS为8，即新增4个、查询4个，这里显然是在查询业务中被拒绝了2个！！！
五、流控效果
在流控的高级选项中，还有一个流控效果选项：
流控效果是指请求达到流控阈值时应该采取的措施，包括三种：
快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长。
1.快速失败
是默认的处理方式。达到阈值后，直接抛出FlowException异常，不做任何处理！
2.warm up
阈值一般是一个微服务能承担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将QPS跑到最大值，可能导致服务瞬间宕机！！！
而warm up模式就是为了解决这个问题！
warm up也叫预热模式，是应对服务冷启动的一种方案。
工作原理
请求阈值初始值是 maxThreshold / coldFactor，持续指定时长后，逐渐提高到maxThreshold值。而coldFactor的默认值是3（也就是说初始阈值是阈值的1/3）
例如，我设置QPS的maxThreshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10，如下图：
3.排队等待
当请求超过QPS阈值时，快速失败和warm up 会拒绝新的请求并抛出异常。
而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，但是，如果请求预期的等待时间超出最大时长，则会被拒绝。
工作原理
例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过2000ms的请求会被拒绝并抛出异常，如下图所示：
好处
如果第1秒同时接收到10个请求，但第2秒只有1个请求，此时QPS的曲线这样的：
如果使用队列模式做流控，所有进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑
平滑的QPS曲线起到了流量整形的作用，对于服务器来说是更友好的，也相当于是对微服务的一种保护！
六、热点参数限流
之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。
1.全局参数限流
例如，一个根据id查询商品的接口
如果按照原来的统计方式，也就是全局参数限流，QPS的值为4。
2.热点参数限流
访问/goods/{id}的请求中，id参数值会有变化，热点参数限流会根据参数值分别统计QPS，如下图所示
配置规则
对hot这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过5
高级选项
对0号的long类型参数限流，每1秒相同参数的QPS不能超过5，有两个例外：
如果参数值是100，则每1秒允许的QPS为10
如果参数值是101，则每1秒允许的QPS为15
案例需求
给/order/{orderId}这个资源添加热点参数限流，规则如下：
默认的热点参数规则是每1秒请求量不超过2
给102这个参数设置例外：每1秒请求量不超过4
给103这个参数设置例外：每1秒请求量不超过10
【有一个坑】注意事项：热点参数限流对默认的SpringMVC资源无效，需要利用@SentinelResource注解标记资源才会生效！！！
代码实现
（1）标记资源
给order-service中的OrderController中的/order/{orderId}资源添加注解
@SentinelResource("hot")
@GetMapping("{orderId}")
public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
// 根据id查询订单并返回
return orderService.queryOrderById(orderId);
}（2）热点参数限流规则
点击左侧菜单中热点规则菜单
点击新增，填写表单
（3）Jmeter测试
这里发起请求的QPS为5，包含3个http请求，即
/order/101
/order/102
/order/103
对于普通参数"/order/101"的阈值是2
/order/102的阈值是4
/order/103的阈值是10
也就是说，通过QPS的最大值是11（2+4+5）
显然，不同参数的限流上限是不一样的！热点参数限流是一种更细粒度的限流！