为什么要设计限流方案
- 就是限制流量，让一部人用户能下单，一部分用户不能下单，从而避免大流量把系统冲挂了；
- 流量远比想象的多，即使预估的再多，活动的真实流量也可能比预估的多；
- 系统活着比挂了要好，系统活着能服务小部分用户，系统挂了一个用户都服务不了；
- 宁愿只让少数人能用，也不要让所有人都不能用；
几种限流方案
限制并发的方案：全局计数器
- 限定同一时间只能有 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 个流量就都可以被处理；
限流的粒度
接口维度
总体维度
- 假设系统有 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);
}
