秒杀系统 | 限流技术 | 令牌桶算法 vs 漏桶算法

为什么要设计限流方案

• 就是限制流量，让一部人用户能下单，一部分用户不能下单，从而避免大流量把系统冲挂了；
• 流量远比想象的多，即使预估的再多，活动的真实流量也可能比预估的多；
• 系统活着比挂了要好，系统活着能服务小部分用户，系统挂了一个用户都服务不了；
• 宁愿只让少数人能用，也不要让所有人都不能用；

几种限流方案

限制并发的方案：全局计数器

• 限定同一时间只能有 10 个线程能访问接口，最初级的方案，用全局计数器，比如需要限制的接口是下单接口，就在下单接口的 Controller 处加一个计数器，这个计数器是全局的，并且要支持并发下的加减操作，在 Controller 的入口处把计数器减 1，判断计数器的值是不是大于 0，大于 0 才往下走，在 Controller 出口处把 1 加回来；
• 这个方案太简单粗暴，并且在接口执行时间很长的情况下，比如 10s，其衡量的指标和 TPS 衡量的指标是不对等的，一般不用这种算法；

限制 TPS 或 QPS 的方案

• 令牌桶算法
• 漏桶算法

令牌桶算法原理

• 每秒桶里会新增 10 滴水；
• 客户端请求来了，会从桶里取 1 滴水；
• 每秒只能有 10 个客户端请求能取到水，其余的客户端请求无法往下走；
• 对应的 TPS 就是 10；

漏桶算法原理

• 桶一开始是满的，10 滴水；
• 桶以每秒 10 滴水的速度流出；
• 客户端的一次请求就是往桶里加 1 滴水；
• 如果桶是满的，客户端请求加的 1 水就加不进去，客户端的请求就不能往下走；
• 对应的 TPS 就是 10；

令牌桶算法 vs 漏桶算法

• 漏桶算法是无法应对突发流量的，请求以非固定的速率进入漏桶，漏桶的容量是固定的，超过漏桶容量的请求就会被拒绝掉，请求会以固定的流速或 0 流速，漏向后端的系统；
• 令牌桶算法可以应对令牌桶令牌个数的突发流量，令牌桶中会以固定的速率接令牌，比如有一段时间，请求很少，令牌桶中的令牌就会上升，直至到达令牌桶的满载状态，比如 1000 个令牌，此时，如果有 1000 个流量同时到来，这 1000 个流量就都可以被处理；

限流的粒度

接口维度

• 系统中的单个接口的 TPS；

总体维度

• 假设系统有 10 个接口，每个接口的 TPS 是 5，那么系统总的 TPS 是达不到 50 的，系统的总流量一般要限制在所有接口的 TPS 总和的 80%；

限流范围

集群限流

• 依赖 Redis 或其他中间件做统一计数器，往往会产生性能瓶颈；

单机限流

• 负载均衡的前提下，单机平均限流的效果更好；

基于 Guava 的 RateLimiter 的令牌桶算法的保护

初始化令牌桶

• 压测得到的下单接口的 TPS 是 350，保护性的在令牌桶里放了 300 个令牌，下单接口能承受的 TPS 就是 300；

private RateLimiter orderCreateRateLimiter;

@PostConstruct
public void init() {
    orderCreateRateLimiter = RateLimiter.create(300);
}

用令牌桶保护下单接口

• 在下单接口的入口位置，设置令牌桶的保护代码；

@RequestMapping(value = "/createorder", method = {RequestMethod.POST}, consumes = {CONTENT_TYPE_FORMED})
@ResponseBody
public CommonReturnType createOrder(@RequestParam(name = "itemId") Integer itemId,
                                    @RequestParam(name = "amount") Integer amount,
                                    @RequestParam(name = "promoId", required = false) Integer promoId,
                                    @RequestParam(name = "promoToken", required = false) String promoToken)
        throws BusinessException {

    // 令牌桶保护
    if (!orderCreateRateLimiter.tryAcquire()) {
        throw new BusinessException(EmBusinessError.RATE_LIMITER);
    }

    // 校验用户是否登录
    String token = httpServletRequest.getParameterMap().get("token")[0];
    if (StringUtils.isEmpty(token)) {
        throw new BusinessException(EmBusinessError.USER_NOT_LOGIN, "用户还未登录，不能下单");
    }
    UserModel userModel = (UserModel) redisTemplate.opsForValue().get(token);
    if (userModel == null) {
        throw new BusinessException(EmBusinessError.USER_NOT_LOGIN, "用户还未登录，不能下单");
    }

    // 校验秒杀令牌是否正确
    if (promoId != null) {
        String inRedisPromoToken = (String)redisTemplate.opsForValue()
                .get("promo_token_" + promoId + "_userid_" + userModel.getId() + "_itemid_" + itemId);
        if (inRedisPromoToken == null) {
            throw new BusinessException(EmBusinessError.PARAMETER_VALIDATION_ERROR, "秒杀令牌校验失败");
        }
        if (!StringUtils.equals(promoToken, inRedisPromoToken)) {
            throw new BusinessException(EmBusinessError.PARAMETER_VALIDATION_ERROR, "秒杀令牌校验失败");
        }
    }

    // 拥塞窗口为 20 的等待队列，用来队列化泄洪，在一个 Tomcat 上，同一时间只能有 20 个请求能下来做下单，其他请求都要排队
    Future