Go實現(xiàn)用戶每日限額的方法(例一天只能領三次福利)
如果你寫一個 bug 管理系統(tǒng),用了這個 PeriodLimit 你就可以限制每個測試人員每天只能給你提一個 bug。工作是不是就輕松很多了?:P
如今微服務架構大行其道本質原因是因為要降低系統(tǒng)的整體復雜度,將系統(tǒng)風險均攤到子系統(tǒng)從而最大化保證系統(tǒng)的穩(wěn)定性,通過領域劃分拆成不同的子系統(tǒng)后各個子系統(tǒng)能獨立的開發(fā)、測試、發(fā)布,研發(fā)節(jié)奏和效率能明顯提高。
但同時也帶來了問題,比如:調用鏈路過長,部署架構復雜度提升,各種中間件需要支持分布式場景。為了確保微服務的正常運行,服務治理就不可或缺了,通常包括:限流,降級,熔斷。
其中限流指的是針對接口調用頻率進行限制,以免超出承載上限拖垮系統(tǒng)。比如:
- 電商秒殺場景
- API 針對不同商戶限流
常用的限流算法有:
- 固定時間窗口限流
- 滑動時間窗口限流
- 漏桶限流
- 令牌桶限流
本文主要講解固定時間窗口限流算法,主要的使用場景比如:
- 每個手機號每天只能發(fā)5條驗證碼短信
- 每個用戶每小時只能連續(xù)嘗試3次密碼
- 每個會員每天只能領3次福利
工作原理
從某個時間點開始每次請求過來請求數(shù)+1,同時判斷當前時間窗口內請求數(shù)是否超過限制,超過限制則拒絕該請求,然后下個時間窗口開始時計數(shù)器清零等待請求。

優(yōu)缺點
優(yōu)點
實現(xiàn)簡單高效,特別適合用來限制比如一個用戶一天只能發(fā)10篇文章、只能發(fā)送5次短信驗證碼、只能嘗試登錄5次等場景,實際業(yè)務中此類場景非常多見。
缺點
固定時間窗口限流的缺點在于無法處理臨界區(qū)請求突發(fā)場景。
假設每 1s 限流 100 次請求,用戶在中間 500ms 時開始 1s 內發(fā)起 200 次請求,此時 200 次請求是可以全部通過的。這就和我們預期 1s 限流 100 次不合了,根源在于限流的細粒度太粗。

go-zero 代碼實現(xiàn)
core/limit/periodlimit.go
go-zero 中使用 redis 過期時間來模擬固定時間窗口。
redis lua 腳本:
-- KYES[1]:限流器key
-- ARGV[1]:qos,單位時間內最多請求次數(shù)
-- ARGV[2]:單位限流窗口時間
-- 請求最大次數(shù),等于p.quota
local limit = tonumber(ARGV[1])
-- 窗口即一個單位限流周期,這里用過期模擬窗口效果,等于p.permit
local window = tonumber(ARGV[2])
-- 請求次數(shù)+1,獲取請求總數(shù)
local current = redis.call("INCRBY",KYES[1],1)
-- 如果是第一次請求,則設置過期時間并返回 成功
if current == 1 then
redis.call("expire",KYES[1],window)
return 1
-- 如果當前請求數(shù)量小于limit則返回 成功
elseif current < limit then
return 1
-- 如果當前請求數(shù)量==limit則返回 最后一次請求
elseif current == limit then
return 2
-- 請求數(shù)量>limit則返回 失敗
else
return 0
end固定時間窗口限流器定義
type (
? // PeriodOption defines the method to customize a PeriodLimit.
? // go中常見的option參數(shù)模式
? // 如果參數(shù)非常多,推薦使用此模式來設置參數(shù)
? PeriodOption func(l *PeriodLimit)
? // A PeriodLimit is used to limit requests during a period of time.
? // 固定時間窗口限流器
? PeriodLimit struct {
? ? // 窗口大小,單位s
? ? period ? ? int
? ? // 請求上限
? ? quota ? ? ?int
? ? // 存儲
? ? limitStore *redis.Redis
? ? // key前綴
? ? keyPrefix ?string
? ? // 線性限流,開啟此選項后可以實現(xiàn)周期性的限流
? ? // 比如quota=5時,quota實際值可能會是5.4.3.2.1呈現(xiàn)出周期性變化
? ? align ? ? ?bool
? }
)注意一下 align 參數(shù),align=true 時請求上限將會呈現(xiàn)周期性的變化。
比如quota=5時實際quota可能是5.4.3.2.1呈現(xiàn)出周期性變化
限流邏輯
其實限流邏輯在上面的 lua 腳本實現(xiàn)了,需要注意的是返回值
- 0:表示錯誤,比如可能是 redis 故障、過載
- 1:允許
- 2:允許但是當前窗口內已到達上限,如果是跑批業(yè)務的話此時可以休眠 sleep 一下等待下個窗口(作者考慮的非常細致)
- 3:拒絕
// Take requests a permit, it returns the permit state.
// 執(zhí)行限流
// 注意一下返回值:
// 0:表示錯誤,比如可能是redis故障、過載
// 1:允許
// 2:允許但是當前窗口內已到達上限
// 3:拒絕
func (h *PeriodLimit) Take(key string) (int, error) {
? // 執(zhí)行l(wèi)ua腳本
? resp, err := h.limitStore.Eval(periodScript, []string{h.keyPrefix + key}, []string{
? ? strconv.Itoa(h.quota),
? ? strconv.Itoa(h.calcExpireSeconds()),
? })
??
? if err != nil {
? ? return Unknown, err
? }
? code, ok := resp.(int64)
? if !ok {
? ? return Unknown, ErrUnknownCode
? }
? switch code {
? case internalOverQuota:
? ? return OverQuota, nil
? case internalAllowed:
? ? return Allowed, nil
? case internalHitQuota:
? ? return HitQuota, nil
? default:
? ? return Unknown, ErrUnknownCode
? }
}這個固定窗口限流可能用來限制比如一個用戶一天只能發(fā)送5次驗證碼短信,此時我們就需要跟中國時區(qū)對應(GMT+8),并且其實限流時間應該從零點開始,此時我們需要額外對齊(設置 align 為 true)。
// 計算過期時間也就是窗口時間大小
// 如果align==true
// 線性限流,開啟此選項后可以實現(xiàn)周期性的限流
// 比如quota=5時,quota實際值可能會是5.4.3.2.1呈現(xiàn)出周期性變化
func (h *PeriodLimit) calcExpireSeconds() int {
? if h.align {
? ? now := time.Now()
? ? _, offset := now.Zone()
? ? unix := now.Unix() + int64(offset)
? ? return h.period - int(unix%int64(h.period))
? }
? return h.period
}項目地址
https://github.com/zeromicro/go-zero
到此這篇關于Go實現(xiàn)用戶每日限額的方法(例一天只能領三次福利)的文章就介紹到這了,更多相關Go 用戶每日限額內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
axios?gin的GET和POST請求實現(xiàn)示例
這篇文章主要為大家介紹了axios?gin的GET和POST請求實現(xiàn)示例,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步早日升職加薪2022-04-04
一文帶你揭秘Go中new()和make()函數(shù)的區(qū)別和用途
Go(或 Golang)是一種現(xiàn)代、靜態(tài)類型、編譯型的編程語言,專為構建可擴展、并發(fā)和高效的軟件而設計,它提供了各種內置的函數(shù)和特性,幫助開發(fā)人員編寫簡潔高效的代碼,在本博客文章中,我們將探討 new() 和 make() 函數(shù)之間的區(qū)別,了解何時以及如何有效地使用它們2023-10-10

