:-:  **设置流控规则的地方**  **限流规则组成因素** * 资源名：限流规则的作用对象，唯一名称，默认为请求路径。 * 针对来源：可以针对调用者限流，为微服务的名称，default为不区分来源。 * 阈值类型： * QPS是每秒请求次数。 * 线程数与QPS的区别是：QPS是指当超过阈值时会将多余的请求拒之门外，多余的请求根本就进不了微服务里面；而线程数是指所有的请求都可以进到微服务里面，多余的请求则在微服务里面直接丢弃。 * 单机阈值：填写整数。 * 是否集群：不勾选则不是集群。 * 流控模式： * 直接：当一个请求超出阈值时，超出部分直接被限流。 * 关联：如果请求B关联请求A，则当请求B超出阈值时，对请求A限流。 * 链路：在指定的链路上的入口资源超出阈值则限流。 * 流控效果： * 快速失败：当请求超出阈值后，超出的部分直接抛出异常，请求失败。 * Warm Up：称为预热/冷启动方式。假如设置阈值为10，预热时长为5s，则初始阈值为 `$ 10/codeFactor(默认为3)=3 $`，经过5s后阈值更改为10。 * 排队等待：就是当请求超出阈值后，超出的部分需要排队处理，可以规定每多少秒处理一个请求，只针对QPS阈值类型有效。 下面演示流控模式和流控效果的使用效果。 **1. 流控模式-直接** （1）流控规则：1s内只处理一次请求。  （2）演示效果：在1s超出的请求被限流了。  <br/> **2. 流控模式-关联** （1）流控规则：`/testB`1s内只处理一次请求。 关联模式下，设置的单机阈值是`/testB`的阈值，不是`/testA`的阈值。  （2）演示效果：我使用Postman在1s内向`/testB`请求100次，由于`/testB`1s内被请求的次数超过1次，所以导致`/testA`被限流了。  **3. 流控模式-链路** （1）流控规则： <br/> **4. 流控效果-快速失败** 这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时。 （1）流控规则：1s内只处理一次请求。  （2）演示效果：在1s超出的请求被限流了，直接抛出异常。  <br/> **5. 流控效果-Warm Up** 当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。 （1）流控规则：设置阈值为10，预热时长为5s，则初始阈值为 `$ 10/codeFactor(默认为3)=3 $`，经过5s后阈值更改为10。  （2）演示效果：开始的时候阈值为3，1s内请求次数超过3次后被限流，经过5s后阈值为10，承担的请求次数变多就没有被限流了。  <br/> **6. 流控效果-排队等待** 这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。 >[info] 注意：匀速排队模式暂时不支持 QPS > 1000 的场景。 （1）流控规则：1s只处理一个请求，如果某一个请求在2000ms还没有被处理则丢弃。  （2）演示效果：我使用Postman在1s内发出100次请求，但是这些请求每隔1s才被处理。