分布式限流

1. 分布式限流

 限流是对 出入流量 进行控制 ， 防止大量流入，导致资源不足，系统不稳定。   限流系统是对资源访问的控制组件 ， 控制主要有两个功能 ， 限流策略和熔断策略，对不同的系统有不同的熔断策略诉求，   有的系统希望直接拒绝、有的系统希望排队等待、有的系统希望服务降级、有的系统会定制自己的熔断策略，这里只对 限流策略  这个功能做详细的设计。
   Guava RateLimiter提供了令牌桶算法实现：平滑突发限流(SmoothBursty) 和 平滑预热限流(SmoothWarmingUp)实现
   即一个时间窗口内的请求数，如想限制某个接口/服务 每秒/每分钟/每天的 请求数/调用量。如一些基础服务会被很多其他系统调用，   比如商品详情页服务会调用基础商品服务调用，但是怕因为更新量比较大，将基础服务打挂，这时我们需要对每秒/每分钟的调用量进行限速；
   此次控制分布式瞬发限流的设计类似于 窗口最大请求数设计业务请求，不满足类似于Guava RateLimiter中的特性( 瞬发限流特性 )   接下来将实现一种分布式 瞬发限流的实现 (令牌桶算法实现与RateLimiter类似，但基于分布式的实现)
    distributed-current-limiter 

2. 分布式限流的运行原理？

分布式编程架构技术我们在前几期的文章中已经给大家简单分析过很多次了，今天我们就一起来了解一下API网关分布式限流的运行原理都有哪些。




API网关中针对一个API、API分组、接入应用APPID,IP等进行限流。这些限流条件都将会产生一个限流使用的key，在后续的限流中都是对这个key进行限流。

限流算法通常在API网关中可以采用令牌桶算法实现。

必须说明一点的是分布式限流由于有网络的开销，TPS的支持隔本地限流是有差距的，因此在对于TPS要求很高的场景，建议采用本地限流进行处理。

下面讨论我们应该采用redis的哪一种分布式锁的方案：

由于redis事务要得到锁的效果需要在高TPS时会产生大量的无效的访问请求，所以不建议在这种场景下使用。

SETNX/EX的锁方案会产生在过期时间的问题，同时也有异步复制master数据到slave的问题。相比lua方案会产生更多的不稳定性。

我建议采用lua的方案来实施分布式锁，因为都是单进程单线程的执行，因此在TPS上和二种方案没有大的区别，而且由于只是一个lua脚本在执行，甚至是可能纯lua执行可能会有更高的TPS。当然是lua脚本中可能还是会去设置过期时间，但是应用server宕机并不会影响到redis中的锁。当然master异步复制的问题还是有，但是并不会造成问题，因为数据只会有1个lua脚本执行问题，下一个执行就正常了。

在实现方案的时候使用了Jedis库，云南java课程http://www.kmbdqn.cn/认为有一些问题在方案的实现层面我已经去做过验证了，可能也会是读者的疑问。