如果系統的峰值流量會超過了預估的峰值，對于核心服務也產生了比較大的影響，而我們總不能把核心服務整體降級吧？那么在這個時候要如何保證服務的穩定性呢?你認為可以使用限流的方案，而提到限流，相信我們多多少少在以下幾個地方出錯過：

• 限流演算法選擇不當，導致限流效果不好；
• 開啟了限流卻發現整體性能有損耗；
• 只實作了單機的限流卻沒有實作整體系統的限流；

說白了，之所以出現這些問題還是對限流的演算法以及實際應用不熟練，

究竟什么是限流

限流指的是通過限制到達系統的并發請求數量，保證系統能夠正常回應部分用戶請求，而對 于超過限制的流量，則只能通過拒絕服務的方式保證整體系統的可用性，限流策略一般部署 在服務的入口層，比如 API 網關中，這樣可以對系統整體流量做塑形，而在微服務架構 中，你、也可以在 RPC 客戶端中引入限流的策略，來保證單個服務不會被過大的流量壓垮，

其實，無論在實際作業生活中還是在之前學習過的知識中，都可能對限流策略有過應用，舉幾個例子，

• 比如，到了十一黃金周的時候想去某個景區游玩，結果到了才發現景區有了臨時的通知，每天僅僅售賣 10 萬張門票，而當天沒有搶到門票的游客就只能第二天起早繼續來搶了，這就是一種常見的限流策略，也就是對一段時間內（在這里是一天）流量做整體的控 制，它可以避免出現游客過多導致的景區環境受到影響的情況，也能保證游客的安全，而 且，如果有擠過地鐵，就更能感同身受了，北京早高峰的地鐵都會限流，想法很直接，就是 控制進入地鐵的人數，保證地鐵不會被擠爆，也可以盡量保障人們的安全，

• 再比如，在 TCP 協議中有一個滑動視窗的概念，可以實作對網路傳輸流量的控制，可以想象一下，如果沒有流量控制，當流量接收方處理速度變慢而發送方還是繼續以之前的速率 發送資料，那么必然會導致流量擁塞，而 TCP 的滑動視窗實際上可以理解為接收方所能提 供的緩沖區的大小，

• 在接收方回復發送方的 ACK 訊息中，會帶上這個視窗的大小，這樣，發送方就可以通過這 個滑動視窗的大小決定發送資料的速率了，如果接收方處理了一些緩沖區的資料，那么這個 滑動視窗就會變大，發送方發送資料的速率就會提升;反之，如果接收方接收了一些資料還 沒有來得及處理，那么這個滑動視窗就會減小，發送方發送資料的速率就會減慢，

而無論是在一體化架構還是微服務化架構中，我們也可以在多個維度上對到達系統的流量做控制，比如：

• 可以對系統每分鐘處理多少請求做限制；
• 可以針對單個介面設定每分鐘請求流量的限制；
• 可以限制單個 IP、用戶 ID 或者設備 ID 在一段時間內發送請求的數量；
• 對于服務于多個第三方應用的開放平臺來說，每一個第三方應用對于平臺方來說都有一個唯一的 appkey 來標識，那么你也可以限制單個 appkey 的訪問介面的速率，

而實作上述限制速率的方式是基于一些限流演算法的，那么常見的限流的演算法有哪些呢？在實作限流的時候都有哪些方式呢？

應該知道的限流演算法

固定視窗與滑動視窗的演算法

我們知道，限流的目的是限制一段時間內發向系統的總體請求量，比如，限制一分鐘之內系統只能承接 1 萬次請求，那么最暴力的一種方式就是記錄這一分鐘之內訪問系統的請求量 有多少，如果超過了 1 萬次的限制，那么就觸發限流的策略回傳請求失敗的錯誤，如果這 一分鐘的請求量沒有達到限制，那么在下一分鐘到來的時候先重置請求量的計數，再統計這一分鐘的請求量是否超過限制，

這種演算法叫做固定視窗演算法，在實作它的時候，首先要啟動一個定時器定期重置計數，

而限流的邏輯就非常簡單了，只需要比較計數值是否大于閾值就可以了：

這種演算法雖然實作非常簡單，但是卻有一個很大的缺陷：無法限制短時間之內的集中流 量，假如我們需要限制每秒鐘只能處理 10 次請求，如果前一秒鐘產生了 10 次請求，這 10 次請求全部集中在最后的 10 毫秒中，而下一秒鐘的前 10 毫秒也產生了 10 次請求，那么 在這 20 毫秒中就產生了 20 次請求，超過了限流的閾值，但是因為這 20 次請求分布在兩 個時間視窗內，所以沒有觸發限流，這就造成了限流的策略并沒有生效，

