大流量|高并发抢购、秒杀实现


       在大流量场景下,抢购、下单量大等场景,由于业务应用系统的负载能力有限,为了防止非预期的请求对系统压力过大而拖垮业务应用系统。
       也就是面对大流量时,如何进行流量控制?
       服务接口的流量控制策略:分流、降级、限流等。本文讨论下限流策略,虽然降低了服务接口的访问频率和并发量,却换取服务接口和业务应用系统的高可用。

限流算法

常用的限流算法有漏桶算法、令牌桶算法
 1、漏桶算法
         漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:
         可见这里有两个变量,一个是桶的大小,支持流量突发增多时可以存多少的水(burst),另一个是水桶漏洞的大小(rate)。
         因为漏桶的漏出速率是固定的参数,所以,即使网络中不存在资源冲突(没有发生拥塞),漏桶算法也不能使流突发(burst)到端口速率.因此,漏桶算法对于存在突发特性的流量来说缺乏效率.
2、令牌桶算法
         令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务.
  令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量.

ReteLimiter完成限流、抢购场景实现

        RateLimiter是guava提供的基于令牌桶算法的实现类,Api使用简单,并且根据系统的实际情况来调整生成token的速率。
 maven引入

<dependency>
     <groupId>com.google.guava</groupId>
     <artifactId>guava</artifactId>
     <version>18.0</version>
</dependency>

代码

package com.lsq.einterview;

import com.google.common.util.concurrent.RateLimiter;

publicclassRateLimiterTest{
   /*
   简单使用Ratelimiter 实现限流功能,
   例:限制2秒钟只能有一个任务通过
    */
   publicstaticvoidmain(String[] args){
       //每秒通过0.5,所以2秒只能有一个通过
       RateLimiter rateLimiter = RateLimiter.create(0.5);
       for (int i = 0; i < 10; i++) {
           double acquire = rateLimiter.acquire();
           System.out.println(“任务执行,等待时间:”+acquire);
       }
   }
}

结果
     rateLimiter.acquire()返回的是本次执行等待的时间,我们可以清楚的看到,第一次无需等待,后边都需要等待两秒才可以执行到,
     rateLimiter.acquire()该方法会阻塞线程,直到令牌桶中能取到令牌为止才继续向下执行。

抢购实现1

       我们模拟抢购商品,总共有35件商品,模拟我们服务器只能承受住20个并发,超过20个服务器会挂掉,我们用rateLimiter来进行限流,
我们没有传参数,当然实际场景复杂很多。

package com.lsq.einterview.controller;

import com.google.common.util.concurrent.RateLimiter;
import com.lsq.einterview.domain.APIResponse;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;


@RestController()
@RequestMapping(“/api”)
publicclassRushBuyController{

   privatestaticfinal RateLimiter rateLimiter = RateLimiter.create(20);
   privatestaticint productCount=35;
   privatestaticfinal Object o=new Object();
   /**
    * 我们模拟抢购商品,模拟我们服务器只能承受住20个并发,超过10个服务器会挂掉,
    * 我们用rateLimiter来进行限流,
    * 我们也没有传参数,当然实际场景复杂很多。
    * @return 响应体
    */
   @RequestMapping(value = “/rushBuy2Product” , produces = “application/json;charset=utf-8”)
   public APIResponse rushBuy2Product(){
      System.out.println(“进入抢购:等待时间为:” + rateLimiter.acquire());
       boolean b = productStock();
       if (b){
           System.out.println(“抢购成功”);
       }else {
           System.out.println(“抢购失败”);
       }
       returnnew APIResponse<>().success();
   }

   /**
    * 抢购商品的库存
    * @return
    */
   privatebooleanproductStock(){
       if (productCount==0){
           returnfalse;
       }
       synchronized (o){
           if (productCount>0){
               –productCount;
               System.out.println(“剩余库存为:”+productCount);
               returntrue;
           }else {
               returnfalse;
           }
       }
   }

}

