帶你快速瞭解：限流中的漏桶和令牌桶算法

在前文 《限流熔斷是什麼，怎麼作，不作行不行？》中針對 「限流」 動做，有提到流量控制其內部對應着兩種經常使用的限流算法，分別是漏桶算法和令牌桶算法。所以會有的讀者會好奇，這都是些啥？

爲了更進一步的瞭解 WHY，本文來快速探索一下，看看限流下的一些 「算法」 們到底有何做用，是爲什麼成爲流量控制的基石的？

前言

理論上每個對外/內提供功能的資源點，都須要進行必定的流量控制，不然在業務的持續迭代中，是有可能出現突發性流量的場景（就像年初所帶來的一些行業突發轉變，致使業務流量忽然暴增）：

若沒有進行限流，就會出現一些奇奇怪怪的問題點，實則就是系統沒法承受這波流量，逐漸崩潰，走向系統假死。

現實場景

最多見的現實場景就是平常隨處可見的排插、插座，其內置的保險絲，也被稱爲電流保險絲，其主要是起過載保護做用，保險絲會在電流異常升高到必定的高度和熱度的時候，自身熔斷切斷電流，從而起到保護電路安全運行的做用。

所以真實世界中有許多與軟件工程中的限流熔斷的場景有殊途同歸之處，也是爲了控制量，超量就切斷。你也能夠想一想現實生活中是否有遇到其餘相似的例子呢？

漏桶算法（Leaky Bucket）

漏桶算法（Leaky Bucket）是網絡中流量整形（Traffic Shaping）或速率限制（Rate Limiting）時經常使用的一種算法，它的主要目的是控制數據注入到網絡的速率，平滑網絡上的突發流量。

漏桶算法經過其算法調控了流量訪問，使得突發流量能夠被整形，去毛刺，變成一個相對緩和，以便爲網絡提供一個穩定的流量。

漏桶算法的存儲桶主要由三個參數定義，分別是：桶的容量、水從桶中流出的速率、桶的初始充滿度。

其核心理念就如字面意思：一個會漏水的桶。

Bursty Flow

在上圖中，水龍頭表明着突發流量（Bursty Flow）。當網絡中存在突發流量，且無任何調控時，就會出現像 Bursty Data 處相似的場景。主機以 12 Mbps 的速率發送數據，時間持續 2s，總計 24 Mbits 數據。隨後主機暫停發送 5s，而後再以 2 Mbps 的速率發送數據 3s，最終總共發送了 6 Mbits 的數據。

所以主機在 10s 內總共發送了 30 Mbits 的數據。但這裏存在一個問題，就是數據的發送並非平滑的，存在一個較大的波峯。若全部流量都是如此的傳輸方式，將會 「旱的旱死澇的澇死」，對系統並非特別的友好。

Fixed Flow

爲了解決 Bursty Flow 場景的問題。漏桶（Leaky Bucket）出現了，漏桶具備固定的流出速率、固定的容量大小。

在上圖中，漏桶在相同的 10s 內以 3 Mbps 的速率持續發送數據來平滑流量。若水（流量）來的過猛，但水流（漏水）不夠快時，其最終結果就是致使水直接溢出，呈現出來就是拒絕請求/排隊等待的表現。另外當 Buckets 空時，是會出現一次性倒入達到 Bucket 容量限制的水的可能性，此時也可能會出現波峯。

簡單來說就是，一個漏桶，水流進來，但漏桶只有固定的流速來流出水，若容量滿即拒絕，不然將持續保持流量流出。

令牌桶算法

令牌桶算法也是網絡中流量整形或速率限制時經常使用的一種算法，它的主要目的是控制發送到網絡上的數據的數目，並容許突發數據的發送。

令牌桶算法會以一個恆定的速率向桶裏放入令牌，若是有新的請求進來但願進行處理，則必需要先從桶內拿到一個可用的令牌，才能繼續被處理。若桶內無令牌可取時，則拒絕請求/排隊等待。

1. 每 1/r 秒新增一個 token 到 buckets 中。
2. buckets 中最多可容納 b 個令牌。若是桶已滿，將丟棄這個新增的 token（也就是不須要新的 token）。
3. 當主機傳輸 n bytes packets 時，buckets 中若是有 n 個令牌，則取到所需令牌，成功傳輸 n bytes。
4. 當可用的 token 小於 n bytes 時，不會從 buckets 中取到任何 token，本次請求將被拒絕/排隊等待。

漏桶 vs 令牌桶

漏桶算法和令牌桶算法本質上都是爲了作流量整形（Traffic Shaping）或速率限制（Rate Limiting），避免系統由於大流量而被打崩，但二者核心差別在於限流的方向是相反的。

令牌桶限制的是流量的平均流入速率，而且容許必定程度的忽然性流量，最大速率爲桶的容量和生成 token 的速率。而漏桶限制的是流量的流出速率，是相對固定的。

所以也會相對的帶來一個問題，在某些場景中，漏桶算法並不能有效的使用網絡資源，由於漏桶的漏出速率是相對固定的，因此在網絡狀況比較好，沒有擁塞的狀態下，漏桶依然是限制住的，並無辦法放開量。而令牌桶算法則不一樣，其可以是限制平均速率的同時支持必定程度的突發流量。

總結

在軟件系統中，限流經常所表明的就是流量整形、速率限制，是一個很是常見的調控手段。通常咱們會將其在初期集成到統一框架、網關、Mesh 中去。所以建議接觸業務的同窗，都要對這一塊進行考量，便於後續的快速使用/接入，畢竟業務的流量爆發老是來的比較忽然，甚至多是惡意攻擊。

而本文所提到的漏桶，令牌桶都是很是常見的手段，雖然二者獨立出來分析了。但從軟件開發的角度來說，你認爲二者是否能夠融合，結合其優點呢？

個人公衆號

分享 Go 語言、微服務架構和奇怪的系統設計，歡迎你們關注個人公衆號和我進行交流和溝通，二維碼：

最好的關係是互相成就，各位的點贊就是煎魚創做的最大動力，感謝支持。