RateLimiter抢购秒杀限流

2018-06-09 17:34:07
810次阅读
0个评论

常用的限流算法有漏桶算法和令牌桶算法,guava的RateLimiter使用的是令牌桶算法,也就是以固定的频率向桶中放入令牌,例如一秒钟10枚令牌,实际业务在每次响应请求之前都从桶中获取令牌,只有取到令牌的请求才会被成功响应,获取的方式有两种:阻塞等待令牌或者取不到立即返回失败


也许是出于简单起见,RateLimiter 中的时间窗口能且仅能为 1s,如果想搞其他时间单位的限流,只能另外造轮子。

RateLimiter 有一个有趣的特性是「前人挖坑后人跳」,也就是说 RateLimiter 允许某次请求拿走超出剩余令牌数的令牌,但是下一次请求将为此付出代价,一直等到令牌亏空补上,并且桶中有足够本次请求使用的令牌为止。这里面就涉及到一个权衡,是让前一次请求干等到令牌够用才走掉呢,还是让它先走掉后面的请求等一等呢?Guava 的设计者选择的是后者,先把眼前的活干了,后面的事后面再说。

测试代码


public class RateLimiterMain {
    public static void main(String[] args) {
        RateLimiter rateLimiter = RateLimiter.create(2);
        System.out.println(rateLimiter.acquire(5));
        System.out.println(rateLimiter.acquire(2));
        System.out.println(rateLimiter.acquire(1));
    }
}

输出内容:


0.0
2.496889
0.992149


可以看出,令牌桶每秒只能产生2个令牌,我们可以第一次取出5个,但是第二个再去取令牌的时候,需要等2.5s,也就是第一次令牌取完后,需要等2.5s才能取到令牌。同样的,第三次取1个令牌的时候,也需要等待第二次的1s的时间。也就是,取的速率可以超过令牌产生的速率,但是下一次再次去取的时候,需要阻塞等待。


上面的例子虽然限制了单位时间内对DB的操作,但是对用户是不友好的,因为他需要等待,不能迅速的得到响应。当你有1万个并发请求,一秒只能处理10个,那剩余的用户都会陷入漫长的等待。所以我们需要对应用降级,一旦判断出某些请求是得不到令牌的,就迅速返回失败,避免无谓的等待。
由于RateLimiter是属于单位时间内生成多少个令牌的方式,譬如0.1秒生成1个,那抢购就要看运气了,你刚好是在刚生成1个时进来了,那么你就能抢到,在这0.1秒内其他的请求就算白瞎了,只能寄希望于下一个0.1秒,而从用户体验上来说,不能让他在那一直阻塞等待,所以就需要迅速判断,该用户在某段时间内,还有没有机会得到令牌,这里就需要使用tryAcquire(long timeout, TimeUnit unit)方法来非阻塞的获取,可以实时返回结果,指定一个超时时间,一旦判断出在timeout时间内还无法取得令牌,就返回false。注意,这里并不是真正的等待了timeout时间,而是被判断为即便过了timeout时间,也无法取得令牌。这个是不需要等待的。


RateLimiter rateLimiter = RateLimiter.create(10);  
public Object miao(int count, String code) {  

        //判断能否在1秒内得到令牌,如果不能则立即返回false,不会阻塞程序  
        if (!rateLimiter.tryAcquire(1000, TimeUnit.MILLISECONDS)) {  
            System.out.println("短期无法获取令牌,真不幸,排队也瞎排");  
            return "失败";  
        }  
        if (goodInfoService.update(code, count) > 0) {  
            System.out.println("购买成功");  
            return "成功";  
        }  
        System.out.println("数据不足,失败");  
        return "失败";  
    }


收藏00

登录 后评论。没有帐号? 注册 一个。