為什么要設計限流方案

• 就是限制流量，讓一部人用戶能下單，一部分用戶不能下單，從而避免大流量把系統沖掛了；
• 流量遠比想象的多，即使預估的再多，活動的真實流量也可能比預估的多；
• 系統活著比掛了要好，系統活著能服務小部分用戶，系統掛了一個用戶都服務不了；
• 寧愿只讓少數人能用，也不要讓所有人都不能用；

幾種限流方案

限制并發的方案：全局計數器

• 限定同一時間只能有 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<Object> future = executorService.submit(new Callable<Object>() {
        @Override
        public Object call() throws Exception {
            // 在 RocketMQ 的事務型消息中完成下單操作
            String stockLogId = itemService.initStockLog(itemId, amount);
            if (!mqProducer.transactionAsyncReduceStock(userModel.getId(), promoId, itemId, amount, stockLogId)) {
                throw new BusinessException(EmBusinessError.UNKNOWN_ERROR, "下單失敗");
            }
            return null;
        }
    });
    try {
        // 倒不是要什么返回值，就是主線程等提交到線程池中的任務執行完，好給前端響應；
        future.get();
    } catch (InterruptedException e) {
        throw new BusinessException(EmBusinessError.UNKNOWN_ERROR);
    } catch (ExecutionException e) {
        throw new BusinessException(EmBusinessError.UNKNOWN_ERROR);
    }

    return CommonReturnType.create(null);
}