隨著網際網路的發展,在處理流量的方法也不僅僅為 first-come,first-served,而在共用網路中實現流量管理的基本機制就是排隊。而公平演演算法則是實現在優先順序佇列中基於哪些策略來排隊的」公平佇列「。Token Bucket
則是為公平排隊提供了替代方案。Fair Queue 與 Token Bucket的區別主要在,對於Fair Queue來講,如果請求者目前空閒,Queue會將該請求者的頻寬分配給其他請求者;而 Token Bucket 則是分配給請求者的頻寬是頻寬的上限。
通過例子瞭解演演算法原理
假設出站頻寬是 4個封包/ms,此時有一個需求為,為一個特定的傳送端 A 來分配 1個封包/ms的頻寬。此時可以使用公平排隊的方法分給傳送 A 25%的頻寬。
此時存在的問題是我們希望可以靈活地允許 A 的封包以無規則的時間間隔傳送。例如假設 A 在每個封包傳送後等待1毫秒後再開始下一個封包的傳送。
顯然sence2是合理的,這個場景的解決方法就是令牌桶演演算法,規定 A 的配額,允許指定平均速率和突發容量。當封包不符合令牌桶規範,那麼就認為其不合理,此時會做出一下相應:
delay 被稱為 整形 shaping
, shaping 是指在某個時間間隔內傳送超過 Bc(Committed Burst)的大小,Bc 在這裡指桶的尺寸。由於資料流量是突發性的,當在一段時間內不活動後,再次啟用後的在一個間隔內傳送的數量大於 Bc ,那麼額外的流量被稱為Be (burst excess)。
將流量丟棄或標記超額流量,保持在一個流量速率限制稱為 管制 policing
。
令牌桶的定義是指,有一個桶,以穩定的速度填充令牌;桶中的任何一個溢位都會被丟棄。當要傳送一個封包,需要能夠從桶中取出一個令牌;如果桶是空的那麼此時封包是不合規的封包,必須進行 delay
, drop
, mark
操作。如果桶是滿的,則會傳送與桶容量相對應的突發(短時間內的高頻寬傳輸),這是桶是空的。
令牌桶的規範:\(TB(r,B_{max})\)
那麼公式則表示,桶以指定的速率填充令牌,最大為 \(B_{max}\) 。這就說明了為了使大小為 S 的封包合規,桶內必須至少有 S 個令牌,即 \(B \ge S\),否則封包不合規,在傳送時,桶為 \(B=B-S\)
場景1:假設令牌桶規範為 \(TB(\frac{1}{3}\ packet/ms, 4\ packet)\),桶最初是滿的,封包在以下時間到達 [0, 0, 0, 2, 3, 6, 9, 12]
在處理完所有 T=0
的封包後,桶中還剩 1 個令牌。到第四個封包 T=2
到達時,桶內已經有1個令牌 + \(\frac{2}{3}\) 個令牌;當傳送完第四個封包時,桶內令牌數為 \(\frac{2}{3}\) 。到 T=3
封包時,桶內令牌為1,滿足傳送第 5 個封包。萬鬆完成後桶是空的,在後面 6 9 12時,都滿足3/ms 一個封包,都可以傳送成功
場景2:另外一個範例,在同樣的令牌桶規範下 \(TB(\frac{1}{3}, 4)\),封包到達時間為 [0, 0, 0, 0, 12, 12, 12, 12, 24, 24, 24, 24]
,可以看到在這個場景下,資料到達為3個突發,每個突發4個封包,此時每次傳送完成後桶被清空,當再次填滿時需要12ms,此時另外一組突發達。故這組資料是合規的。、
場景3:在同樣的令牌桶規範下 \(TB(\frac{1}{3}, 4)\),封包到達時間為 [0, 1, 2, 3, 4, 5]
, 這組資料是不合規的
用表格形式表示如下:
封包到達時間 | 0 | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|---|
傳送前桶內令牌 | 4 | 3 \(\frac{1}{3}\) | 2 \(\frac{2}{3}\) | 2 | 1 \(\frac{1}{3}\) | \(\frac{2}{3}\) |
傳送後桶內令牌 | 3 | 2 \(\frac{1}{3}\) | 1 \(\frac{2}{3}\) | 1 | \(\frac{1}{3}\) | \(\frac{2}{3}\) |
如果一個封包在桶中沒有足夠的令牌來傳送它時到達,可以進行整形或管制,整形使封包等到足夠的令牌積累。管制會丟棄封包。或者傳送方可以立即傳送封包,但將其標記為不合規。
漏桶 (leaky bucket)是一種臨時儲存可變數量的請求並將它們組織成設定速率輸出的封包的方法。漏桶的概念與令牌桶比起是相反的,漏桶可以理解為是一個具有恆定服務時間的佇列。
由下圖可以看出,漏桶的概念是一個底部有孔的桶。無論水進入桶的速度是多少,它都會以恆定的速度通過孔從桶中洩漏出來。如果桶中沒有水,則流速為零,如果桶已滿,則多餘的水溢位並丟失。
和令牌桶一樣,漏桶用於流量整形和流量管制
Leaky | Token |
---|---|
桶中存放的是所有到達的封包,必須入桶 | 桶中存放的是定期生成的令牌 |
桶以恆定速率洩漏 | 桶有最大容量 \(B_{max}\) |
突發流量入桶轉換為恆定流量傳送 | 傳送封包需要小號對應的token |
token較leaky的優勢:
在golang中,內建的 rate
包實現了一個令牌桶演演算法,通過 rate.NewLimiter(r,B)
進行構造。與公式\(TB(r,B_{max})\) 意思相同。
type Limiter struct {
limit Limit // 向桶中放置令牌的速率
burst int // 桶的容量
mu sync.Mutex
tokens float64 // 可用令牌容量
last time.Time // 上次放入token的時間
lastEvent time.Time
}
Limiter中帶有三種方法, Allow
、Reserve
、Wait
分別表示Token Bucket中的 shaping
和 policing
:
drop
delay
Reserve()
返回了 ReserveN(time.Now(), 1)
ReserveN()
無論如何都會返回一個 Reservation,指定了呼叫者在 n 個事件發生之前必須等待多長時間。Delay()
方法返回了需要等待的時間,如果時間為0則不需要等待Cancel()
將取消等待wait/waitN
reserveN()
拿到token是合規的,並消耗掉tokenAllowN 為截止到某一時刻,當前桶內桶中數目是否至少為 n 個,滿足則返回 true,同時從桶中消費 n 個 token。反之不消費 Token,false。
func (lim *Limiter) AllowN(now time.Time, n int) bool {
return lim.reserveN(now, n, 0).ok // 由於僅需要一個合規否,顧合規的通過,不合規的丟棄
}
reserveN()
是三個行為的核心,AllowN中指定的為 0 ,因為 maxFutureReserve
是最大的等待時間,AllowN給定的是0,即如果突發大的情況下丟棄額外的 Bc。
func (lim *Limiter) reserveN(now time.Time, n int, maxFutureReserve time.Duration) Reservation {
lim.mu.Lock()
if lim.limit == Inf {
lim.mu.Unlock()
return Reservation{
ok: true,
lim: lim,
tokens: n,
timeToAct: now,
}
}
// 這裡拿到的是now,上次更新token時間和桶內token數量
now, last, tokens := lim.advance(now)
// 計算剩餘的token
tokens -= float64(n)
// Calculate the wait duration
var waitDuration time.Duration
if tokens < 0 {
waitDuration = lim.limit.durationFromTokens(-tokens)
}
// 確定是否合規,n是token
// token 的數量要小於桶的容量,並且 等待時間小於最大等待時間
ok := n <= lim.burst && waitDuration <= maxFutureReserve
// Prepare reservation
r := Reservation{
ok: ok,
lim: lim,
limit: lim.limit,
}
if ok {
r.tokens = n
r.timeToAct = now.Add(waitDuration)
}
// Update state
if ok {
lim.last = now
lim.tokens = tokens
lim.lastEvent = r.timeToAct
} else {
lim.last = last
}
lim.mu.Unlock()
return r
}
在reserveN中呼叫了一個 advance()
函數,
func (lim *Limiter) advance(now time.Time) (newNow time.Time, newLast time.Time, newTokens float64) {
last := lim.last
if now.Before(last) { // 計算上次放入token是否在傳入now之前
last = now
}
// 當 last 很舊時,避免在下面進行 delta 溢位。
// maxElapsed 計算裝滿需要多少時間
maxElapsed := lim.limit.durationFromTokens(float64(lim.burst) - lim.tokens)
elapsed := now.Sub(last) // 上次裝入到現在的時差
if elapsed > maxElapsed { // 上次如果放入token時間超長,就讓他與裝滿時間相等
elapsed = maxElapsed // 即,讓桶為滿的
}
// 裝桶的動作,下面函數表示,elapsed時間內可以生成多少個token
delta := lim.limit.tokensFromDuration(elapsed)
tokens := lim.tokens + delta // 當前的token
if burst := float64(lim.burst); tokens > burst {
tokens = burst // 這裡表示token溢位,讓他裝滿就好
}
return now, last, tokens
}
reserveN()
拿到token是合規的,並消耗掉tokenfunc (lim *Limiter) WaitN(ctx context.Context, n int) (err error) {
if n > lim.burst && lim.limit != Inf {
return fmt.Errorf("rate: Wait(n=%d) exceeds limiter's burst %d", n, lim.burst)
}
// 外部已取消
select {
case <-ctx.Done():
return ctx.Err()
default:
}
// Determine wait limit
now := time.Now()
waitLimit := InfDuration
if deadline, ok := ctx.Deadline(); ok {
waitLimit = deadline.Sub(now)
}
// 三個方法的核心,這裡給定了deatline
r := lim.reserveN(now, n, waitLimit)
if !r.ok {
return fmt.Errorf("rate: Wait(n=%d) would exceed context deadline", n)
}
// Wait if necessary
delay := r.DelayFrom(now)
if delay == 0 {
return nil
}
t := time.NewTimer(delay)
defer t.Stop()
select {
case <-t.C:
// We can proceed.
return nil
case <-ctx.Done():
// Context was canceled before we could proceed. Cancel the
// reservation, which may permit other events to proceed sooner.
r.Cancel()
return ctx.Err()
}
}
在 rate.limiter
中,支援調整速率和桶大小,這樣就可以根據現有環境和條件,來動態的改變 Token生成速率和桶容量
SetLimit(Limit)
更改生成 Token 的速率SetBurst(int)
改變桶容量package main
import (
"log"
"strconv"
"time"
"golang.org/x/time/rate"
)
func main() {
timeLayout := "2006-01-02:15:04:05.0000"
limiter := rate.NewLimiter(1, 5) // BT(1,5)
log.Println("bucket current capacity: " + strconv.Itoa(limiter.Burst()))
length := 20 // 一共請求20次
chs := make([]chan string, length)
for i := 0; i < length; i++ {
chs[i] = make(chan string, 1)
go func(taskId string, ch chan string, r *rate.Limiter) {
err := limiter.Allow()
if !err {
ch <- "Task-" + taskId + " unallow " + time.Now().Format(timeLayout)
}
time.Sleep(time.Duration(5) * time.Millisecond)
ch <- "Task-" + taskId + " run success " + time.Now().Format(timeLayout)
return
}(strconv.FormatInt(int64(i), 10), chs[i], limiter)
}
for _, ch := range chs {
log.Println("task start at " + <-ch)
}
}
通過執行結果可以看出,在突發為20的情況下,allow僅允許了獲得token的事件執行,,這種場景下實現了流量整形的特性。
package main
import (
"context"
"log"
"strconv"
"time"
"golang.org/x/time/rate"
)
func main() {
timeLayout := "2006-01-02:15:04:05.0000"
limiter := rate.NewLimiter(1, 5) // BT(1,5)
log.Println("bucket current capacity: " + strconv.Itoa(limiter.Burst()))
length := 20 // 一共請求20次
chs := make([]chan string, length)
for i := 0; i < length; i++ {
chs[i] = make(chan string, 1)
go func(taskId string, ch chan string, r *rate.Limiter) {
err := limiter.Wait(context.TODO())
if err != nil {
ch <- "Task-" + taskId + " unallow " + time.Now().Format(timeLayout)
}
ch <- "Task-" + taskId + " run success " + time.Now().Format(timeLayout)
return
}(strconv.FormatInt(int64(i), 10), chs[i], limiter)
}
for _, ch := range chs {
log.Println("task start at " + <-ch)
}
}
結果可以看出,在大突發的情況下,在拿到token的任務會立即執行,沒有拿到token的會等待拿到token後繼續執行,這種場景下實現了流量管制的特性
Reference