基于分布式环境下限流系统的设计.docxVIP

基于分布式环境下限流系统的设计 2021-11-28 业务背景 就拿前些天的双十一的 “抢券活动” 来说，一般是设置整点开头抢的，你想想，淘宝的用户群体格外大，可以达到亿级别，而服务接口每秒能处理的量是有限的，那么这个时候问题就会消灭，我们如何通过程序来把握用户抢券呢，于是就必需加上这个限流功能了。 生产环境 1、服务接口所能供应的服务上限（limit）假如是 500次/s 2、用户恳求接口的次数未知，QPS可能达到 800次/s，1000次/s，或者更高 3、当服务接口的访问频率超过 500次/s，超过的量将拒绝服务，多出的信息将会丢失 4、线上环境是多节点部署的，但是调用的是同一个服务接口 于是，为了保证服务的可用性，就要对服务接口调用的速率进行限制（接口限流）。 什么是限流？ 限流是对系统的出入流量进行把握，防止大流量出入，导致资源不足，系统不稳定。 限流系统是对资源访问的把握组件，把握次要的两个功能：限流策略和熔断策略，对于熔断策略，不同的系统有不同的熔断策略诉求，有的系统期望直接拒绝、有的系统期望排队等待、有的系统期望服务降级、有的系统会定制本人的熔断策略，这里只针对限流策略这个功能做具体的设计。 限流算法 1、限制瞬时并发数 Guava RateLimiter 供应了令牌桶算法实现：平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现。 2、限制某个接口的时间窗最大恳求数 即一个时间窗口内的恳求数，如想限制某个接口/服务每秒/每分钟/每天的恳求数/调用量。如一些基础服务会被很多其他系统调用，比如商品详情页服务会调用基础商品服务调用，但是怕由于更新量比较大将基础服务打挂，这时我们要对每秒/每分钟的调用量进行限速；一种实现方式如下所示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 LoadingCache counter = CacheBuilder.newBuilder() .expireAfterWrite(2, TimeUnit.SECONDS) .build(new CacheLoader() { @Override public AtomicLong load(Long seconds) throws Exception { return new AtomicLong(0); } }); long limit = 1000; while(true) { //得到当前秒 long currentSeconds = System.currentTimeMillis() / 1000; if(counter.get(currentSeconds).incrementAndGet() limit) { System.out.println(限流了: + currentSeconds); continue; } //业务处理 } 使用Guava的Cache来存储计数器，过期时间设置为2秒（保证1秒内的计数器是有的），然后我们猎取当前时间戳然后取秒数来作为KEY进行计数统计和限流，这种方式也是简约粗暴，刚才说的场景够用了。 3、令牌桶 算法描述： 假如用户配置的平均发送速率为r，则每隔1/r秒一个令牌被加入到桶中 假设桶中最多可以存放b个令牌。假如令牌到达时令牌桶已经满了，那么这个令牌会被丢弃 当流量以速率v进入，从桶中以速率v取令牌，拿到令牌的流量通过，拿不到令牌流量不通过，执行熔断规律 属性 长期来看，符合流量的速率是遭到令牌添加速率的影响，被稳定为：r 由于令牌桶有肯定的存储量，可以抵抗肯定的流量突发情况 M是以字节/秒为单位的最大可能传输速率。 Mr T max = b/(M-r) 承受最大传输速率的时间 B max = T max * M 承受最大传输速率的时间内传输的流量 优点：流量比较平滑，并且可以抵抗肯定的流量突发情况 4、GOOGLE GUAVA 供应的工具库中 RATELIMITER 类（内部也是接受令牌桶算法实现） 最快的方式是使用 RateLimit 类，但是这仅限制在单节点，假如是分布式系统，每个节点的 QPS 是一样的，恳求量到服务接口那的话就是 QPS * 节点数 了。所以这种方案在分布式的情况下不适用！ 5、基于 REDIS 实现，存储两个 KEY，一个用于计时，一个用于计数。恳求每调用一次，计数器添加 1，若在计时器时间内计数器未超过阈值，则可以处理任务。 这种能够很好地处理了分布式环境下多实例所导致的并发问题。由于使用redis设置的计时器和计数器均是全局独一的，不管多少个节点，它们使用的都是同样的计时器和计数器，因而可以做到格外精准的流控。