一個問題往往會引出了一連串的問題,知識的盲區就這樣被自己悄悄的發現了。車轍在自己動手寫限流注解時,遇到的問題那是真一個比一個多:
- 限流算法用哪個比較合適。
- 如何用註解實現限流。
- 如何對每個方法單獨限流。
- 長字符串如何轉換成短字符串。
- 64 進制 or 62進制。
- LRU 是什麼,如何用簡單的數據結構實現。
什麼是限流
對服務器接收到的請求作出限制,只有一部分請求能真正到達服務器,其他的請求可以延遲,也可以拒絕。從而避免所有請求到數據庫,打垮 DB。
舉個生活中大家可能遇到的場景,特別是北上廣深或者新一線城市,杭州一號線地鐵,鳳起路站,在客流量到達一定峰值時,警察叔叔♀可能就不讓你進地鐵,讓使用其他交通工具了️。。。都是淚啊!
限流算法用哪個比較合適
關於限流算法,網上的解釋一大堆,漏桶算法,令牌桶算法等等,百度一下,你就知道,在這裡車轍用最簡單的計數器算法作為實現。
計數器算法
- 將一秒鐘分為 10 個階段,每個階段 100ms。
- 每隔 100ms 記錄下接口調用的次數。
- 當然隨著時間的流逝,階段會越來越多。這時候可以將最前面的 n 個階段刪除,只保留 10 個,也就是隻剩 1s。
- 最後一個減去第一個的次數,就是 1s 中內該接口調用的次數。
如何用註解實現限流
在用 nginx 限流時,是將 nginx 作為代理層攔截請求處理,那麼在 Spring 中代理層就是 AOP 啦。
AOP
在 web 服務器中,有很多場景都是可以靠 AOP 實現的,比如:
- 打印日誌,記錄時間類,方法,參數。
- 利用反射設置分頁 PageRow、PageNum 的默認值。
- 遊戲場景,判斷遊戲是否已經結束,不用每個方法都去判斷。
- 解密,驗籤等等。
定時任務
在計數器算法中我們提到,每隔 100ms 需要記錄接口調用的次數,並保存。這時候定時任務就派上用場了。
定時任務的實現有很多,像利用線程池的 ScheduledExecutorService,當然 Spring 的 Scheduled 也莫得問題。
其次,用什麼數據結構保存調用次數 --> LinkedList。
另外,我們需要對多個方法限流,該如何解決呢?--> 每個方法都有唯一對應的值: package + class + methodName,於是我們將這個唯一值作為key,linkedList 作為 map,下方代碼:
1 /** 每個key 對應的調用次數**/
2 private Map<string> countMap = new ConcurrentHashMap<>();
3
4 /** 每個key 對應的linkedlist**/
5 private static Map<string>> calListMap = new ConcurrentHashMap<>();
6
7 ## 每s一次查詢
8 @Scheduled(cron = "*/1 * * * * ?")
9 private void timeGet(){
10 countMap.forEach((k,v)->{
11 LinkedList<long> calList = calListMap.get(k);
12 if(calList == null){
13 calList = new LinkedList<>();
14 }
15 # 每個方法的調用次數放入linkedList中
16 calList.addLast(v);
17 calListMap.put(k, calList);
18
19 if (calList.size() > 10) {
20 calList.removeFirst();
21 }
22 });
23 }
/<long>/<string>/<string>
AOP 檢查
定義註解:
1import java.lang.annotation.*;
2
3
4@Target(ElementType.METHOD)
5@Retention(RetentionPolicy.RUNTIME)
6@Documented
7public @interface CalLimitAnno {
8
9 String value() default "" ;
10
11 String methodName() default "" ;
12
13 long count() default 100;
14}
調用接口前檢查:
1@Around(value = "@annotation(around)")
2 public Object initBean(ProceedingJoinPoint point, CalLimitAnno around) throws Throwable {
3 /** 獲取類名和方法名 **/
4 MethodSignature signature = (MethodSignature) point.getSignature();
5 Method method = signature.getMethod();
6 String[] classNameArray = method.getDeclaringClass().getName().split("\\\\.");
7 String methodName = classNameArray[classNameArray.length - 1] + "." + method.getName();
8 String classZ = signature.getDeclaringTypeName();
9 String countMapKey = classZ + "|" + methodName;
10
11
12 LinkedList<long> calList = calListMap.get(countMapKey);
13 if(calList != null){
14 /** 調用次數判斷是否已經超過註解設置的值 **/
15 if ((calList.peekLast() - calList.peekFirst()) > Long.valueOf(around.count())) {
16 throw new RuntimeException("被限流了");
17 }
18 /** 存放**/
19 countMap.putIfAbsent(countMapKey,0L);
20 countMap.put(countMapKey,countMap.get(countMapKey) + 1);
21 }
22 Object object = point.proceed();
23 return object;
24 }
/<long>
方法 考慮到定時任務的頻率不能太小,因此我們的定時任務是每秒鐘執行一次,這裡我們需要設置 10s 鐘的限流值,導致粒度變大了。
1@CalLimitAnno(count = 1000)
2 public void testPageAnno(){
3 System.out.println("成功執行");
4 }
Map 優化
上述我們將 package + className + methodName 作為唯一 key,導致 key 的長度變得特別長,我們是不是該想個辦法降低 key 的長度。
大家有沒有想到平時收到的短信,有時候會存在一個短鏈接,這些短連接其實就是用的發號器 --> 從某個服務中獲取唯一的自增id,然後將這個 id 進行轉化。比如這時候自增到 100000 了,那麼將 100000 從十進制轉化為 62 進制 q0U。這個和短信上的鏈接很相似不是嗎?
Map 持久化
既然是自增的,那麼相同的長字符通過調用服務轉化成的短字符串都是不同的。在某些業務場景,可能調用比較頻繁,就需要做kv存儲。不然也沒有必要做存儲了,多做多錯嘛~
kv 存儲優化
假設我們需要做 kv 存儲,童鞋們能想到的大概也就是 jvm 內存或者 redis 了。因為這個對應關係一般是不會長久存儲的,通常在某個熱點事件中作為查詢。如果是 redis,可以設置過期時間作為驅逐。那麼在 jvm 內存中,我們需要考慮到的是 LRU。即最近最常使用:
- 使用過的 key 需要放到隊列的隊首。
- 最不經常使用的一旦超過隊列限制的長度,需要將其刪除。
那麼我們需要用哪種數據結構實現這中條件的隊列呢?
GET
- 假設這個 key 不存在,那麼返回 null。
- 假設 key 存在,需要返回值的同時,需要將對應的 key 刪除,並且將 key 放到隊首。
在上述的這種場景下,明顯底層是數組的集合如 ArrayList 是不適用的。別說你這想不通哈。。
那就只剩下鏈表瞭如 LinkedList,但是 LinedList 查詢時需要遍歷鏈表。如果我們在存入 LinkedList 的同時,同樣存入 map,那是不是就行了。當然。。。。不是啦,這個 map 有個要求,node 需要保存上一個節點,這樣在查到值的同時,獲取前一個節點,就可以在鏈表中刪除對應的節點了。
PUT
- 假設 key 不存在,放入隊首。
- 假設 key 存在,刪除這個 key,同時放到隊首。
經過 Get 的鋪墊,這個不用說了吧!最終結果是 LinedHashMap。LinkedHashMap 的具體車轍這邊就不逼逼了,還是自己看歷史文章吧!
結尾
這邊不考慮併發導致的線程不安全哈,只是一個參考~~ 講了大半天,大家應該還是有些會看不明白的,請下方留言。沒辦法,語文差啊。
閱讀更多 老男孩的成長之路 的文章