大家好,我是飄渺。SpringBoot老鳥系列的文章已經寫了四篇,每篇的閱讀反響都還不錯,那今天繼續給大家帶來老鳥系列的第五篇,來聊聊在SpringBoot項目中如何對接口進行限流,有哪些常見的限流算法,如何優雅的進行限流(基于AOP)。
首先就讓我們來看看為什么需要對接口進行限流?
為什么要進行限流?
因為互聯網系統通常都要面對大并發大流量的請求,在突發情況下(最常見的場景就是秒殺、搶購),瞬時大流量會直接將系統打垮,無法對外提供服務。那為了防止出現這種情況最常見的解決方案之一就是限流,當請求達到一定的并發數或速率,就進行等待、排隊、降級、拒絕服務等。
例如,12306購票系統,在面對高并發的情況下,就是采用了限流。 在流量高峰期間經常會出現提示語;“當前排隊人數較多,請稍后再試!”
什么是限流?有哪些限流算法?
限流是對某一時間窗口內的請求數進行限制,保持系統的可用性和穩定性,防止因流量暴增而導致的系統運行緩慢或宕機。
常見的限流算法有三種:
1. 計數器限流
計數器限流算法是最為簡單粗暴的解決方案,主要用來限制總并發數,比如數據庫連接池大小、線程池大小、接口訪問并發數等都是使用計數器算法。
如:使用 AomicInteger 來進行統計當前正在并發執行的次數,如果超過域值就直接拒絕請求,提示系統繁忙。
2. 漏桶算法
漏桶算法思路很簡單,我們把水比作是請求
,漏桶比作是系統處理能力極限
,水先進入到漏桶里,漏桶里的水按一定速率流出,當流出的速率小于流入的速率時,由于漏桶容量有限,后續進入的水直接溢出(拒絕請求),以此實現限流。
3. 令牌桶算法
令牌桶算法的原理也比較簡單,我們可以理解成醫院的掛號看病,只有拿到號以后才可以進行診病。
系統會維護一個令牌(token
)桶,以一個恒定的速度往桶里放入令牌(token
),這時如果有請求進來想要被處理,則需要先從桶里獲取一個令牌(token
),當桶里沒有令牌(token
)可取時,則該請求將被拒絕服務。令牌桶算法通過控制桶的容量、發放令牌的速率,來達到對請求的限制。
基于Guava工具類實現限流
Google開源工具包Guava提供了限流工具類RateLimiter,該類基于令牌桶算法實現流量限制,使用十分方便,而且十分高效,實現步驟如下:
第一步:引入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 "當前排隊人數較多,請稍后再試!"; } log.info("獲取令牌成功,時間{}", LocalDateTime.now().format(dtf)); return "請求成功"; } }
以上用到了RateLimiter的2個核心方法:create()
、tryAcquire()
,以下為詳細說明
- acquire() 獲取一個令牌, 改方法會阻塞直到獲取到這一個令牌, 返回值為獲取到這個令牌花費的時間
- acquire(int permits) 獲取指定數量的令牌, 該方法也會阻塞, 返回值為獲取到這 N 個令牌花費的時間
- tryAcquire() 判斷時候能獲取到令牌, 如果不能獲取立即返回 false
- tryAcquire(int permits) 獲取指定數量的令牌, 如果不能獲取立即返回 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:37 WARN 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次成功,其他都失敗降級了,說明我們已經成功給接口加上了限流功能。
當然了,我們在實際開發中并不能直接這樣用。至于原因嘛,你想呀,你每個接口都需要手動給其加上tryAcquire()
,業務代碼和限流代碼混在一起,而且明顯違背了DRY原則,代碼冗余,重復勞動。代碼評審時肯定會被老鳥們給嘲笑一番,啥破玩意兒!
所以,我們這里需要想辦法將其優化 - 借助自定義注解+AOP實現接口限流。
基于AOP實現接口限流
基于AOP的實現方式也非常簡單,實現過程如下:
第一步:加入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 ""; /** * 最多的訪問限制次數 */ double permitsPerSecond () ; /** * 獲取令牌最大等待時間 */ long timeout(); /** * 獲取令牌最大等待時間,單位(例:分鐘/秒/毫秒) 默認:毫秒 */ TimeUnit timeunit() default TimeUnit.MILLISECONDS; /** * 得不到令牌的提示語 */ String msg() default "系統繁忙,請稍后再試."; }
第三步:使用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)) { // 創建令牌桶 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 = "當前排隊人數較多,請稍后再試!") public String limit2() { log.info("令牌桶limit2獲取令牌成功"); return "ok"; } @GetMapping("/test3") @Limit(key = "limit3", permitsPerSecond = 2, timeout = 500, timeunit = TimeUnit.MILLISECONDS,msg = "系統繁忙,請稍后再試!") public String limit3() { log.info("令牌桶limit3獲取令牌成功"); return "ok"; } }
第五步:體驗效果
通過訪問測試地址: http://127.0.0.1:8080/limit/test2,反復刷新并觀察輸出結果:
正常響應時:
{"status":100,"message":"操作成功","data":"ok","timestamp":1632579377104}
觸發限流時:
{"status":2001,"message":"系統繁忙,請稍后再試!","data":null,"timestamp":1632579332177}
通過觀察得之,基于自定義注解同樣實現了接口限流的效果。
小結
一般在系統上線時我們通過對系統壓測可以評估出系統的性能閥值,然后給接口加上合理的限流參數,防止出現大流量請求時直接壓垮系統。今天我們介紹了幾種常見的限流算法(重點關注令牌桶算法),基于Guava工具類實現了接口限流并利用AOP完成了對限流代碼的優化。
在完成優化后業務代碼和限流代碼解耦,開發人員只要一個注解,不用關心限流的實現邏輯,而且減少了代碼冗余大大提高了代碼可讀性,代碼評審時誰還能再笑話你?
源碼下載
https://github.com/jianzh5/cloud-blog/
到此這篇關于SpringBoot 進行限流的操作方法的文章就介紹到這了,更多相關SpringBoot限流內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家!
原文鏈接:https://blog.csdn.net/jianzhang11/article/details/120700247