限流是對稀缺資源訪問時，比如秒殺，搶購的商品時，來限制併發和請求的數量，從而有效的進行削峰並使得流量曲線平滑。限流的目的是對併發訪問和併發請求進行限速，或者一個時間視窗內請求進行限速從而來保護系統，一旦達到或超過限制速率就可以拒絕服務，或者進行排隊等待等。
計數器
採用計數器實現限流有點簡單粗暴，一般我們會限制一秒鐘的能夠通過的請求數，比如限流 qps 為100，演算法的實現思路就是從第一個請求進來開始計時，在接下去的1s內，每來一個請求，就把計數加1，如果累加的數字達到了100，那麼後續的請求就會被全部拒絕。等到1s結束後，把計數恢復成0，重新開始計數。
這種實現方式，相信大家都知道有一個弊端：如果我在單位時間1s內的前10ms，已經通過了100個請求，那後面的990ms，只能眼巴巴的把請求拒絕，我們把這種現象稱為“突刺現象”
漏桶
為了消除”突刺現象”，可以採用漏桶演算法實現限流，漏桶演算法這個名字就很形象，演算法內部有一個容器，類似生活用到的漏斗，當請求進來時，相當於水倒入漏斗，然後從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。
不管服務呼叫方多麼不穩定，通過漏桶演算法進行限流，每10毫秒處理一次請求。因為處理的速度是固定的，請求進來的速度是未知的，可能突然進來很多請求，沒來得及處理的請求就先放在桶裡，既然是個桶，肯定是有容量上限，如果桶滿了，那麼新進來的請求就丟棄。
這種演算法，在使用過後也存在弊端：無法應對短時間的突發流量。
令牌桶
某種意義上講，令牌桶演算法是對漏桶演算法的一種改進，桶演算法能夠限制請求呼叫的速率，而令牌桶演算法能夠在限制呼叫的平均速率的同時還允許一定程度的突發呼叫。
在令牌桶演算法中，存在一個桶，用來存放固定數量的令牌。演算法中存在一種機制，以一定的速率往桶中放令牌。每次請求呼叫需要先獲取令牌，只有拿到令牌，才有機會繼續執行，否則選擇選擇等待可用的令牌、或者直接拒絕。
放令牌這個動作是持續不斷的進行，如果桶中令牌數達到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時進來的請求就可以直接拿到令牌執行，比如設定 qps 為100，那麼限流器初始化完成一秒後，桶中就已經有100個令牌了，這時服務還沒完全啟動好，等啟動完成對外提供服務時，該限流器可以抵擋瞬時的100個請求。所以，只有桶中沒有令牌時，請求才會進行等待，最後相當於以一定的速率執行。
令牌桶實現原理
對於令牌桶中令牌的產生一般有兩種做法：
- 一種解法是，開啟一個定時任務，由定時任務持續生成令牌。這樣的問題在於會極大的消耗系統資源，如，某介面需要分別對每個使用者做訪問頻率限制，假設系統中存在6W使用者，則至多需要開啟6W個定時任務來維持每個桶中的令牌數，這樣的開銷是巨大的。
- 第二種解法是延遲計算，定義一個 resync 函式。該函式會在每次獲取令牌之前呼叫，其實現思路為，若當前時間晚於 nextFreeTicketMicros，則計算該段時間內可以生成多少令牌，將生成的令牌加入令牌桶中並更新資料。這樣一來，只需要在獲取令牌時計算一次即可。
原文連結：www.swoft.org/documents/v2/microse...
本作品採用《CC 協議》，轉載必須註明作者和本文連結