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

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

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

從系統(tǒng)架構來看，我們的統(tǒng)一處理入口在austin-api接入層上，austin-api接入層做完簡單的參數(shù)校驗以及參數(shù)拼接后，就將請求轉發(fā)到消息隊列上了

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

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

在系統(tǒng)本身上其實沒有性能相關的問題，但我們下發(fā)的渠道可能就需要我們?nèi)タ刂普{(diào)用的速率。

騰訊云短信默認限制3000次/秒調(diào)用下發(fā)接口

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

....

在保證下發(fā)速度的前提下，為了讓業(yè)務方所下發(fā)的消息其用戶能正常接收到和下游渠道的穩(wěn)定性，我們需要給某些渠道進行限流

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

1、按照請求數(shù)限流

2、按照下發(fā)用戶數(shù)限流

02、如何實現(xiàn)限流？

想要實現(xiàn)限流，擺在我們面前有兩個選擇：

1、單機限流

2、分布式限流

咋一看，線上不可能只部署一臺機器去發(fā)送整個公司的消息推送的，我們的系統(tǒng)應用在線上環(huán)境絕對是集群部署的，那肯定就需要上分布式限流了，對吧？

但實際上分布式限流實現(xiàn)并不簡單，目前分布式限流的方案一般借助兩個中間件

1、Redis

2、Sentinel

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

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

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

對于分布式限流而言，不管用哪一種方案，使用的成本和技術挑戰(zhàn)都是比較大的。

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

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

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

我是怎么實現(xiàn)的？單機限流一把梭

03、代碼設計

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

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

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

2、子類在初始化的時候定義限流參數(shù)，BaseHandler父類根據(jù)限流參數(shù)統(tǒng)一實現(xiàn)限流的邏輯

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

而限流的邏輯就比較簡單了，主要就使用RateLimit提供的易用API實現(xiàn)

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

04、總結

扯了半天，原來就用了Guava包的RateLimit實現(xiàn)了單機限流，就這么簡單，只是把限流值配置在分布式配置中心上而已。

很多時候，設計簡單的代碼可能實現(xiàn)并不完美，并不智能，并不優(yōu)雅，但它付出的代價往往是最小的。

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

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

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

以上就是spring 項目實現(xiàn)限流方法示例的詳細內(nèi)容，更多關于spring 項目限流的資料請關注腳本之家其它相關文章！

最新評論