spring 項目實現限流方法示例

Posted on by

01、為什麼AUSTIN項目需要限流

眾所周知，服務器能處理的請求數是有限的，如果請求量特別大，我們就可能需要做限流。

限流處理的姿勢：要麼就讓請求等待，要麼就把請求給扔瞭

從系統架構來看，我們的統一處理入口在austin-api接入層上，austin-api接入層做完簡單的參數校驗以及參數拼接後，就將請求轉發到消息隊列上瞭

按正常來說，因為接瞭消息隊列且接入層沒有什麼耗時的操作，那對外的接口壓力不大的。

沒錯的，austin要接入限流也並不是在austin-api接入層上做，是在austin-handler消息處理下發層。austin-handler消息處理下發層我們是用線程池去隔離不同的消息渠道不同的消息類型。

在系統本身上其實沒有性能相關的問題，但我們下發的渠道可能就需要我們去控制調用的速率。

騰訊雲短信默認限制3000次/秒調用下發接口

釘釘渠道對應用消息和群機器人消息都有接口調用的限制

….

在保證下發速度的前提下，為瞭讓業務方所下發的消息其用戶能正常接收到和下遊渠道的穩定性，我們需要給某些渠道進行限流

於是在這個背景下，我目前定義瞭兩種限流策略：

1、按照請求數限流

2、按照下發用戶數限流

02、如何實現限流？

想要實現限流，擺在我們面前有兩個選擇：

1、單機限流

2、分佈式限流

咋一看，線上不可能隻部署一臺機器去發送整個公司的消息推送的，我們的系統應用在線上環境絕對是集群部署的，那肯定就需要上分佈式限流瞭，對吧？

但實際上分佈式限流實現並不簡單，目前分佈式限流的方案一般借助兩個中間件

1、Redis

2、Sentinel

我們可能會用Redis的setnx/incrby+expire命令(從而實現計數器、令牌桶限流)/zset數據結構(從而實現滑動窗口限流)

Redis實現的限流想要比較準確，無論是哪種方式，都要依靠lua腳本

而Sentinel支持單機限流和分佈式限流，Sentinel分佈式限流需要部署Token服務器

對於分佈式限流而言，不管用哪一種方案，使用的成本和技術挑戰都是比較大的。

如果用單機限流的話，那就簡單得多瞭，省事直接用Guava包下的RateLimiter就完瞭。缺點就在於：它隻能控制單機的限流，如果發生瞭服務器擴容和縮容，它是感知不到的。

有的人就給出瞭方案：那我用Zookeeper監聽服務器的數量不就好瞭嗎。理論上確實是這樣的：每臺機器限流值=限流總值/服務器數量

不過這又要去依賴Zookeeper，Zookeeper集群本身也有一堆狀態相關的問題。

我是怎麼實現的？單機限流一把梭

03、代碼設計

從上面的描述可以看到，austin的限流我是要做在具體渠道上的，根據現有的代碼設計我要的就是在各個的Handler上寫上限流的代碼。

我本身就設計瞭BaseHandler抽象類作為模板方法設計模式，此次限流的設計我的是：

1、將flowControl定義為abstract抽象方法，子類渠道去實現限流的代碼

2、子類在初始化的時候定義限流參數，BaseHandler父類根據限流參數統一實現限流的邏輯

我選擇瞭第二種方式，主要是我認為對於各個渠道而言，隻是限流值是不同的，限流的邏輯應該都是一樣的，沒必要在每個子類上實現類似的邏輯。

而限流的邏輯就比較簡單瞭，主要就使用RateLimit提供的易用API實現

沒錯，限流值的大小我是配置在apollo分佈式配置中心的。假設以後真的要擴縮容瞭，那到時候提前把分佈式配置中心的值給改掉，也能解決一部分的問題。

04、總結

扯瞭半天，原來就用瞭Guava包的RateLimit實現瞭單機限流，就這麼簡單，隻是把限流值配置在分佈式配置中心上而已。

很多時候，設計簡單的代碼可能實現並不完美，並不智能，並不優雅，但它付出的代價往往是最小的。

雖說如此，如果大傢想要瞭解Redis+lua實現的同學可以fetch下austin最新的代碼，就我寫文章這段時間裡，已經有老哥提瞭pull request用Redis+lua實現瞭滑動窗口去重的功能瞭，本質上是一樣的。我已經merge到master分支瞭。

austin消息推送平臺項目源碼Gitee鏈接：gitee.com/austin

austin消息推送平臺項目源碼GitHub鏈接：github.com/austin

以上就是spring 項目實現限流方法示例的詳細內容，更多關於spring 項目限流的資料請關註WalkonNet其它相關文章！

推薦閱讀：