sentinel集群限流与负载均衡问题的思考

单机应用我们已知道怎么操作，但是假如有多个业务应用实例，那么你设置了限流规则后，每台实例会生成相同的流控规则。

比如，我们三台机器，8C 16G一台，4C 16G两台，8C的能承受3000qps,4C的能承受1500qps,那么理想状态总共可承载6000qps。

但是却只能设置1500qps，超过1500可能会导致两台4C的挂掉。

      基于这种问题，我们需要一个集群限流模式，通过一个server来专门统计调用量和分配令牌，进而产生了集群模式。和单机的区别在于单机是每个实例中进行统计，集群是有一专门token server实例进行统计。其他client会向token server去请求token。当达到集群的总阀值，当前实例被block。限流基于上述问题，我们就可以设置总qps为6000。

   sentinel的集群限流有两种身份：

   token client:流控客户端，用于向token server请求token,集群会返回给客户端结果，决定是否限流。

   token server:集群流控服务端，处理来自client的请求，根据配置的集群规则判断是否应发token。

单机流控只有一种身份，每个sentinel都是一个token server。

集群限流的token server是单点，挂掉，会退化成单机本地限流模式。在ClusterFlowConfig的fallbackToLocalWhenFail参数配置。

    阀值：两种模式：单机均摊和总体阀值

部署方式：

独立部署：单独启动一个token server来处理token client的请求。

嵌入式部署：在多个 sentinel-core 中选择一个实例设置为 token server，随着应用一起启动，其他的 sentinel-core 都是集群中 token client。

token server的切换：

http://:/setClusterMode?mode=

其中 mode 为 0 代表 client，1 代表 server，-1 代表关闭。

server主要依赖：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<dependencies>     <dependency>         <groupId>com.alibaba.cspgroupId>         <artifactId>sentinel-transport-simple-httpartifactId>         <version>1.4.1version>     dependency>     <dependency>         <groupId>com.alibaba.cspgroupId>         <artifactId>sentinel-cluster-server-defaultartifactId>         <version>1.4.1version>     dependency>     <dependency>         <groupId>com.alibaba.cspgroupId>         <artifactId>sentinel-datasource-nacosartifactId>         <version>1.4.1version>     dependency>     <dependency>         <groupId>org.apache.logging.log4jgroupId>         <artifactId>log4j-slf4j-implartifactId>         <version>2.9.1version>     dependency> dependencies>

client主要依赖：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<dependencies>     <dependency>         <groupId>com.alibaba.cspgroupId>         <artifactId>sentinel-transport-simple-httpartifactId>         <version>1.4.1version>     dependency>     <dependency>         <groupId>com.alibaba.cspgroupId>         <artifactId>sentinel-cluster-client-defaultartifactId>         <version>1.4.1version>     dependency>     <dependency>         <groupId>com.alibaba.cspgroupId>         <artifactId>sentinel-datasource-nacosartifactId>         <version>1.4.1version>     dependency>     <dependency>         <groupId>org.apache.logging.log4jgroupId>         <artifactId>log4j-slf4j-implartifactId>         <version>2.9.1version>     dependency> dependencies>

      Sentinel 支持系统自适应限流，Hystrix 所不支持的。当系统负载较高的时候，如果仍持续让请求进入，可能会导致系统崩溃，无法响应。在集群环境下，负载均衡把本应这台机器承载的流量转发到其它的机器上去，如果这个时候其它的机器也处在一个边缘状态的时候，这个增加的流量就会导致这台机器崩溃，最后导致整个集群不可用。针对这个情况，Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。

      我们可以思考，除了轮询负载均衡算法外，其它的算法比如hash都会导致流量到集群的每个节点都不一样，有的多有的少。集群流控虽然可以精确地控制整个集群的调用总量，结合单机限流兜底，可以更好地发挥流量控制的效果。

      问题思考：可能出现令牌申请成功了，若不同节点硬件配置不一致呢？单机均摊可能会超出其最大承受限额。

      此时想到的方案：监控所有节点的qps,avgRt，负载等。可按照最优负载进行自定义路由转发。

      限流是对资源的一种保护，使其不会瘫痪。不可避免会出现block。

补充：系统自适应限流官方给出的解释：自适应限流