SpringBoot中使用Guava實現(xiàn)單機令牌桶限流的示例
SpringBoot項目中如何對接口進行限流,有哪些常見的限流算法,如何優(yōu)雅的進行限流。
首先就讓我們來看看為什么需要對接口進行限流?
為什么要進行限流?
因為互聯(lián)網系統(tǒng)通常都要面對大并發(fā)大流量的請求,在突發(fā)情況下(最常見的場景就是秒殺、搶購),瞬時大流量會直接將系統(tǒng)打垮,無法對外提供服務。那為了防止出現(xiàn)這種情況最常見的解決方案之一就是限流,當請求達到一定的并發(fā)數(shù)或速率,就進行等待、排隊、降級、拒絕服務等。
例如,12306購票系統(tǒng),在面對高并發(fā)的情況下,就是采用了限流。在流量高峰期間經常會出現(xiàn)提示語;"當前排隊人數(shù)較多,請稍后再試!"
什么是限流?有哪些限流算法?
限流是對某一時間窗口內的請求數(shù)進行限制,保持系統(tǒng)的可用性和穩(wěn)定性,防止因流量暴增而導致的系統(tǒng)運行緩慢或宕機。
常見的限流算法有三種:
1. 計數(shù)器限流
計數(shù)器限流算法是最為簡單粗暴的解決方案,主要用來限制總并發(fā)數(shù),比如數(shù)據(jù)庫連接池大小、線程池大小、接口訪問并發(fā)數(shù)等都是使用計數(shù)器算法。
如:使用 AomicInteger 來進行統(tǒng)計當前正在并發(fā)執(zhí)行的次數(shù),如果超過域值就直接拒絕請求,提示系統(tǒng)繁忙。
2. 漏桶算法

漏桶算法思路很簡單,我們把水比作是請求,漏桶比作是系統(tǒng)處理能力極限,水先進入到漏桶里,漏桶里的水按一定速率流出,當流出的速率小于流入的速率時,由于漏桶容量有限,后續(xù)進入的水直接溢出(拒絕請求),以此實現(xiàn)限流。
3. 令牌桶算法

