在一個高并發系統中對流量的把控是非常重要的,當巨大的流量直接請求到我們的伺服器上沒多久就可能造成接口不可用,不處理的話甚至會造成整個應用不可用。
比如最近就有個這樣的需求,我作為用戶端要向
kafka
生産資料,而 kafka
的消費者則再源源不斷的消費資料,并将消費的資料全部請求到 web伺服器
,雖說做了負載(有4台 web伺服器
)但業務資料的量也是巨大的,每秒鐘可能有上萬條資料産生。如果生産者直接生産資料的話極有可能把 web伺服器
拖垮。
對此就必須要做限流處理,每秒鐘生産一定限額的資料到
kafka
,這樣就能極大程度的保證 web
的正常運轉。
其實不管處理何種場景,本質都是降低流量保證應用的高可用。
https://blog.didispace.com/spring-boot-request-limit/#%E5%B8%B8%E8%A7%81%E7%AE%97%E6%B3%95 常見算法
對于限流常見有兩種算法:
- 漏桶算法
- 令牌桶算法
漏桶算法比較簡單,就是将流量放入桶中,漏桶同時也按照一定的速率流出,如果流量過快的話就會溢出(
漏桶并不會提高流出速率
)。溢出的流量則直接丢棄。
如下圖所示:
這種做法簡單粗暴。
漏桶算法
雖說簡單,但卻不能應對實際場景,比如突然暴增的流量。
這時就需要用到
令牌桶算法
:
令牌桶
會以一個恒定的速率向固定容量大小桶中放入令牌,當有流量來時則取走一個或多個令牌。當桶中沒有令牌則将目前請求丢棄或阻塞。
相比之下令牌桶可以應對一定的突發流量.
https://blog.didispace.com/spring-boot-request-limit/#RateLimiter%E5%AE%9E%E7%8E%B0 RateLimiter實作
對于令牌桶的代碼實作,可以直接使用
Guava
包中的
RateLimiter
。
@Override
public BaseResponse<UserResVO> getUserByFeignBatch(@RequestBody UserReqVO userReqVO) {
//調用遠端服務
OrderNoReqVO vo = new OrderNoReqVO() ;
vo.setReqNo(userReqVO.getReqNo());
RateLimiter limiter = RateLimiter.create(2.0) ;
//批量調用
for (int i = 0 ;i< 10 ; i++){
double acquire = limiter.acquire();
logger.debug("擷取令牌成功!,消耗=" + acquire);
BaseResponse<OrderNoResVO> orderNo = orderServiceClient.getOrderNo(vo);
logger.debug("遠端傳回:"+JSON.toJSONString(orderNo));
}
UserRes userRes = new UserRes() ;
userRes.setUserId(123);
userRes.setUserName("張三");
userRes.setReqNo(userReqVO.getReqNo());
userRes.setCode(StatusEnum.SUCCESS.getCode());
userRes.setMessage("成功");
return userRes ;
詳見此 調用結果如下:
代碼可以看出以每秒向桶中放入兩個令牌,請求一次消耗一個令牌。是以每秒鐘隻能發送兩個請求。按照圖中的時間來看也确實如此(傳回值是擷取此令牌所消耗的時間,差不多也是每500ms一個)。
使用
RateLimiter
有幾個值得注意的地方:
允許
先消費,後付款
,意思就是它可以來一個請求的時候一次性取走幾個或者是剩下所有的令牌甚至多取,但是後面的請求就得為上一次請求買單,它需要等待桶中的令牌補齊之後才能繼續擷取令牌。
https://blog.didispace.com/spring-boot-request-limit/#%E6%80%BB%E7%BB%93 總結
針對于單個應用的限流
RateLimiter
夠用了,如果是分布式環境可以借助
redis
來完成。具體實作在接下來讨論。