我是3y，一年CRUD經驗用十年的markdown程式設計師???常年被譽為職業八股文選手
今天繼續來更新austin專案的內容，主要講講限流這塊
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