為什么要設計限流方案
- 就是限制流量,讓一部人用戶能下單,一部分用戶不能下單,從而避免大流量把系統沖掛了;
- 流量遠比想象的多,即使預估的再多,活動的真實流量也可能比預估的多;
- 系統活著比掛了要好,系統活著能服務小部分用戶,系統掛了一個用戶都服務不了;
- 寧愿只讓少數人能用,也不要讓所有人都不能用;
幾種限流方案
限制并發的方案:全局計數器
- 限定同一時間只能有 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);
}
最后編輯于 :
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。