不管是在單體服務中還是在微服務中，開發者為前端提供的API接口都是有訪問上限的，當訪問頻率或者並發量超過其承受范圍時候，我們就必須考慮限流來保證接口的可用性或者降級可用性。即接口也需要安裝上保險絲，以防止非預期的請求對系統壓力過大而引起的系統癱瘓。
go-zero 集成了開箱即用的 限流器 。其中內置了兩種限流器，也對應兩類使用場景：
| 種類 | 原理 | 場景 |
|---|---|---|
periodlimit |
單位時間限制訪問次數 | 需要強行限制數據的傳輸速率 |
tokenlimit |
令牌桶限流 | 限制數據的平均傳輸速率，同時允許某種程度的突發傳輸 |
本文就來介紹一下 periodlimit 。
使用
const (
seconds = 1
total = 100
quota = 5
)
// New limiter
l := NewPeriodLimit(seconds, quota, redis.NewRedis(s.Addr(), redis.NodeType), "periodlimit")
// take source
code, err := l.Take("first")
if err != nil {
logx.Error(err)
return true
}
// switch val => process request
switch code {
case limit.OverQuota:
logx.Errorf("OverQuota key: %v", key)
return false
case limit.Allowed:
logx.Infof("AllowedQuota key: %v", key)
return true
case limit.HitQuota:
logx.Errorf("HitQuota key: %v", key)
// todo: maybe we need to let users know they hit the quota
return false
default:
logx.Errorf("DefaultQuota key: %v", key)
// unknown response, we just let the sms go
return true
}
periodlimit
go-zero 采取 滑動窗口 計數的方式，計算一段時間內對同一個資源的訪問次數，如果超過指定的 limit ，則拒絕訪問。當然如果你是在一段時間內訪問不同的資源，每一個資源訪問量都不超過 limit ，此種情況是允許大量請求進來的。
而在一個分布式系統中，存在多個微服務提供服務。所以當瞬間的流量同時訪問同一個資源，如何讓計數器在分布式系統中正常計數？ 同時在計算資源訪問時，可能會涉及多個計算，如何保證計算的原子性？
go-zero借助redis的incrby做資源訪問計數- 采用
lua script做整個窗口計算，保證計算的原子性
下面來看看 lua script 控制的幾個關鍵屬性：
| argument | mean |
|---|---|
| key[1] | 訪問資源的標示 |
| ARGV[1] | limit => 請求總數，超過則限速。可設置為 QPS |
| ARGV[2] | window大小 => 滑動窗口，用 ttl 模擬出滑動的效果 |
-- to be compatible with aliyun redis,
-- we cannot use `local key = KEYS[1]` to reuse thekey
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
-- incrbt key 1 => key visis++
local current = redis.call("INCRBY", KEYS[1], 1)
-- 如果是第一次訪問，設置過期時間 => TTL = window size
-- 因為是只限制一段時間的訪問次數
if current == 1 then
redis.call("expire", KEYS[1], window)
return 1
elseif current < limit then
return 1
elseif current == limit then
return 2
else
return 0
end
至於上述的 return code ，返回給調用方。由調用方來決定請求后續的操作：
| return code | tag | call code | mean |
|---|---|---|---|
| 0 | OverQuota | 3 | over limit |
| 1 | Allowed | 1 | in limit |
| 2 | HitQuota | 2 | hit limit |
下面這張圖描述了請求進入的過程，以及請求觸發 limit 時后續發生的情況：
后續處理
如果在服務某個時間點，請求大批量打進來，periodlimit 短期時間內達到 limit 閾值，而且設置的時間范圍還遠遠沒有到達。后續請求的處理就成為問題。
periodlimit 中並沒有處理，而是返回 code 。把后續請求的處理交給了開發者自己處理。
- 如果不做處理，那就是簡單的將請求拒絕
- 如果需要處理這些請求，開發者可以借助
mq將請求緩沖，減緩請求的壓力 - 采用
tokenlimit，允許暫時的流量沖擊
所以下一篇我們就來聊聊 tokenlimit
總結
go-zero 中的 periodlimit 限流方案是基於 redis 計數器，通過調用 redis lua script ，保證計數過程的原子性，同時保證在分布式的情況下計數是正常的。
但是這種方案也存在缺點，因為它要記錄時間窗口內的所有行為記錄，如果這個量特別大的時候，內存消耗會變得非常嚴重。
參考
同時歡迎大家使用 go-zero 並加入我們，https://github.com/tal-tech/go-zero
如果覺得文章不錯，歡迎github點個star 👏