這個時候如果不做任何保護措施，服務(wù)器就會承受很大的處理壓力，請求量很高，服務(wù)器負載也很高，并且當(dāng)請求超過服務(wù)器承載極限的時候，系統(tǒng)就會崩潰，導(dǎo)致所有人都不能訪問。

[[281662]]

為了應(yīng)用服務(wù)的高可用，一個常用的辦法是對大流量的請求(秒殺/搶購)進行限流，攔截掉大部分請求，只允許一部分請求真正進入后端服務(wù)器，這樣就可以防止大量請求造成系統(tǒng)壓力過大導(dǎo)致的系統(tǒng)崩潰，從而保護服務(wù)正?？捎?。

令牌桶(Token Bucket) 、 漏桶(leaky bucket) 和 計數(shù)器 算法是最常用的三種限流的算法。

限流算法

計數(shù)器

計數(shù)器限流算法也是比較常用的，主要用來限制總并發(fā)數(shù)。比如限流 qps 為 100，算法的實現(xiàn)思路就是從第一個請求進來開始計時，在接下去的 1s 內(nèi)，每來一個請求，就把計數(shù)加 1 ，如果累加的數(shù)字達到了 100 ，那么后續(xù)的請求就會被全部拒絕。等到 1s 結(jié)束后，把計數(shù)恢復(fù)成 0 ，重新開始計數(shù)。

這種實現(xiàn)方式有一個弊端：如果我在單位時間 1s 內(nèi)的前 10ms ，已經(jīng)通過了 100個請求，那后面的 990ms ，只能眼巴巴的把請求拒絕，這種現(xiàn)象稱為 突刺現(xiàn)象。

漏桶

為了消除 突刺現(xiàn)象，可以采用漏桶算法實現(xiàn)限流，漏桶算法這個名字就很形象，算法內(nèi)部有一個容器，類似生活用到的漏斗，當(dāng)請求進來時，相當(dāng)于水倒入漏斗，然后從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。

不管服務(wù)調(diào)用方多么不穩(wěn)定，通過漏桶算法進行限流，每 10 毫秒處理一次請求。因為處理的速度是固定的，請求進來的速度是未知的，可能突然進來很多請求，沒來得及處理的請求就先放在桶里，既然是個桶，肯定是有容量上限，如果桶滿了，那么新進來的請求就丟棄。

在算法實現(xiàn)方面，可以 準(zhǔn)備一個隊列，用來保存請求，另外通過一個線程池定期從隊列中獲取請求并執(zhí)行，可以一次性獲取多個并發(fā)執(zhí)行。

這種算法，在使用過后也存在弊端：無法應(yīng)對短時間的突發(fā)流量，同時它的優(yōu)點也是可以平滑網(wǎng)絡(luò)上的突發(fā)流量，請求可以被整形成穩(wěn)定的流量。

令牌桶

從某種意義上講，令牌桶算法是對漏桶算法的一種改進，桶算法能夠限制請求調(diào)用的速率，而令牌桶算法能夠在限制調(diào)用的平均速率的同時還允許一定程度的突發(fā)調(diào)用。

在令牌桶算法中，存在一個桶，用來存放固定數(shù)量的令牌。算法中存在一種機制，以一定的速率往桶中放令牌。每次請求調(diào)用需要先獲取令牌，只有拿到令牌，才有機會繼續(xù)執(zhí)行，否則選擇選擇等待可用的令牌、或者直接拒絕。

放令牌這個動作是持續(xù)不斷的進行，如果桶中令牌數(shù)達到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時進來的請求就可以直接拿到令牌執(zhí)行，比如設(shè)置 qps為 100 ，那么限流器初始化完成一秒后，桶中就已經(jīng)有 100 個令牌了，這時服務(wù)還沒完全啟動好，等啟動完成對外提供服務(wù)時，該限流器可以抵擋瞬時的 100 個請求。所以，只有桶中沒有令牌時，請求才會進行等待，最后相當(dāng)于以一定的速率執(zhí)行。

實現(xiàn)思路：可以 準(zhǔn)備一個隊列，用來保存令牌，另外通過一個線程池定期生成令牌放到隊列中，每來一個請求，就從隊列中獲取一個令牌，并繼續(xù)執(zhí)行。

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

集群限流

Redis 請求窗口

采用redis 的計時和計數(shù)方式,在規(guī)定的時間窗口期,允許通過的最大請求數(shù)量

比如為了限制某個資源被每個用戶或者商戶的訪問次數(shù)，5s 只能訪問 2 次，或者一天只能調(diào)用 1000 次，這種需求，單機限流是無法實現(xiàn)的，這時就需要通過集群限流進行實現(xiàn)。

如何實現(xiàn)?為了控制訪問次數(shù)，肯定需要一個計數(shù)器，而且這個計數(shù)器只能保存在第三方服務(wù)，比如redis。

大概思路：每次有相關(guān)操作的時候，就向 redis 服務(wù)器發(fā)送一個 incr 命令，比如需要限制某個用戶訪問 /index 接口的次數(shù)，只需要拼接用戶 id 和接口名生成 redis 的 key ，每次該用戶訪問此接口時，只需要對這個 key 執(zhí)行 incr 命令，在這個 key 帶上過期時間，就可以實現(xiàn)指定時間的訪問頻率。

Nginx 限流

Nginx按請求速率限速模塊使用的是漏桶算法，即能夠強行保證請求的實時處理速度不會超過設(shè)置的閾值。

Nginx官方版本限制IP的連接和并發(fā)分別有兩個模塊： - limit_req_zone 用來限制單位時間內(nèi)的請求數(shù)，即速率限制,采用的漏桶算法 “leaky bucket”。 - limit_req_conn 用來限制同一時間連接數(shù)，即并發(fā)限制。