限流器相關算法
一般限流器有五種算法，分別是：令牌桶，漏斗桶，固定窗口，滑動日志（指的其實是廣義上的滑動窗口），滑動窗口（這里指的是滑動日志+固定窗口結合的一種算法）。
1. 令牌桶（Token bucket）
令牌桶算法用來控制一段時間內發送到網絡上的數據的數目，並允許突發數據的發送。
算法大概是： 假設允許的請求速率為r次每秒，那么每過1/r秒就會向桶里面添加一個令牌。桶的最大大小是b。當一個大小為n的請求到來時，檢查桶內令牌數是否足夠，如果足夠，令牌數減少n，請求通過。不夠的話就會觸發拒絕策略。
令牌桶有一個固定大小，假設每一個請求也有一個大小，當要檢查請求是否符合定義的限制時，會檢查桶，以確定它當時是否包含足夠的令牌。如果有，那么會移除掉這些令牌，請求通過。否則，會采取其他操作，一般是拒絕。令牌桶中的令牌會以一定速率恢復，這個速率就是允許請求的速率（當然，根據大小的配置，可能實際會超過這個速率，但是隨着令牌桶的消耗會被調整回這個恢復速率）。
如果令牌不被消耗，或者被消耗的速度小於產生的速度，令牌就會不斷地增多，直到把桶填滿。可以看出，令牌桶在保持整體上的請求速率的同時，允許某種程度的突發傳輸。
分布式環境下的令牌桶的實現需要考慮如下幾個問題：
- 令牌桶當前大小究竟如何存儲？是只存儲一個當前令牌桶的大小（例如通過 redis 的一個鍵值對存儲），還是存放每個通過的請求到來的時間戳（例如通過 redis 的 zset 實現，zset 的大小就是桶的最大大小）？
- 令牌桶的令牌補充是由誰補充？對於存儲一個當前令牌桶的大小的實現方式，需要一個進程以速率
r不斷地往里面添加令牌，那么如何在分布式的環境下保證有且只有一個這樣的進程，這個進程掛了怎么辦？對於存放每個通過的請求到來的時間戳的這種實現方式實現，那么怎么控制記錄請求的個數，肯定不能每個都記錄，並且每次怎么通過目前的請求以及時間戳來判斷剩余令牌數量
2. 漏斗桶（Leaky bucket）
漏斗桶控制請求必須在最大某個速率被消費，就像一個漏斗一樣，入水量可大可小，但是最大速率只能到某一量值，不會像令牌桶一樣，會有小的尖峰。
算法大概是： 主要實現方式是通過一個 FIFO （First in first out）的隊列實現，這個隊列是一個有界隊列，大小為b，如果請求堆積滿了隊列，就會觸發丟棄策略。假設允許的請求速率為r次每秒，那么這個隊列中的請求，就會以這個速率進行消費。
分布式環境下的漏桶的實現需要考慮如下幾個問題：
1. 漏桶的隊列，怎么存放？這個隊列需要存放每個通過的請求以及對應的消費的時間戳，保證消費的平穩。同時，這個隊列最好是無鎖隊列，因為會有分布式鎖征用。並且，這個隊列大小應該設置為b，並每次有請求到來時，放入隊列的同時清理隊列。
2. 消費如何實現？也就是存入隊列的請求，如何消費呢？可以請求到來時，通過隊列中的請求來判斷當前這個請求的執行時間應該是多久以后，之后入隊列，延遲這么久再執行這個請求。也可以利用本身帶延遲時間實現的隊列來實現。
3. 固定時間窗口（Fixed window）
固定時間窗口比較簡單，就是將時間切分成若干個時間片，每個時間片內固定處理若干個請求。這種實現不是非常嚴謹，但是由於實現簡單，適用於一些要求不嚴格的場景。
算法大概是： 假設n秒內最多處理b個請求，那么每隔n秒將計數器重置為b。請求到來時，如果計數器值足夠，則扣除並請求通過，不夠則觸發拒絕策略。
固定時間窗口是最容易實現的算法，但是也是有明顯的缺陷：那就是在很多情況下，尤其是請求限流后拒絕策略為排隊的情況下，請求都在時間窗口的開頭被迅速消耗，剩下的時間不處理任何請求，這是不太可取的。並且，在一些極限情況下，實際上的流量速度可能達到限流的 2 倍。例如限制 1 秒內最多 100 個請求。假設 0.99 秒的時候 100 個請求到了，之后 1.01 秒的時候又有 100 個請求到了，這樣的話其實在 0.99 秒 ~ 1.01 秒這一段時間內有 200 個請求，並不是嚴格意義上的每一秒都只處理 100 個請求。為了能實現嚴格意義上的請求限流，則有了后面兩種算法。
4. 滑動日志（Sliding Log）
滑動日志根據緩存之前接受請求對應的時間戳，與當前請求的時間戳進行計算，控制速率。這樣可以嚴格限制請求速率。一般的網上提到的滑動窗口算法也指的是這里的滑動日志（Sliding Log）算法，但是我們這里的滑動窗口是另一種優化的算法，待會會提到。
算法大概是： 假設n秒內最多處理b個請求。那么會最多緩存 b 個通過的請求與對應的時間戳，假設這個緩存集合為B。每當有請求到來時，從B中刪除掉n秒前的所有請求，查看集合是否滿了，如果沒滿，則通過請求，並放入集合，如果滿了就觸發拒絕策略。
分布式環境下的滑動日志的實現需要考慮如下幾個問題：
- 我們的算法其實已經簡化了存儲，但是對於高並發的場景，要緩存的請求可能會很多（例如限制每秒十萬的請求，那么這個緩存的大小是否就應該能存儲十萬個請求？），這個緩存應該如何實現？
- 高並發場景下，對於這個集合的刪除掉
n秒前的所有請求的這個操作，需要速度非常快。如果你的緩存集合實現對於按照時間戳刪除這個操作比較慢，可以緩存多一點請求，定時清理刪除n秒前的所有請求而不是每次請求到來都刪除。請求到來的時候，查看b個之前的請求是否存在並且時間差小於n秒，存在並且小於代表應該觸發限流策略。
5. 滑動窗口（滑動日志 + 固定窗口）
前面的滑動日志，我們提到了一個問題 - 要緩存的請求可能會很多。也許在我們的架構內不能使用一個恰當的緩存來實現，我們可以通過滑動窗口這個方法來減少要存儲的請求數量，並減少集合大小減少同一個集合上面的並發。
算法大概是： 假設n秒內最多處理b個請求。我們可以將n秒切分成每個大小為m毫秒得時間片，只有最新的時間片內緩存請求和時間戳，之前的時間片內只保留一個請求量的數字。這樣可以大大優化存儲，小幅度增加計算量。對於臨界條件，就是之前已經有了n/m個時間片，計算n秒內請求量時可以計算當前時間片內經過時間的百分比，假設是 25%，那么就取開頭的第一個時間片的請求量的 75% 進行計算。
每日一刷，輕松提升技術，斬獲各種offer：
