全局流控介绍和实现思路

全局流控

一、描述：

控制集群范围内接口每秒钟的有效请求数，例如有一个500台应用的系统集群，现预测数据库集群能够支持的最大的qps是10000【通过压测来判断数据库达到瓶颈时能够支持的访问量】，接口需要访问数据库那么可以判断出系统的压力主要在数据库上，而不在应用上，因此需要对请求进行流量控制防止数据库压力过大，这个时候就可以通过全局流控来保护数据库。

二、特点：

1、粒度控制到接口

2、阈值位接口总阈值

3、支持双机房分开控制

4、依赖redis服务

三、使用场景：

1.保护整体服务请求

2.适用于流量较小的服务

3.需要精确进行tps流控

4.适用于交易线：交易链路像加车、提交订单、支付等操作，而非浏览线像首页、四级页、搜索查询之类的。

四、使用举例：

1、机器无压力，主要压力在库，可设置全局流控。

2、适用于对整体TPS有要求的流控限制，如某个接单接口只能接入5000tps，如果tps大了会造成下游系统问题，此时就不适用于分布式流控，可采用全局流控。

五、实现思路和原理

1、判断当前时间秒接口流控状态，如果已经被流控直接返回，如果未流控做流控判断和配额扣减处理

2、从本地配额缓存中获取接口当前秒key的配额ConcurrentHashMap<key, 配额对象>

3、如果当前秒key对应的配额对象不存在：从redis获取当前时间秒对应接口的配额，redis key为interface_code_secondKey, value 为全局的配额。

从redis获取配额的操作为原子操作，如下所示

String sha1 = loadScript(timeKey,"local key=KEYS[1];" +"local valve=KEYS[2];" +"local step=KEYS[3];" +"local expire=KEYS[4];" +"local remnant;" +"local exists=redis.call(\"EXISTS\",key);" +"if(exists==1) then remnant=redis.call(\"DECRBY\",key,step);" +"else remnant=redis.call(\"DECRBY\",key,(step-valve));" +"redis.call(\"EXPIRE\",key,expire);end return remnant;");

脚本中变量介绍 value: 全局流控的阈值； step: 每次拉取时给应用分配的配额【本次申请的配额】； expire：过期时间； remnant：全局配额剩余数量；

先判断key是否存在，key不存在新建key并扣除本次拉取的配额， key存在则直接扣除本次拉取的配额，返回总的配额余额。

（1）如果总的配额余额>=0说明配额充足，说明本次应用申请的配额可以满足，更新本地配额为申请的配额；

（2）如果总的配额余额 < 0 并且 |总的配额余额绝对值| < 本次申请的配额，说明本次申请的配额不够但是可以满足部分，更新本地配额为总的配额余额 + 本次申请的配额

（3）如果总的配额余额<0 并且 |总的配额余额绝对值| >= 本次申请的配额, 说明本次申请的配额完全不能够满足，不更新本次配额，更新流控状态为配额不足被流控。

4、如果当前秒key对应的配额对象存在：先判断流控状态，如果状态为被流控直接返回流控。如果状态为未被流控，先看本地配额是否够扣，够扣的话获取本地配额锁然后扣减本地配额，扣完后释放本地配额锁；如果本地配额不够扣，从redis拉取配额，拉取的方法跟步骤3中的原子方法一致。

5、异常处理：如果从redis拉取配额的时候发生异常，则更新本地的流控状态为流控失效，不做后续流控处理，并记录失效时间点，流控判断状态是如果发现状态为流控失效并且当前时间与流控失效时间间隔没有超过30s直接继续执行，否则继续从redis拉取配额并做流控处理。

六、扩展

全局流控的思路其实可以拓展到实际业务应用中，例如支持百万或者千万级tps的秒杀抢购之类的，秒杀或者抢购的对象数量就相当于流控接口的阈值。

后续会继续写篇文章介绍下分布式流控和实现思路，分布式流控的实现其实比起全局流控来说更加简单。