一、計數(shù)器（固定窗口）算法

計數(shù)器算法是使用計數(shù)器在周期內(nèi)累加訪問次數(shù)，當(dāng)達(dá)到設(shè)定的限流值時，觸發(fā)限流策略。下一個周期開始時，進(jìn)行清零，重新計數(shù)。

此算法在單機(jī)還是分布式環(huán)境下實現(xiàn)都非常簡單，使用redis的incr原子自增性和線程安全即可輕松實現(xiàn)。

計數(shù)器算法對于秒級以上的時間周期來說，會存在一個非常嚴(yán)重的問題，那就是臨界問題，如下圖：

假設(shè)1min內(nèi)服務(wù)器的負(fù)載能力為100，因此一個周期的訪問量限制在100，然而在第一個周期的最后5秒和下一個周期的開始5秒時間段內(nèi)，分別涌入100的訪問量，雖然沒有超過每個周期的限制量，但是整體上10秒內(nèi)已達(dá)到200的訪問量，已遠(yuǎn)遠(yuǎn)超過服務(wù)器的負(fù)載能力，由此可見，計數(shù)器算法方式限流對于周期比較長的限流，存在很大的弊端。

二、滑動窗口

滑動窗口算法是將時間周期分為N個小周期，每個小周期分別記錄訪問次數(shù)，并且根據(jù)時間滑動刪除過期的小周期，添加新的小周期。小周期的訪問次數(shù)和的最大值等于限流值。

假設(shè)1分鐘允許100個請求，然后我們將時間窗口進(jìn)行劃分，比如圖中，我們就將滑動窗口劃成了6格，所以每格代表的是10秒鐘。每過10秒鐘，我們的時間窗口就會往右滑動一格。每一個格子都有自己獨立的計數(shù)器counter，比如當(dāng)一個請求 在0:35秒的時候到達(dá)，那么0:30~0:39對應(yīng)的counter就會加1。

滑動窗口如何解決臨界問題：
當(dāng)最后0:59和1:01都來了100個請求，在0:59所屬的周期沒有過期前，因為已經(jīng)達(dá)到限流值，因此會出發(fā)限流，直到0:59所屬的周期過期，才能接受新的請求，解決了臨界問題。

回顧一下上面的計數(shù)器算法，我們可以發(fā)現(xiàn)，計數(shù)器算法其實就是滑動窗口算法。只是它沒有對時間窗口做進(jìn)一步地劃分，所以只有1格。
由此可見，當(dāng)滑動窗口的格子劃分的越多，那么滑動窗口的滾動就越平滑，限流的統(tǒng)計就會越精確。

滑動窗口的缺點

滑動窗口的實現(xiàn)：簡單的java實現(xiàn)滑動時間窗口限流算法

單機(jī)下可以通過隊列實現(xiàn)，分布式下可以通過Redis的 zset 實現(xiàn)。滑動窗口需要記錄每個請求的時間戳，因此內(nèi)存消耗比較大，占用存儲空間高，且不能保證請求穩(wěn)定。

三、漏桶算法

漏桶算法思路很簡單，水（請求）先進(jìn)入到漏桶里，漏桶以一定的速度出水，當(dāng)水流入速度過大會直接溢出，可以看出漏桶算法能強(qiáng)行限制數(shù)據(jù)的傳輸速率，不允許突發(fā)流量。

對于很多應(yīng)用場景來說，除了要求能夠限制數(shù)據(jù)的平均傳輸速率外，還要求允許某種程度的突發(fā)流量。這時候漏桶算法可能就不合適了，令牌桶算法更為適合。

四、令牌桶

令牌桶算法的原理是系統(tǒng)會以一個恒定的速度往桶里放入令牌，而如果請求需要被處理，則需要先從桶里獲取一個令牌，當(dāng)桶里沒有令牌可取時，則拒絕服務(wù)。

漏桶法和令牌桶的區(qū)別

兩者主要區(qū)別在

• 漏桶算法能夠強(qiáng)行限制數(shù)據(jù)的傳輸速率
• 令牌桶算法在能夠限制數(shù)據(jù)的平均傳輸速率外，還允許某種程度的突發(fā)傳輸。在“令牌桶算法”中，只要令牌桶中存在令牌，那么就允許突發(fā)地傳輸數(shù)據(jù)直到達(dá)到用戶配置的門限，所以它適合于具有突發(fā)特性的流量。

令牌桶可以用來保護(hù)自己，主要用來對調(diào)用者頻率進(jìn)行限流，為的是讓自己不被打垮。所以如果自己本身有處理能力的時候，如果流量突發(fā)（實際消費能力強(qiáng)于配置的流量限制），那么實際處理速率可以超過配置的限制。

漏桶算法，這是用來保護(hù)他人，也就是保護(hù)他所調(diào)用的系統(tǒng)。主要場景是，當(dāng)調(diào)用的第三方系統(tǒng)本身沒有保護(hù)機(jī)制，或者有流量限制的時候，我們的調(diào)用速度不能超過他的限制，由于我們不能更改第三方系統(tǒng)，所以只有在主調(diào)方控制。這個時候，即使流量突發(fā)，也必須舍棄。因為消費能力是第三方?jīng)Q定的。