令牌桶算法的原理也比較簡單,我們可以理解成醫(yī)院的掛號看病,只有拿到號以后才可以進行診病。
系統(tǒng)會維護一個令牌(token)桶,以一個恒定的速度往桶里放入令牌(token),這時如果有請求進來想要被處理,則需要先從桶里獲取一個令牌(token),當桶里沒有令牌(token)可取時,則該請求將被拒絕服務。令牌桶算法通過控制桶的容量、發(fā)放令牌的速率,來達到對請求的限制。
基于Guava工具類實現(xiàn)限流
Google開源工具包Guava提供了限流工具類RateLimiter,該類基于令牌桶算法實現(xiàn)流量限制,使用十分方便,而且十分高效,實現(xiàn)步驟如下:
第一步:引入guava依賴包
<dependency> ????<groupId>com.google.guava</groupId> ????<artifactId>guava</artifactId> ????<version>30.1-jre</version> </dependency>
第二步:給接口加上限流邏輯
@Slf4j
@RestController
@RequestMapping("/limit")
public?class?LimitController?{
????/**
?????*?限流策略?:1秒鐘2個請求
?????*/
????private?final?RateLimiter?limiter?=?RateLimiter.create(2.0);
????private?DateTimeFormatter?dtf?=?DateTimeFormatter.ofPattern("yyyy-MM-dd?HH:mm:ss");
????@GetMapping("/test1")
????public?String?testLimiter()?{
????????//500毫秒內,沒拿到令牌,就直接進入服務降級
????????boolean?tryAcquire?=?limiter.tryAcquire(500,?TimeUnit.MILLISECONDS);
????????if?(!tryAcquire)?{
????????????log.warn("進入服務降級,時間{}",?LocalDateTime.now().format(dtf));
????????????return?"當前排隊人數(shù)較多,請稍后再試!";
????????}
????????log.info("獲取令牌成功,時間{}",?LocalDateTime.now().format(dtf));
????????return?"請求成功";
????}
}以上用到了RateLimiter的2個核心方法:create()、tryAcquire(),以下為詳細說明
- acquire() 獲取一個令牌, 改方法會阻塞直到獲取到這一個令牌, 返回值為獲取到這個令牌花費的時間
- acquire(int permits) 獲取指定數(shù)量的令牌, 該方法也會阻塞, 返回值為獲取到這 N 個令牌花費的時間
- tryAcquire() 判斷時候能獲取到令牌, 如果不能獲取立即返回 false
- tryAcquire(int permits) 獲取指定數(shù)量的令牌, 如果不能獲取立即返回 false
- tryAcquire(long timeout, TimeUnit unit) 判斷能否在指定時間內獲取到令牌, 如果不能獲取立即返回 false
- tryAcquire(int permits, long timeout, TimeUnit unit) 同上
第三步:體驗效果
通過訪問測試地址:http://127.0.0.1:8080/limit/test1,反復刷新并觀察后端日志
WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:37
WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:37
INFO LimitController:39 - 獲取令牌成功,時間2021-09-25 21:39:37
WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:37
WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:37
INFO LimitController:39 - 獲取令牌成功,時間2021-09-25 21:39:37WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:38
INFO LimitController:39 - 獲取令牌成功,時間2021-09-25 21:39:38
WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:38
INFO LimitController:39 - 獲取令牌成功,時間2021-09-25 21:39:38
從以上日志可以看出,1秒鐘內只有2次成功,其他都失敗降級了,說明我們已經成功給接口加上了限流功能。
當然了,我們在實際開發(fā)中并不能直接這樣用。至于原因嘛,你想呀,你每個接口都需要手動給其加上tryAcquire(),業(yè)務代碼和限流代碼混在一起,而且明顯違背了DRY原則,代碼冗余,重復勞動。代碼評審時肯定會被老鳥們給嘲笑一番,啥破玩意兒!
所以,我們這里需要想辦法將其優(yōu)化 - 借助自定義注解+AOP實現(xiàn)接口限流。
基于AOP實現(xiàn)接口限流
基于AOP的實現(xiàn)方式也非常簡單,實現(xiàn)過程如下:
第一步:加入AOP依賴
<dependency> ??<groupId>org.springframework.boot</groupId> ??<artifactId>spring-boot-starter-aop</artifactId> </dependency>
第二步:自定義限流注解
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
@Documented
public?@interface?Limit?{
????/**
?????*?資源的key,唯一
?????*?作用:不同的接口,不同的流量控制
?????*/
????String?key()?default?"";
????/**
?????*?最多的訪問限制次數(shù)
?????*/
????double?permitsPerSecond?()?;
????/**
?????*?獲取令牌最大等待時間
?????*/
????long?timeout();
????/**
?????*?獲取令牌最大等待時間,單位(例:分鐘/秒/毫秒)?默認:毫秒
?????*/
????TimeUnit?timeunit()?default?TimeUnit.MILLISECONDS;
????/**
?????*?得不到令牌的提示語
?????*/
????String?msg()?default?"系統(tǒng)繁忙,請稍后再試.";
}第三步:使用AOP切面攔截限流注解
@Slf4j
@Aspect
@Component
public?class?LimitAop?{
????/**
?????*?不同的接口,不同的流量控制
?????*?map的key為?Limiter.key
?????*/
????private?final?Map<String,?RateLimiter>?limitMap?=?Maps.newConcurrentMap();
????@Around("@annotation(com.jianzh5.blog.limit.Limit)")
????public?Object?around(ProceedingJoinPoint?joinPoint)?throws?Throwable{
????????MethodSignature?signature?=?(MethodSignature)?joinPoint.getSignature();
????????Method?method?=?signature.getMethod();
????????//拿limit的注解
????????Limit?limit?=?method.getAnnotation(Limit.class);
????????if?(limit?!=?null)?{
????????????//key作用:不同的接口,不同的流量控制
????????????String?key=limit.key();
????????????RateLimiter?rateLimiter?=?null;
????????????//驗證緩存是否有命中key
????????????if?(!limitMap.containsKey(key))?{
????????????????//?創(chuàng)建令牌桶
????????????????rateLimiter?=?RateLimiter.create(limit.permitsPerSecond());
????????????????limitMap.put(key,?rateLimiter);
????????????????log.info("新建了令牌桶={},容量={}",key,limit.permitsPerSecond());
????????????}
????????????rateLimiter?=?limitMap.get(key);
????????????//?拿令牌
????????????boolean?acquire?=?rateLimiter.tryAcquire(limit.timeout(),?limit.timeunit());
????????????//?拿不到命令,直接返回異常提示
????????????if?(!acquire)?{
????????????????log.debug("令牌桶={},獲取令牌失敗",key);
????????????????this.responseFail(limit.msg());
????????????????return?null;
????????????}
????????}
????????return?joinPoint.proceed();
????}
????/**
?????*?直接向前端拋出異常
?????*?@param?msg?提示信息
?????*/
????private?void?responseFail(String?msg)??{
????????HttpServletResponse?response=((ServletRequestAttributes)?RequestContextHolder.getRequestAttributes()).getResponse();
????????ResultData<Object>?resultData?=?ResultData.fail(ReturnCode.LIMIT_ERROR.getCode(),?msg);
????????WebUtils.writeJson(response,resultData);
????}
}第四步:給需要限流的接口加上注解
@Slf4j
@RestController
@RequestMapping("/limit")
public?class?LimitController?{
????@GetMapping("/test2")
????@Limit(key?=?"limit2",?permitsPerSecond?=?1,?timeout?=?500,?timeunit?=?TimeUnit.MILLISECONDS,msg?=?"當前排隊人數(shù)較多,請稍后再試!")
????public?String?limit2()?{
????????log.info("令牌桶l(fā)imit2獲取令牌成功");
????????return?"ok";
????}
????@GetMapping("/test3")
????@Limit(key?=?"limit3",?permitsPerSecond?=?2,?timeout?=?500,?timeunit?=?TimeUnit.MILLISECONDS,msg?=?"系統(tǒng)繁忙,請稍后再試!")
????public?String?limit3()?{
????????log.info("令牌桶l(fā)imit3獲取令牌成功");
????????return?"ok";
????}
}第五步:體驗效果
通過訪問測試地址:http://127.0.0.1:8080/limit/test2,反復刷新并觀察輸出結果:
正常響應時:
{"status":100,"message":"操作成功","data":"ok","timestamp":1632579377104}觸發(fā)限流時:
{"status":2001,"message":"系統(tǒng)繁忙,請稍后再試!","data":null,"timestamp":1632579332177}通過觀察得之,基于自定義注解同樣實現(xiàn)了接口限流的效果。
小結
一般在系統(tǒng)上線時我們通過對系統(tǒng)壓測可以評估出系統(tǒng)的性能閾值,然后給接口加上合理的限流參數(shù),防止出現(xiàn)大流量請求時直接壓垮系統(tǒng)。今天我們介紹了幾種常見的限流算法(重點關注令牌桶算法),基于Guava工具類實現(xiàn)了接口限流并利用AOP完成了對限流代碼的優(yōu)化。
到此這篇關于SpringBoot中使用Guava實現(xiàn)單機令牌桶限流的示例的文章就介紹到這了,更多相關SpringBoot Guava單機令牌桶限流內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
SpringBoot實現(xiàn)Logback輸出日志到Kafka方式
本文介紹了如何在SpringBoot應用中通過自定義Appender實現(xiàn)Logback輸出日志到Kafka,包括配置maven依賴、Kafka工具類和logback.xml配置2025-02-02
Jmeter參數(shù)化獲取序列數(shù)據(jù)實現(xiàn)過程
這篇文章主要介紹了Jmeter參數(shù)化獲取序列數(shù)據(jù)實現(xiàn)過程,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-07-07
Mybatis-Plus 條件構造器 QueryWrapper 的基本用法
這篇文章主要介紹了Mybatis-Plus - 條件構造器 QueryWrapper 的使用,通過實例代碼給大家介紹了查詢示例代碼及實現(xiàn)需求,代碼簡單易懂,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-09-09
Java JDK動態(tài)代理(AOP)用法及實現(xiàn)原理詳解
在本篇文章了小編給大家整理的是一篇關于Java JDK動態(tài)代理(AOP)用法及實現(xiàn)原理詳解內容,有需要的朋友們可以參考學習下。2020-10-10

