流控相关

https://segmentfault.com/a/1190000010237714

http://jm.taobao.org/2018/01/22/post20180122/

对系统的访问速率，资源占用，消费者并发链接数，并行访问数 进行限制，在请求量超过阈值时，经过拒绝等方式，防止服务接口的雪崩和挂掉

同步RPC类调用，针对服务提供者的并发全局流控，或针对服务消费者的并发局部流控 

异步MQ类调用，在订阅端限流，针对消息订阅者的并发流控，或针对消息订阅者的消费延时流控。

单机流控  -> 全局流控  -> 动态流控

1. 全局计数器的存储 redis

     记录两个信息，计数和记间， 由于限制通常是多少请求每秒之类的，过时重置

2. 如何上报请求

    全量、定时批量上报

    通常还须要每台机器部署agent来完成上报和流控判断，业务模块和agent之间也要通信

1）将流控服务作成原子化，目前不管使用redis仍是ckv，加锁方式并发下没法保证性能，原生的incr方式要解决过时时间的问题，须要的技术门槛和开发成本都比较高；

2）从上报统计方式看，全量上报对请求量巨大的业务部门来讲不大可行，定时批量上报又没法保证明时流控；

3）接入全局流控每台机器都须要部署agent，agent可否正常工做影响全局流控的使用，同时部署及运维的成本不低；

QPS ， 并发线程数 ， 黑白名单 ， 加权分级 

令牌桶控制的是一个时间窗口内的经过的数据量，在 API 层面咱们常说的 QPS、TPS，正好是一个时间窗口内的请求量或者事务量，只不过期间窗口限定在 1s 罢了。

RateLimiter 对简单的令牌桶算法作了一些工程上的优化，具体的实现是 SmoothBursty。须要注意的是，RateLimiter 的另外一个实现 SmoothWarmingUp，就不是令牌桶了，而是漏桶算法。也许是出于简单起见，RateLimiter 中的时间窗口能且仅能为 1s，若是想搞其余时间单位的限流，只能另外造轮子。

http://www.liuhaihua.cn/archives/529035.html

配额拉取的概念，替换通常统计上报的方式，取而代之的是每一个key初始化时写入流控阈值，每一个业务机器并不是上报请求量，而是访问ckv拉取配额到本地保存，本地配额消耗完毕再次拉取，相似余库存扣减。

agent要完成的功能比较简单，主要功能托管到业务流控api。好比拉取配额设置10，即正常10个请求要拉取一次配额，这时流控api会请求一次ckv拉取配额，这个业务请求耗时增长约1ms。

方案对容灾作了充分的考虑，主要解决方式是全局及单机流控同时启用，即基于ckv的全局流控和基于单机共享内存的单机流控都同时工做。

全局流控失效（ckv挂掉或连续超时致使拉取配额失败），流控api判断出这种状况后，暂时中止使用全局流控，而单机流控依然能够正常工做，流控api按期去探查（好比30s）全局流控是否恢复可用，再启动全局流控。

因为使用ckv的incr以及配额拉取的实现方式，全局流控接入服务请求的能力获得成本增加。

目前方案单独申请了一块ckv，容量为6G，使用incr的方式，压测性能达到9w+/s。

对业务空接口（Appplatform框架）作流控压测，使用30台v6虚拟机，单机50进程，压测性能达到50w+/s。

单接口50w/s的请求的服务接入，一样也能知足多接口整体服务请求量50w+/s的全局流控需求。

上述的压测瓶颈主要是Appplatform框架的性能缘由，因为拉取配额值是根据流控阈值设定（通常>10），50w+的请求量只有不到5w的ckv访问量，ckv没到瓶颈。

支持平行扩展流控能力，一套全局流控部署能知足流控的服务请求量是达百万/s，更大的服务请求量须要部署多套全局流控。

支持升级到动态流控能力，ckv写入的流控阈值是经过定时管理器完成，目前业务已经作了健康度上报，定时管理器只须要对接健康度数据，分析接口当前请求状况，动态调整流控阈值便可达到动态流控能力。

一、管理定时器：

根据配置，将频率限制任务的配额值，写入多个带时间信息的key。好比频率限制任务1配了阈值为5000/s的全局流控，那么就以每一秒生成一个kv为例：

key为task1_20170617000000、task1_2017061700000一、task1_20170617000002等

value为5000

二、共享内存：

保存每个任务流控相关的本机信息，包括流控状态、本地配额、配额锁等。

三、流控API：

业务经过流控api，请求先扣减本地配额（原子操做），若是配额<=0，就从ckv拉取配额到共享内存中，若是没配额拉取，就作说明流控生效。

 具体，除了上述，在本地配额将满时候提早拉取必定配额，在即将用尽时增长几率失败等，在基于@注解定义类加载检查方式拉取配额，基于dubbo filter扩展方式