使用Jmeter测试开启100个线程进行测试


统计下商品抢购成功的数据,正好是35个抢购成功。
       我们看到在开始进入的请求不需要等待,直接执行,后面进来的需要等待的时间慢慢变长,因为拿不到令牌。
       但是这种方法有个很明显的缺陷,在实际并不适合使用,因为用户请求进来,拿不到令牌就需要等待执行,体验十分差。所以下面我们介绍另一种方式。

抢购实现2

       由于RateLimiter是属于单位时间内生成多少个令牌的方式,譬如0.1秒生成1个,那抢购就要看运气了,你刚好是在刚生成1个时进来了,那么你就能抢到,在这0.1秒内其他的请求就算白瞎了,只能寄希望于下一个0.1秒,而从用户体验上来说,不能让他在那一直阻塞等待,所以就需要迅速判断,该用户在某段时间内,还有没有机会得到令牌,这里就需要使用tryAcquire(long timeout, TimeUnit unit)方法,指定一个超时时间,一旦判断出在timeout时间内还无法取得令牌,就返回false。
注意,这里并不是真正的等待了timeout时间,而是被判断为即便过了timeout时间,也无法取得令牌。这个是不需要等待的。

package com.lsq.einterview.controller;

import com.google.common.util.concurrent.RateLimiter;
import com.lsq.einterview.domain.APIResponse;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.concurrent.TimeUnit;


@RestController()
@RequestMapping(“/api”)
publicclassRushBuyController{

   privatestaticfinal RateLimiter rateLimiter = RateLimiter.create(20);
   privatestaticint productCount=35;
   privatestaticfinal Object o=new Object();
   /**
    * 我们模拟抢购商品,模拟我们服务器只能承受住20个并发,超过10个服务器会挂掉,
    * 我们用rateLimiter来进行限流,
    * 我们也没有传参数,当然实际场景复杂很多。
    * @return 响应体
    */
   @RequestMapping(value = “/rushBuy2Product” , produces = “application/json;charset=utf-8”)
   public APIResponse rushBuy2Product(){
       boolean isAcquire = rateLimiter.tryAcquire(1, TimeUnit.SECONDS);
       if (!isAcquire){
           System.out.println(“进入抢购:在1s内无法拿到令牌,直接返回”);
           returnnew APIResponse<>().fail(“抢购失败”);
       }
       boolean b = productStock();
       if (b){
           System.out.println(“抢购成功”);
       }else {
           System.out.println(“抢购失败”);
       }
       returnnew APIResponse<>().success();
   }

   /**
    * 抢购商品的库存
    * @return
    */
   privatebooleanproductStock(){
       if (productCount==0){
           returnfalse;
       }
       synchronized (o){
           if (productCount>0){
               –productCount;
               System.out.println(“剩余库存为:”+productCount);
               returntrue;
           }else {
               returnfalse;
           }
       }
   }
}
结果

在我们的所有日志文件中统计:
抢购成功:35
抢购失败:23
无法拿到令牌,未参与抢购:42
总数为我们100个线程。

总结

        抢购实现的方式有很多种,在抢购2案例中,按照固定的单位时间进行分割,每个单位时间产生一个令牌,可供购买。我们可以想到平常参与抢购秒杀时,有时候你网速很快,但总是抢不到,现在明白了吧。
       真正的抢购不是这么简单,难度也复杂的多。所以不只是在代码中限流能实现的。瞬间的流量洪峰会冲垮服务器的负载,当几十万人抢购几件商品时,连接口都请求不进来,更别提接口里的令牌分配了。

本站所有文章均由网友分享,仅用于参考学习用,请勿直接转载,如有侵权,请联系网站客服删除相关文章。若由于商用引起版权纠纷,一切责任均由使用者承担
极客文库 » 大流量|高并发抢购、秒杀实现

Leave a Reply