01、為什么AUSTIN項(xiàng)目需要限流

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

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

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

按正常來說，因?yàn)榻恿讼㈥?duì)列且接入層沒有什么耗時(shí)的操作，那對(duì)外的接口壓力不大的。

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

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

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

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

....

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

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

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

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

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

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

1、單機(jī)限流

2、分布式限流

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

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

1、Redis

2、Sentinel

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

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

而Sentinel支持單機(jī)限流和分布式限流，Sentinel分布式限流需要部署Token服務(wù)器

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

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

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

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

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

03、代碼設(shè)計(jì)

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

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

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

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

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

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

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

04、總結(jié)

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

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

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

austin消息推送平臺(tái)項(xiàng)目源碼Gitee鏈接：gitee.com/austin

austin消息推送平臺(tái)項(xiàng)目源碼GitHub鏈接：github.com/austin

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

最新評(píng)論