应用限流
前言
在一個(gè)高并發(fā)系統(tǒng)中對流量的把控是非常重要的，當(dāng)巨大的流量直接請求到我們的服務(wù)器上沒多久就可能造成接口不可用，不處理的話甚至?xí)斐烧麄€(gè)應(yīng)用不可用。
比如最近就有個(gè)這樣的需求，我作為客戶端要向 kafka生產(chǎn)數(shù)據(jù)，而 kafka的消費(fèi)者則再源源不斷的消費(fèi)數(shù)據(jù)，并將消費(fèi)的數(shù)據(jù)全部請求到 web服務(wù)器，雖說做了負(fù)載(有4臺 web服務(wù)器)但業(yè)務(wù)數(shù)據(jù)的量也是巨大的，每秒鐘可能有上萬條數(shù)據(jù)產(chǎn)生。如果生產(chǎn)者直接生產(chǎn)數(shù)據(jù)的話極有可能把 web服務(wù)器拖垮。
對此就必須要做限流處理，每秒鐘生產(chǎn)一定限額的數(shù)據(jù)到 kafka，這樣就能極大程度的保證 web的正常運(yùn)轉(zhuǎn)。
其實(shí)不管處理何種場景，本質(zhì)都是降低流量保證應(yīng)用的高可用。
?
常見算法
對于限流常見有兩種算法:
- 漏桶算法
- 令牌桶算法
漏桶算法比較簡單，就是將流量放入桶中，漏桶同時(shí)也按照一定的速率流出，如果流量過快的話就會溢出( 漏桶并不會提高流出速率)。溢出的流量則直接丟棄。
如下圖所示:
這種做法簡單粗暴。
漏桶算法雖說簡單，但卻不能應(yīng)對實(shí)際場景，比如突然暴增的流量。
這時(shí)就需要用到 令牌桶算法:
令牌桶會以一個(gè)恒定的速率向固定容量大小桶中放入令牌，當(dāng)有流量來時(shí)則取走一個(gè)或多個(gè)令牌。當(dāng)桶中沒有令牌則將當(dāng)前請求丟棄或阻塞。
相比之下令牌桶可以應(yīng)對一定的突發(fā)流量.
?
RateLimiter實(shí)現(xiàn)
對于令牌桶的代碼實(shí)現(xiàn)，可以直接使用 Guava包中的 RateLimiter。
@Overridepublic BaseResponse<UserResVO> getUserByFeignBatch(@RequestBody UserReqVO userReqVO) {//調(diào)用遠(yuǎn)程服務(wù)OrderNoReqVO vo = new OrderNoReqVO() ;vo.setReqNo(userReqVO.getReqNo());RateLimiter limiter = RateLimiter.create(2.0) ;//批量調(diào)用for (int i = 0 ;i< 10 ; i++){double acquire = limiter.acquire();logger.debug("獲取令牌成功!,消耗=" + acquire);BaseResponse<OrderNoResVO> orderNo = orderServiceClient.getOrderNo(vo);logger.debug("遠(yuǎn)程返回:"+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 ;}詳見此。
調(diào)用結(jié)果如下:
代碼可以看出以每秒向桶中放入兩個(gè)令牌，請求一次消耗一個(gè)令牌。所以每秒鐘只能發(fā)送兩個(gè)請求。按照圖中的時(shí)間來看也確實(shí)如此(返回值是獲取此令牌所消耗的時(shí)間，差不多也是每500ms一個(gè))。
使用 RateLimiter有幾個(gè)值得注意的地方:
允許 先消費(fèi)，后付款，意思就是它可以來一個(gè)請求的時(shí)候一次性取走幾個(gè)或者是剩下所有的令牌甚至多取，但是后面的請求就得為上一次請求買單，它需要等待桶中的令牌補(bǔ)齊之后才能繼續(xù)獲取令牌。
?
總結(jié)
針對于單個(gè)應(yīng)用的限流 RateLimiter夠用了，如果是分布式環(huán)境可以借助 redis來完成。具體實(shí)現(xiàn)在接下來的分布式限流討論。
總結(jié)
