1.1 限流算法----漏桶算法
漏桶(Leaky Bucket)算法思路很簡單，水(請求)先進入到漏桶裏，漏桶以一定的速度出水(接口有響應速率)，當水流入速度過大會直接溢出(訪問頻率超過接口響應速率)，然後就拒絕請求，可以看出漏桶算法能強行限制數據的傳輸速率，示意圖如下(因爲漏桶的漏出速率是固定的參數,所以,即使網絡中不存在資源衝突(沒有發生擁塞),漏桶算法也不能使流突發(burst)到端口速率.因此,漏桶算法對於存在突發特性的流量來說缺乏效率):
1.2 限流算法----令牌桶算法
令牌桶算法(Token Bucket)和 Leaky Bucket 效果一樣但方向相反的算法，更加容易理解。隨着時間流逝，系統會按恆定1/QPS時間間隔(如果QPS=100，則間隔是10ms)往桶裏加入Token(想象和漏洞漏水相反，有個水龍頭在不斷的加水)，如果桶已經滿了就不再加了，新請求來臨時，會各自拿走一個Token，如果沒有Token可拿了就阻塞或者拒絕服務。
令牌桶的另外一個好處是可以方便的改變速度. 一旦需要提高速率,則按需提高放入桶中的令牌的速率. 一般會定時(比如100毫秒)往桶中增加一定數量的令牌, 有些變種算法則實時的計算應該增加的令牌的數量。
3.3 基於RateLimiter的流速控制
ateLimiter使用的是令牌桶的流控算法，RateLimiter會按照一定的頻率往桶裏扔令牌，線程拿到令牌才能執行，比如你希望自己的應用程序QPS不要超過1000，那麼RateLimiter設置1000的速率後，就會每秒往桶裏扔1000個令牌。
RateLimiter經常用於限制對一些物理資源或者邏輯資源的訪問速率。
通過設置許可證的速率來定義RateLimiter。在默認配置下，許可證會在固定的速率下被分配，速率單位是每秒多少個許可證。爲了確保維護配置的速率，許可會被平穩地分配，許可之間的延遲會做調整。
可能存在配置一個擁有預熱期的RateLimiter 的情況，在這段時間內，每秒分配的許可數會穩定地增長直到達到穩定的速率。
有一點很重要，那就是請求的許可數從來不會影響到請求本身的限制（調用acquire(1) 和調用acquire(1000) 將得到相同的限制效果，如果存在這樣的調用的話），但會影響下一次請求的限制，也就是說，如果一個高開銷的任務抵達一個空閒的RateLimiter，它會被馬上許可，但是下一個請求會經歷額外的限制，從而來償付高開銷任務。注意：RateLimiter 並不提供公平性的保證。