如果這是第二次看到我的文章，歡迎掃描文末二維碼訂閱我喲~
本文長度爲2869字，建議閱讀8分鐘。
可能你在網上看過不少「限流」相關的文章，但是z哥的這篇可能是最全面，最深入淺出的一篇了（容我飄幾秒～）。
開個玩笑，希望你能收穫一些增量價值就好～。
之前有瞭解到z哥的一部分讀者們沒有充分搞清楚「限流」和「熔斷」的關係。我們先來思考一個問題，生活中也有限流，爲什麼國慶春節長假熱門景點要限流？而不是一早先開幾小時，如果人多了就關幾小時，人少了就再開呢？其實這就是限流和熔斷表象上的一個區別。
在上一篇中我們聊到了「熔斷」（分佈式系統關注點——99%的人都能看懂的「熔斷」以及最佳實踐），有熔斷機制的系統，它對可用性的作用至少保證了不會全盤崩潰。
但是你可以想象一個稍微極端一點的場景，如果系統流量不是很穩定，導致頻繁觸發熔斷的話，是不是意味着系統一直熔斷的三種狀態中不斷切換。
導致的結果是每次從開啓熔斷到關閉熔斷的期間，必然會導致大量的用戶無法正常使用。系統層面的可用性大致是這樣的。
另外，從資源利用率上也會很容易發現，波谷的這段時期資源是未充分利用的。
由此可見，光有熔斷是遠遠不夠的。
在高壓下，只要系統沒宕機，如果能將接收的流量持續保持在高位，但又不超過系統所能承載的上限，會是更有效率的運作模式，因爲會將這裏的波谷填滿。
在如今的互聯網已經作爲社會基礎設施的大環境下，上面的這個場景其實離我們並不是那麼遠，同時也會顯得沒那麼極端。例如，層出不窮的營銷玩法，一個接着一個的社會熱點，以及互聯網冰山之下的黑產、刷子的蓬勃發展，更加使得這個場景變的那麼的需要去考慮、去顧忌。因爲隨時都有可能會涌入超出你預期的流量，然後壓垮你的系統。
那麼限流的作用就很顯而易見了：只要系統沒宕機，系統只是因爲資源不夠，而無法應對大量的請求，爲了保證有限的系統資源能夠提供最大化的服務能力，因而對系統按照預設的規則進行流量（輸出或輸入）限制的一種方法，確保被接收的流量不會超過系統所能承載的上限。
一、怎麼做「限流」
從前面聊到的內容中我們也知道，限流最好能“限”在一個系統處理能力的上限附近，所以：
- 通過「壓力測試」等方式獲得系統的能力上限在哪個水平是第一步。
- 其次，就是制定干預流量的策略。比如標準該怎麼定、是否只注重結果還是也要注重過程的平滑性等。
- 最後，就是處理“被幹預掉”的流量。能不能直接丟棄？不能的話該如何處理？
獲得系統能力的上限
第一步不是我們這次內容的重點，說起來就是對系統做一輪壓測。可以在一個獨立的環境進行，也可以直接在生產環境的多個節點中選擇一個節點作爲樣本來壓測，當然需要做好與其他節點的隔離。
一般我們做壓測爲了獲得2個結果，「速率」和「併發數」。前者表示在一個時間單位內能夠處理的請求數量，比如xxx次請求/秒。後者表示系統在同一時刻能處理的最大請求數量，比如xxx次的併發。從指標上需要獲得「最大值」、「平均值」或者「中位數」。後續限流策略需要設定的具體標準數值就是從這些指標中來的。
題外話：從精益求精的角度來說，其他的諸如cpu、網絡帶寬以及內存的耗用也可以作爲參照因素。
制定干預流量的策略
常用的策略就4種，我給它起了一個簡單的定義——「兩窗兩桶」。兩窗就是：固定窗口、滑動窗口，兩桶就是：漏桶、令牌桶。
固定窗口
固定窗口就是定義一個“固定”的統計週期，比如1分鐘或者30秒、10秒這樣。然後在每個週期統計當前週期中被接收到的請求數量，經過計數器累加後如果達到設定的閾值就觸發「流量干預」。直到進入下一個週期後，計數器清零，流量接收恢復正常狀態。
這個策略最簡單，寫起代碼來也沒幾行。
全局變量 int totalCount = 0; //有一個「固定週期」會觸發的定時器將數值清零。if(totalCount > 限流閾值) {
return; //不繼續處理請求。
}
totalCount++;// do something...
固定窗口有一點需要注意的是，假如請求的進入非常集中，那麼所設定的「限流閾值」等同於你需要承受的最大併發數。所以，如果需要顧忌到併發問題，那麼這裏的「固定週期」設定的要儘可能的短。因爲，這樣的話「限流閾值」的數值就可以相應的減小。甚至，限流閾值就可以直接用併發數來指定。比如，假設固定週期是3秒，那麼這裏的閾值就可以設定爲「平均併發數*3」。
不過不管怎麼設定，固定窗口永遠存在的缺點是：由於流量的進入往往都不是一個恆定的值，所以一旦流量進入速度有所波動，要麼計數器會被提前計滿，導致這個週期內剩下時間段的請求被“限制”。要麼就是計數器計不滿，也就是「限流閾值」設定的過大，導致資源無法充分利用。
「滑動窗口」可以改善這個問題。
滑動窗口
滑動窗口其實就是對固定窗口做了進一步的細分，將原先的粒度切的更細，比如1分鐘的固定窗口切分爲60個1秒的滑動窗口。然後統計的時間範圍隨着時間的推移同步後移。
同時，我們還可以得出一個結論是：如果固定窗口的「固定週期」已經很小了，那麼使用滑動窗口的意義也就沒有了。舉個例子，現在的固定窗口週期已經是1秒了，再切分到毫秒級別能反而得不償失，會帶來巨大的性能和資源損耗。
滑動窗口大致的代碼邏輯是這樣：
全局數組 鏈表[] counterList = new 鏈表[切分的滑動窗口數量];
//有一個定時器，在每一次統計時間段起點需要變化的時候就將索引0位置的元素移除，並在末端追加一個新元素。int sum = counterList.Sum();
if(sum > 限流閾值) {
return; //不繼續處理請求。
}
int 當前索引 = 當前時間的秒數 % 切分的滑動窗口數量;
counterList[當前索引]++;// do something...
雖然說滑動窗口可以改善這個問題，但是本質上還是預先劃定時間片的方式，屬於一種“預測”，意味着幾乎肯定無法做到100%的物盡其用。
但是，「桶」模式可以做的更好，因爲「桶」模式中多了一個緩衝區（桶本身）。
漏桶
首先聊聊「漏桶」吧。漏桶模式的核心是固定“出口”的速率，不管進來多少量，出去的速率一直是這麼多。如果涌入的量多到桶都裝不下了，那麼就進行「流量干預」。
整個實現過程我們來分解一下。
- 控制流出的速率。這個其實可以使用前面提到的兩個“窗口”的思路來實現。如果當前速率小於閾值則直接處理請求，否則不直接處理請求，進入緩衝區，並增加當前水位。
- 緩衝的實現可以做一個短暫的休眠或者記錄到一個容器中再做異步的重試。
- 最後控制桶中的水位不超過最大水位。這個很簡單，就是一個全局計數器，進行加加減減。
這樣一來，你會發現本質就是：通過一個緩衝區將不平滑的流量“整形”成平滑的（高於均值的流量暫存下來補足到低於均值的時期），以此最大化計算處理資源的利用率。
實現代碼的簡化表示如下：
全局變量 int unitSpeed; //出口當前的流出速率。每隔一個速率計算週期（比如1秒）會觸發定時器將數值清零。
全局變量 int waterLevel; //當前緩衝區的水位線。if(unitSpeed < 速率閾值) {
unitSpeed++;//do something...
}
else{
if(waterLevel > 水位閾值){
return; //不繼續處理請求。
}
waterLevel++;
while(unitSpeed >= 速率閾值){
sleep(一小段時間)。
}
unitSpeed++;
waterLevel--;//do something...
}
更優秀的「漏桶」策略已經可以在流量的總量充足的情況下發揮你所預期的100%處理能力，但這還不是極致。
你應該知道，一個程序所在的運行環境中，往往不單單隻有這個程序本身，會存在一些系統進程甚至是其它的用戶進程。也就是說，程序本身的處理能力是會被幹擾的，是會變化的。所以，你可以預估某一個階段內的平均值、中位數，但無法預估具體某一個時刻的程序處理能力。又因此，你必然會使用相對悲觀的標準去作爲閾值，防止程序超負荷。
那麼從資源利用率來說，有沒有更優秀的方案呢？有，這就是「令牌桶」。
令牌桶
令牌桶模式的核心是固定“進口”速率。先拿到令牌，再處理請求，拿不到令牌就被「流量干預」。因此，當大量的流量進入時，只要令牌的生成速度大於等於請求被處理的速度，那麼此刻的程序處理能力就是極限。
也來分解一下它的實現過程。
- 控制令牌生成的速率，並放入桶中。這個其實就是單獨一個線程在不斷的生成令牌。
- 控制桶中待領取的令牌水位不超過最大水位。這個和「漏桶」一樣，就是一個全局計數器，進行加加減減。
大致的代碼簡化表示如下（看上去像「固定窗口」的反向邏輯）：
全局變量 int tokenCount = 令牌數閾值; //可用令牌數。有一個獨立的線程用固定的頻率增加這個數值，但不大於「令牌數閾值」。if(tokenCount == 0){
return; //不繼續處理請求。
}tokenCount--;
//do something...
聰明的你可能也會想到，這樣一來令牌桶的容量大小理論上就是程序需要支撐的最大併發數。的確如此，假設同一時刻進入的流量將令牌取完，但是程序來不及處理，將會導致事故發生。
所以，沒有真正完美的策略，只有合適的策略。因此，根據不同的場景能夠識別什麼是最合適的策略是更需要鍛鍊的能力。下面z哥分享一些我個人的經驗。
二、做「限流」的最佳實踐
四種策略該如何選擇？
首先，固定窗口。一般來說，如非時間緊迫，不建議選擇這個方案，太過生硬。但是，爲了能快速止損眼前的問題可以作爲臨時應急的方案。
其次，滑動窗口。這個方案適用於對異常結果「高容忍」的場景，畢竟相比“兩窗”少了一個緩衝區。但是，勝在實現簡單。
然後，漏桶。z哥覺得這個方案最適合作爲一個通用方案。雖說資源的利用率上不是極致，但是「寬進嚴出」的思路在保護系統的同時還留有一些餘地，使得它的適用場景更廣。
最後，令牌桶。當你需要儘可能的壓榨程序的性能（此時桶的最大容量必然會大於等於程序的最大併發能力），並且所處的場景流量進入波動不是很大（不至於一瞬間取完令牌，壓垮後端系統）。
分佈式系統中帶來的新挑戰
一個成熟的分佈式系統大致是這樣的。
每一個上游系統都可以理解爲是其下游系統的客戶端。然後我們回想一下前面的內容，可能你發現了，前面聊的「限流」都沒有提到到底是在客戶端做限流還是服務端做，甚至看起來更傾向是建立在服務端的基礎上做。但是你知道，在一個分佈式系統中，一個服務端本身就可能存在多個副本，並且還會提供給多個客戶端調用，甚至其自身也會作爲客戶端角色。那麼，在如此交錯複雜的一個環境中，該如何下手做限流呢？我的思路是通過「一縱一橫」來考量。
縱
都知道「限流」是一個保護措施，那麼可以將它想象成一個盾牌。另外，一個請求在系統中的處理過程是鏈式的。那麼，正如古時候軍隊打仗一樣，盾牌兵除了有小部分在老大周圍保護，剩下的全在最前線。因爲盾的位置越前，能受益的範圍越大。
分佈式系統中最前面的是什麼？接入層。如果你的系統有接入層，比如用nginx做的反向代理。那麼可以通過它的ngx_http_limit_conn_module以及ngx_http_limit_req_module來做限流，是很成熟的一個解決方案。
如果沒有接入層，那麼只能在應用層以AOP的思路去做了。但是，由於應用是分散的，出於成本考慮你需要針對性的去做限流。比如ToC的應用必然比ToB的應用更需要做，高頻的緩存系統必然比低頻的報表系統更需要做，Web應用由於存在Filter的機制做起來必然比Service應用更方便。
那麼應用間的限流到底是做到客戶端還是服務端呢？
z哥的觀點是，從效果上客戶端模式肯定是優於服務端模式的，因爲當處於被限流狀態的時候，客戶端模式連建立連接的動作都省了。另一個潛在的好處是，與集中式的服務端模式相比，可以把少數的服務端程序的壓力分散掉。但是在客戶端做成本也更高，因爲它是去中心化的，假如需要多個節點之間的數據共通的話，是一個很麻煩的事情。
所以，最終z哥建議你：如果考慮成本就服務端模式，考慮效果就客戶端模式。當然也不是絕對，比如一個服務端的流量大部分都來源於某一個客戶端，那麼就可以直接在這個客戶端做限流，這也不失爲一個好方案。
數據庫層面的話，一般連接字符串中本身就會包含「最大連接數」的概念，就可以起到限流的作用。如果想做更精細的控制就只能做到統一封裝的數據庫訪問層框架中了。
聊完了「縱」，那麼「橫」是什麼呢？
橫
不管是多個客戶端，還是同一個服務端的多個副本。每個節點的性能必然會存在差異，如何設立合適的閾值？以及如何讓策略的變更儘可能快的在集羣中的多個節點生效？說起來很簡單，引入一個性能監控平臺和配置中心。但這些真真要做好不容易，後續我們再展開這塊內容。
三、總結
限流就好比保險絲，根據你制定的標準，達到了就拉閘。
不過，觸發限流後的措施除了直接丟棄請求之外，還有一個方式是「降級」，那麼降級有哪些方式呢？我們下一篇再聊吧。
Question：
你在工作中有遇到過什麼場景需要做「限流」嗎？歡迎分享交流一下。
相關文章：
▶ 關於作者：張帆（Zachary，個人微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。本文首發於公衆號：「跨界架構師」（ID：Zachary_ZF）。如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公衆號「跨界架構師」，回覆「技術」，送你一份我長期收集和整理的思維導圖。
如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關注我的公衆號「跨界架構師」，回覆「運營」，送你一份我長期收集和整理的思維導圖。
定期發表原創內容：架構設計丨分佈式系統丨產品丨運營丨一些深度思考。
掃碼加入小圈子 ↓
