欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

golang rate令牌桶源碼分析實現(xiàn)方式

 更新時間:2023年07月10日 16:48:17   作者:dandyhuang  
這篇文章主要介紹了golang rate令牌桶源碼分析實現(xiàn)方式,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教

golang rate令牌桶實現(xiàn)

高并發(fā)三板斧:

限流、緩存、降級。

限流其實就是:

當高并發(fā)或者瞬時高并發(fā)時,為了保證系統(tǒng)的穩(wěn)定性、可用性,系統(tǒng)以犧牲部分請求為代價或者延遲處理請求為代價,保證系統(tǒng)整體服務可用。

今天就給大家介紹golang 官方擴展包 time(golang.org/x/time/rate) 中,一個基于令牌桶的限流器實現(xiàn)。

它的實現(xiàn)java guava rate limiter中的實現(xiàn)思路是一樣的。

按照該思路我也用c++實現(xiàn)了一份代碼,可以供大家參考代碼token_limiter.cpp實現(xiàn)。

令牌桶

在這里插入圖片描述

令牌桶算法的原理

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

自然我們可能會想到啟一個協(xié)程,定時的往桶里丟入令牌。

但golang中沒有按照這個思路去實現(xiàn)。而是實時計算當前產(chǎn)生的令牌數(shù)。

可能會有人覺得,把定時的時間片調低一些,比如1us就去計算產(chǎn)生的令牌數(shù)。這種效果也和實時計算效果也差不多。

但這種處理,隨著精度越高,cpu親緣性的問題就越嚴重。我們來看看golang是怎么實現(xiàn)的。思路其實也是比較巧妙。

time/rate實現(xiàn)

package limiter
import (
 "fmt"
 "testing"
 "time"
 "golang.org/x/time/rate"
)
func TestLimter(t *testing.T) {
	limiter := rate.NewLimiter(rate.Every(time.Millisecond*10), 2)
	for i := 0; i < 10; i++ {
		var ok bool
		if limiter.Allow() {
			ok = true
		}
		time.Sleep(time.Millisecond * 3)
		fmt.Println(ok, limiter.Burst())
	}
}

執(zhí)行結果:

=== RUN   TestLimter
true 2
true 2
false 2
true 2
false 2
false 2
true 2
false 2
false 2
true 2
--- PASS: TestLimter1 (0.03s)

因為初始化有2個令牌在里頭,隨著后續(xù)執(zhí)行,每10ms產(chǎn)生一個令牌。所以后續(xù)10ms內(nèi),只有一個請求能獲取到令牌。

創(chuàng)建限流器

func NewLimiter(r Limit, b int) *Limiter {
	return &Limiter{
		limit: r,
		burst: b,
	}
}
type Limiter struct {
	mu     sync.Mutex
	limit  Limit
	burst  int
	tokens float64
	// last is the last time the limiter's tokens field was updated
	last time.Time
	// lastEvent is the latest time of a rate-limited event (past or future)
	lastEvent time.Time
}

Limiter參數(shù)中

  • mu:每次請求并發(fā)安全,加鎖處理
  • burst : 桶內(nèi)能存放令牌的個數(shù)
  • limit:生成令牌的速率
  • tokens: 剩余令牌個數(shù)
  • last: 上一次取走 token 的時間
  • lastEvent:上一次限流事件的時間

Allow 判斷是否運行通過

// 判斷是否滿足條件
func (lim *Limiter) Allow() bool {
	return lim.AllowN(time.Now(), 1)
}
func (lim *Limiter) AllowN(now time.Time, n int) bool {
	return lim.reserveN(now, n, 0).ok
}
func (lim *Limiter) reserveN(now time.Time, n int, maxFutureReserve time.Duration) Reservation {
  // 加鎖防止并發(fā)
	lim.mu.Lock()
	defer lim.mu.Unlock()
	// 邊界處理,都是一些異常設置,設置最大值,或沒有設置的場景
	if lim.limit == Inf {
		return Reservation{
			ok:        true,
			lim:       lim,
			tokens:    n,
			timeToAct: now,
		}
	} else if lim.limit == 0 {
		var ok bool
		if lim.burst >= n {
			ok = true
			lim.burst -= n
		}
		return Reservation{
			ok:        ok,
			lim:       lim,
			tokens:    lim.burst,
			timeToAct: now,
		}
	}
	 // 從上次獲取令牌到當前時間,共產(chǎn)生的令牌數(shù)tokens
	now, last, tokens := lim.advance(now)
	// 減去需要的令牌數(shù)據(jù)
	tokens -= float64(n)
	var waitDuration time.Duration
  // 如果需要的令牌數(shù)tokens 為負數(shù),則計算需要等待的 WaitDuration時間
	if tokens < 0 {
		waitDuration = lim.limit.durationFromTokens(-tokens)
	}
	// 獲取需要的令牌數(shù)如果大于桶的容量  或者 等待時間大于設置的maxFutureReserve
	ok := n <= lim.burst && waitDuration <= maxFutureReserve
	// 構造一個Reservation對象,后續(xù)結果返回該對象
	r := Reservation{
		ok:    ok,
		lim:   lim,
		limit: lim.limit,
	}
  // 成功才更新該對象
	if ok {
		r.tokens = n
		r.timeToAct = now.Add(waitDuration)
	}
	// 成功了,才把上次時間和tokens數(shù)更新
	if ok {
		lim.last = now
		lim.tokens = tokens
		lim.lastEvent = r.timeToAct
	} else {
    // 這里因為鎖并發(fā)的問題,所以才回導致last會有更新
		lim.last = last
	}
	return r
}

reserveN中記錄了上次訪問的時間和當前桶中令牌的數(shù)量。

當再次訪問時,通過上次訪問記錄的時間實時計算當前令牌的數(shù)量,決定是否可以放行。

advance計算產(chǎn)生的令牌數(shù)

func (lim *Limiter) advance(now time.Time) (newNow time.Time, newLast time.Time, newTokens float64) {
	last := lim.last
  // 因為加鎖的原因,所以出現(xiàn)這種情況
	if now.Before(last) {
		last = now
	}
	// (當前時間-上次時間)* 速率 = 產(chǎn)生的令牌數(shù)
	elapsed := now.Sub(last)
	delta := lim.limit.tokensFromDuration(elapsed)
	tokens := lim.tokens + delta
	if burst := float64(lim.burst); tokens > burst {
		tokens = burst
	}
	return now, last, tokens
}

這里AllowN()請求中,我們是在Allow()的時候調用lim.AllowN(time.Now(), 1),并把當前時間傳入。

這時候,如果reserveN處理的比較慢,并且請求成功。

如線程t1請求的時間為10:10:12秒,線程t2請求時間為10:10:10秒。 而線程t1先搶到了鎖。

并處理請求成功。接下去t2才進行處理。這時last為10:10:12秒,now為10:10:10秒的場景

總結

golang/rate包中,犧牲一點加鎖的性能,實時計算產(chǎn)生的令牌數(shù)。

這種實現(xiàn)的好處: 對令牌的計算可以非常精確。

而對比于定時往桶里添加令牌的實現(xiàn),雖然在請求可以使用原子計算,不上鎖實現(xiàn)。

但對于令牌的計算來說,是比較不準確的,需要根據(jù)定時器的精度來保證。

而精度越小,cpu親緣性問題就越明顯。

個人覺得雖然加鎖的實現(xiàn),對性能有一部分影響,但是令牌桶都是在計算,所以性能不會有很大的問題,加鎖時間不長。

以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。

相關文章

最新評論