總結(jié)：如果要讓自己的系統(tǒng)不被打垮，用令牌桶。如果保證別人的系統(tǒng)不被打垮，用漏桶算法

小結(jié)

從上面看來好像漏桶和令牌桶比時間窗口算法好多了，那時間窗口算法有啥子用，扔了扔了？

并不是的，雖然漏桶和令牌桶對比時間窗口對流量的整形效果更佳，流量更加得平滑，但是也有各自的缺點（上面已經(jīng)提到了一部分）。

拿令牌桶來說，假設(shè)你沒預(yù)熱，那是不是上線時候桶里沒令牌？沒令牌請求過來不就直接拒了么？這就誤殺了，明明系統(tǒng)沒啥負(fù)載現(xiàn)在。

再比如說請求的訪問其實是隨機(jī)的，假設(shè)令牌桶每20ms放入一個令牌，桶內(nèi)初始沒令牌，這請求就剛好在第一個20ms內(nèi)有兩個請求，再過20ms里面沒請求，其實從40ms來看只有2個請求，應(yīng)該都放行的，而有一個請求就直接被拒了。這就有可能造成很多請求的誤殺，但是如果看監(jiān)控曲線的話，好像流量很平滑，峰值也控制的很好。

再拿漏桶來說，漏桶中請求是暫時存在桶內(nèi)的。這其實不符合互聯(lián)網(wǎng)業(yè)務(wù)低延遲的要求。

所以漏桶和令牌桶其實比較適合阻塞式限流場景，即沒令牌我就等著，這就不會誤殺了，而漏桶本就是等著。比較適合后臺任務(wù)類的限流。而基于時間窗口的限流比較適合對時間敏感的場景，請求過不了您就快點兒告訴我，等的花兒都謝了。

單機(jī)限流和分布式限流

本質(zhì)上單機(jī)限流和分布式限流的區(qū)別其實就在于 “閾值” 、窗口、漏斗存放的位置。

單機(jī)限流就上面所說的算法直接在單臺服務(wù)器上實現(xiàn)就好了，而往往我們的服務(wù)是集群部署的。因此需要多臺機(jī)器協(xié)同提供限流功能。

像上述的計數(shù)器或者時間窗口的算法，可以將計數(shù)器存放至 Tair 或 Redis 等分布式 K-V 存儲中。

例如滑動窗口的每個請求的時間記錄可以利用 Redis 的 zset 存儲，利用ZREMRANGEBYSCORE 刪除時間窗口之外的數(shù)據(jù)，再用 ZCARD計數(shù)。

像令牌桶也可以將令牌數(shù)量放到 Redis 中。

不過這樣的方式等于每一個請求我們都需要去Redis判斷一下能不能通過，在性能上有一定的損耗，所以有個優(yōu)化點就是 「批量」。例如每次取令牌不是一個一取，而是取一批，不夠了再去取一批。這樣可以減少對 Redis 的請求。

不過要注意一點，批量獲取會導(dǎo)致一定范圍內(nèi)的限流誤差。比如你取了 10 個此時不用，等下一秒再用，那同一時刻集群機(jī)器總處理量可能會超過閾值。

其實「批量」這個優(yōu)化點太常見了，不論是 MySQL 的批量刷盤，還是 Kafka 消息的批量發(fā)送還是分布式 ID 的高性能發(fā)號，都包含了「批量」的思想。

當(dāng)然分布式限流還有一種思想是平分，假設(shè)之前單機(jī)限流 500，現(xiàn)在集群部署了 5 臺，那就讓每臺繼續(xù)限流 500 唄，即在總的入口做總的限流限制，然后每臺機(jī)子再自己實現(xiàn)限流。

總結(jié)

（1）計數(shù)器限流算法：簡單粗暴但邊界值統(tǒng)計不準(zhǔn)確（臨界問題）

（2）滑動窗口限流算法：統(tǒng)計準(zhǔn)確易理解，占用存儲空間高，且不能保證請求穩(wěn)定，適合時間敏感的場景

（3）令牌桶限流算法：相比滑動窗口限流算法占用空間少，可以限制平均流量和流量最大值，適合有突發(fā)流量需求的場景。存在誤殺的問題，需要預(yù)熱（啟動時先放入一些令牌）。

（4）漏斗限流算法：相比滑動窗口限流算法占用空間少，可以嚴(yán)格限制流量。請求會先放在桶中，不適合低延遲的業(yè)務(wù)。

參考

• 重點好文：圖解+代碼|常見限流算法以及限流在單機(jī)分布式場景下的思考
• 推薦好文：高并發(fā)系統(tǒng)限流-漏桶算法和令牌桶算法
• 好文：大話常用限流算法與應(yīng)用場景
• 接口限流算法：漏桶算法&令牌桶算法
• 精度不夠，滑動時間來湊「限流算法第二把法器：滑動時間窗口算法」- 第301篇
• 限流的算法有哪些？

總結(jié)

以上是生活随笔為你收集整理的常用限流算法分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。