前言：

        所有的准备工作都做好了，就可以进入到Sentinel的具体使用上了，这里还需要一个测试工具叫做jmeter，是一个很好的测试工具，专门针对并发的，准备好以后，就可以直接开干了。

一、Sentinel作用

        Sentinel主要是为了解决雪崩问题。微服务的雪崩就是当一个服务出现问题，其它调用问题服务的服务也会出现问题，从而一传十十传百，导致整个系统崩溃，解决微服务雪崩的常见方式有四种：

超时处理：请求超过一定时间就返回报错信息。

仓壁模式：也叫做线程隔离，限制每个业务使用线程的数量，减少对其它业务的影响。

熔断降级：统计请求异常的比例，异常比例达到阈值之后，会熔断该业务，拦截一切访问该业务的请求。

流量控制：对业务的QPS进行限制，避免服务因为流量激增而鼓掌。

二、控制台基本使用

1、进入到Sentinel控制台页面，尝试使用jmeter并发访问某可接口：

可以在实时监控里面看到QPS变化的折线图，也可以看到右边有相关数据的统计。

2、点击簇点链路，可以为不同的url设置流控规则：

 流控规则基本上分为两种：一个是QPS、一个是并发线程数

（1）QPS：在后面的单机阈值里面的设置最大的QPS值，就是每秒钟允许的最大并发量，这种模式下，只要并发量查过最大阈值，都会被拒绝，返回的结果是429，表示被限流。

（2）并发线程数：在后面的单机阈值里面的设置最大线程数量，每秒钟最多有两个线程支持你的请求。这种模式下，最大的QPS可能很大，但是不稳定，时高时低，但是超过线程能处理的能力范围之后，就会出现拒绝，也就是限流。

3、高级选项

 在新增流控规则中点击高级选项，出现流控模式，有三种：

直接模式：统计当前请求的资源，当超过阈值之后，对当前资源直接限流，是默认模式。

关联模式：在某些业务场景下，限流也需要有权重，比如：修改订单和查询订单，都是需要对订单进行操作，这会导致锁的竞争，但是修改订单的权重显然大于查询，因此，当修改订单的请求到达阈值时，需要对查询订单做限流。大致一是就是，我这里都忙不过来了，你就不要来添堵了。

链路模式：在创建订单和查询订单时，都会去查询商品服务，但是查询订单的并发量往往比较高，这时，就需要给这个查询链路加上一个并发的上线，不能让它的QPS无限放大，从而影响到订单的创建。

另外还有流控效果，也分为三种：

快速失败：到达阈值之后，新的请求会立即拒绝并且抛出异常，这是默认的方式。

Warm Up:预热模式，主要是以防止服务的冷启动，服务刚启动时就有大量的请求进入，直接干蹦服务；高开始阈值大概是最大阈值的三分之一，会设置一个预热时间，在这个时间段内，阈值会慢慢加大，直到达到最大阈值，那超过阈值的请求也会理解被拒绝。

排队等待： 将所有的请求放到一个队列里面，根据QPS的大小，计算出请求间隔的时间，例如QPS=5，那么1s钟需要执行5个请求，每个请求就是200ms，第二个请求需要等待第一个请求执行完，那么必须要等待200ms，以此类推，后续的请求进来之后，都会计算自己的预计等待时间，如果预计等待时间比设置的最大等待时间要大，那么该请求就会被拒绝。

 最后还有一种热点规则，精确到了参数，例如：商品A查询的QPS是10，而商品B的QPS是2，那么商品A相对于商品B来说是热点数据，我们可以通过对他的id设置限流，说实话，这个有点针对的感觉；查询商品用的是一个接口，只是参数不一样，对不同的参数可以设置限流，但是需要注意的是 热点参数对默认的SpringMVC资源无法生效，需要在方法上添加注解@SentinelResource("随便起个名字")