為了解決這個缺陷，就有了基于滑動視窗的演算法， 這個演算法的原理是將時間的視窗劃分為 多個小視窗，每個小視窗中都有單獨的請求計數，比如下面這張圖，我們將 1s 的時間視窗 劃分為 5 份，每一份就是 200ms;那么當在 1s 和 1.2s 之間來了一次新的請求時，我們就 需要統計之前的一秒鐘內的請求量，也就是 0.2s~1.2s 這個區間的總請求量，如果請求量 超過了限流閾值那么就執行限流策略，

滑動視窗的演算法解決了臨界時間點上突發流量無法控制的問題，但是卻因為要存盤每個小的時間視窗內的計數，所以空間復雜度有所增加，

雖然滑動視窗演算法解決了視窗邊界的大流量的問題，但是它和固定視窗演算法一樣，還是無法 限制短時間之內的集中流量，也就是說無法控制流量讓它們更加平滑，因此，在實際的專案 中，很少使用基于時間視窗的限流演算法，而是使用其他限流的演算法：一種演算法叫做漏桶算 法，一種叫做令牌筒演算法，

漏桶演算法與令牌筒演算法

漏桶演算法的原理很簡單，它就像在流量產生端和接收端之間增加一個漏桶，流量會進入和暫存到漏桶里面，而漏桶的出口處會按照一個固定的速率將流量漏出到接收端（也就是服務介面），

如果流入的流量在某一段時間內大增，超過了漏桶的承受極限，那么多余的流量就會觸發限流策略，被拒絕服務，

經過了漏桶演算法之后，隨機產生的流量就會被整形成為比較平滑的流量到達服務端，從而避免了突發的大流量對于服務介面的影響，這很像九陽真經的口訣：他強由他強，清風拂山崗，他橫由他橫，明月照大江 ， 也就是說，無論流入的流量有多么強橫，多 么不規則，經過漏桶處理之后，流出的流量都會變得比較平滑，

而在實作時，我們一般會使用訊息佇列作為漏桶的實作，流量首先被放入到訊息佇列中排隊，由固定的幾個佇列處理程式來消費流量，如果訊息佇列中的流量溢位，那么后續的流量就會被拒絕，這個演算法的思想是不是與訊息佇列削峰填谷的作用相似呢？

另一種令牌桶演算法的基本演算法是這樣的：

• 如果我們需要在一秒內限制訪問次數為 N 次，那么就每隔 1/N 的時間，往桶內放入一個 令牌；
• 在處理請求之前先要從桶中獲得一個令牌，如果桶中已經沒有了令牌，那么就需要等待 新的令牌或者直接拒絕服務；
• 桶中的令牌總數也要有一個限制，如果超過了限制就不能向桶中再增加新的令牌了，這 樣可以限制令牌的總數，一定程度上可以避免瞬時流量高峰的問題，
  
  如果要從這兩種演算法中做選擇，我更傾向于使用令牌桶演算法，原因是漏桶演算法在面對突發流量的時候，采用的解決方式是快取在漏桶中， 這樣流量的回應時間就會增長，這就與互聯 網業務低延遲的要求不符；而令牌桶演算法可以在令牌中暫存一定量的令牌，能夠應對一定的 突發流量，所以一般我會使用令牌桶演算法來實作限流方案，而 Guava 中的限流方案就是使 用令牌桶演算法來實作的，

可以看到，使用令牌桶演算法就需要存盤令牌的數量，如果是單機上實作限流的話，可以在行程中使用一個變數來存盤;但是如果在分布式環境下，不同的機器之間無法共享行程中的 變數，我們就一般會使用 Redis 來存盤這個令牌的數量，這樣的話，每次請求的時候都需 要請求一次 Redis 來獲取一個令牌，會增加幾毫秒的延遲，性能上會有一些損耗，因此， 一個折中的思路是: 我們可以在每次取令牌的時候，不再只獲取一個令牌，而是獲取一批 令牌，這樣可以盡量減少請求 Redis 的次數，

總結

我們了解了限流的定義和作用，以及常見的幾種限流演算法，我們需要了解的重點是：

1. 限流是一種常見的服務保護策略，你可以在整體服務、單個服務、單個介面、單個 IP 或 者單個用戶等多個維度進行流量的控制；
2. 基于時間視窗維度的演算法有固定視窗演算法和滑動視窗演算法，兩者雖然能一定程度上實作限流的目的，但是都無法讓流量變得更平滑；
3. 令牌桶演算法和漏桶演算法則能夠塑形流量，讓流量更加平滑，但是令牌桶演算法能夠應對一定的突發流量，所以在實際專案中應用更多，

限流策略是微服務治理中的標配策略，只是你很難在實際中確認限流的閾值是多少，設定的小了容易誤傷正常的請求，設定的大了則達不到限流的目的，所以，一般在實際專案中，我們會把閾值放置在配置中心中方便動態調整;同時，我們可以通過定期地壓力測驗得到整體系統以及每個微服務的實際承載能力，然后再依據這個壓測出來的值設定合適的閾值，