Redis 从 0 到 1（十四）：接口被刷爆？3 种限流算法的 Go+Redis 实现

我不会起名字322· 后端 / 算法 / 数据库 技术栈 力扣 Hot100 Go 项目 Redis MySQL文章目录Redis 从 0 到 1十四接口被刷爆3 种限流算法的 GoRedis 实现一、现象秒杀开始 1 秒接口被打爆二、算法 1固定窗口最简单有突刺三、算法 2滑动窗口用 ZSet 精确计数四、算法 3令牌桶平滑限流预支能力五、3 种算法对比与选型收藏点 1六、中间件封装收藏点 2七、命令清单与压测建议八、总结Redis 从 0 到 1十四接口被刷爆3 种限流算法的 GoRedis 实现上一篇《Redis 从 0 到 1十三分布式锁被误删、锁不住Go 无 Lua 实现 3 级防御》我们做出了 redisx.Lock链接https://blog.csdn.net/2501_92769340/article/details/167399708 。本篇把粒度从同一时刻谁能做放宽到单位时间能做多少限流。一、现象秒杀开始 1 秒接口被打爆活动开始瞬间网关日志出现大量 502/超时。Redis 没挂、数据库没挂——是接口的 QPS 超过了它能承受的上限假设单实例只能扛 2000 QPS请求堆积把线程池耗光雪崩开始。限流的目标不是拒绝用户而是在入口就把超出的流量优雅地丢掉返回 429 或降级数据保护系统活到流量峰值过去。3 种经典算法各有坑本篇用 GoRedis 全部实现一遍。二、算法 1固定窗口最简单有突刺// AllowFixedWindow 每 window 秒允许 limit 次funcAllowFixedWindow(ctx context.Context,rdb*redis.Client,keystring,limitint64,window time.Duration)(bool,error){// INCR EXPIRE 的经典组合key 带时间窗口戳天然滚动winKey:fmt.Sprintf(rl:%s:%d,key,time.Now().Unix()/int64(window.Seconds()))pipe:rdb.Pipeline()incr:pipe.Incr(ctx,winKey)pipe.Expire(ctx,winKey,windowtime.Second)// 多留 1 秒防边界误差if_,err:pipe.Exec(ctx);err!nil{returnfalse,err}returnincr.Val()limit,nil}坑在哪窗口边界突刺。限制 100 QPS第 1 秒末尾来了 100 个请求第 2 秒开头又来 100 个——窗口各自都没超限但 2 秒内实际打了 200 QPS服务照样被冲垮。三、算法 2滑动窗口用 ZSet 精确计数思路把每个请求的时间戳存进 ZSetmember唯一 idscore毫秒时间戳每次检查当前时间往前滑一个窗口内的数量。// AllowSlidingWindow 滑动窗口窗口内请求精确计数funcAllowSlidingWindow(ctx context.Context,rdb*redis.Client,keystring,limitint64,window time.Duration)(bool,error){now:time.Now().UnixMilli()winStart:now-window.Milliseconds()zkey:rl:sw:key// 用 WATCH 保证清理旧记录 计数 写入新记录原子第 13 篇的套路varallowedbool_,err:rdb.TxPipelined(ctx,func(pipe redis.Pipeliner)error{pipe.ZRemRangeByScore(ctx,zkey,0,fmt.Sprintf(%d,winStart))// 清掉窗口外的cnt:pipe.ZCard(ctx,zkey)if_,err:pipe.Exec(ctx);err!nil{// 占位go-redis 会在函数返回后统一 EXECreturnerr}allowedcnt.Val()limitifallowed{pipe.ZAdd(ctx,zkey,redis.Z{Score:float64(now),Member:fmt.Sprintf(%d,now)})pipe.Expire(ctx,zkey,windowtime.Second)}returnnil})iferr!nil{// 并发冲突时 WATCH 事务失败直接按拒绝处理限流宁可错杀returnfalse,nil}returnallowed,nil}代价每个请求一条 ZAdd 一条 ZRemRangeByScore 一次事务写放大明显。QPS 高万级时不划算——这时用算法 3。四、算法 3令牌桶平滑限流预支能力令牌桶桶容量burst每秒补充rate个令牌请求拿走一个令牌才放行桶空则拒绝。平滑无突刺且能容忍短时突发。用 Redis Hash 存{tokens, last_refill_time}扣减逻辑用 WATCH/MULTI 保证并发下不多发typeTokenBucketstruct{rdb*redis.Client burstint64ratefloat64// 每秒补充的令牌数}func(b*TokenBucket)Allow(ctx context.Context,keystring)(bool,error){hkey:rl:tb:keyvarallowedbool_,err:b.rdb.TxPipelined(ctx,func(pipe redis.Pipeliner)error{hm:pipe.HGetAll(ctx,hkey)if_,err:pipe.Exec(ctx);err!nil{returnerr}vals:hm.Val()tokens:b.burst last:time.Now().UnixMilli()ift,ok:vals[tokens];ok{fmt.Sscanf(t,%d,tokens)fmt.Sscanf(vals[ts],%d,last)}// 按流逝时间补充令牌上限 burstrefill:float64(time.Now().UnixMilli()-last)/1000*b.rate tokensint64(math.Min(float64(tokens)refill,float64(b.burst)))iftokens0{allowedtruetokens--}pipe.HSet(ctx,hkey,tokens,tokens,ts,time.Now().UnixMilli())pipe.Expire(ctx,hkey,time.Hour)returnnil})iferr!nil{returnfalse,nil}returnallowed,nil}五、3 种算法对比与选型收藏点 1维度固定窗口滑动窗口令牌桶实现复杂度2 条命令ZSet 事务Hash 事务突刺问题窗口边界双倍流量无无突发被 burst 平滑限制写放大低高每请求 3 写中适合场景粗粒度保护如 1 分钟 1000 次精度要求高的计数平滑 QPS 容忍突发API 网关组合用法是生产常态外层固定窗口挡风暴便宜内层令牌桶平滑精确。六、中间件封装收藏点 2funcRateLimitMiddleware(rdb*redis.Client,tb*TokenBucket)func(http.Handler)http.Handler{returnfunc(next http.Handler)http.Handler{returnhttp.HandlerFunc(func(w http.ResponseWriter,r*http.Request){// 按用户/IP 维度限流key 取登录用户 id 或 X-Forwarded-Forkey:r.Header.Get(X-Forwarded-For)ok,err:tb.Allow(r.Context(),key)iferr!nil||!ok{w.Header().Set(Retry-After,1)http.Error(w,{code:429,msg:请求过于频繁},http.StatusTooManyRequests)return}next.ServeHTTP(w,r)})}}配套约定返回 429 要带Retry-After限流维度选谁要想清楚——按 IP 会误伤 NAT 后的公司出口按用户 id 会被小号绕过。七、命令清单与压测建议命令用于算法INCR EXPIRE固定窗口ZADD/ZCARD/ZREMRANGEBYSCORE/ZREVRANGE滑动窗口HGETALL/HSET WATCH/MULTI令牌桶EXPIRE三种都要计数器 key 必须带 TTL否则内存泄漏压测建议用第 5 篇的压测器改造验证100 QPS 限制下压 500 QPS1 秒吞吐 ≈100拒绝率 ≈80%边界测试用固定窗口故意在窗口边界打双倍流量验证滑动窗口/令牌桶确实无突刺。八、总结固定窗口最简单但有边界突刺滑动窗口精确但写放大令牌桶平滑且容忍突发生产组合外层固定窗口挡风暴 内层令牌桶平滑计数器 key 必带 TTL否则限流器自己成为内存泄漏源事务冲突时宁可错杀拒绝不可错放。下一篇预告流量管住了下一篇做一个高频业务——下一篇《千万玩家积分榜——ZSet 排行榜的 Go 实现 5 细节》我们处理同分排序、分页、我的排名这些最容易踩坑的细节。