golang常见接口限流算法的实现

发布者: 福建二哥 | 发布时间: 2025-8-14 06:48| 查看数: 86| 评论数: 0|帖子模式

常见接口限流算法

今天面试时，面试官对我之前实习时实现的限流功能很感兴趣，发起了夺命连问…
正好趁此机会好好整理一下，很棒。

常用的限流算法

固定窗口

实现思想
固定窗口的实现原理是：在指定周期内累加访问次数，当访问次数达到限制时，触发限流策略。
比如我们限制3s内的请求不超过两次，当第三次访问的时候检测到当前窗口内以处理2次，对本次进行限制。

优点：

实现简单。可以直接通过 redis 的 string 类型实现。将客户端 ip + 访问端口作为 key，访问次数作为 value，并设置过期时间。

缺点：

限流不平滑，如第2秒到第5秒的窗口内之间可以有3次请求。

代码实现
固定窗口我们可以基于 redis 设置过期时间的 string 实现。当对 redis 的操作出现 err 时，建议放行，因为限流的目的是

降低服务器的压力

复制代码

，而不是让服务器“宕机”。

var limit struct {
count int
cycle time.Duration
}
func init() {
limit.count = 2
limit.cycle = 3 * time.Second
}
func ratelimit() func(c *gin.Context) {
return func(c *gin.Context) {
// 获取客户端IP
clientIP := c.ClientIP()
// 不包括参数
path := c.Request.URL.Path
key := clientIP + path
valStr, err := rdb.Get(c, key).Result()
if err != nil {
// 根据业务处理(放行/拦截)
}
val, _ := strconv.Atoi(valStr)
if val >= limit.count {
c.AbortWithStatusJSON(http.StatusTooManyRequests, gin.H{
"code": 1,
"msg": "请求过于频繁",
})
return
}
count, err := rdb.Incr(context.Background(), key).Result()
if err != nil {
// 根据业务处理(放行/拦截)
}
if count == 1 {
err = rdb.Expire(context.Background(), key, limit.cycle).Err()
if err != nil {
// 删除key或者重试
}
}
if int(count) > limit.count {
c.AbortWithStatusJSON(http.StatusTooManyRequests, gin.H{
"code": 1,
"msg": "请求过于频繁",
})
return
}
}
}

复制代码

滑动窗口

实现思想
滑动窗口是指在每一个时间窗口内的次数都不超过限制次数。
还是以3秒内请求不超过两次为例子，当我们每次请求时，统计一下前3秒到现在次数。如果大于等于2次时，则进行拦截。

优点：

可以保证任意时间窗口内的请求次数都不超过限制。

缺点：

实现相对复杂
还是不够平滑。假如我们限制在60s 内请求20次，会存在第一秒内请求了20次，而在后面59秒内都进行拦截的情况。

代码实现
滑动窗口可以基于 reids 的 zset 实现，以请求时的时间戳作为分数。通过当前查询分数区间[ 当前时间戳 - 时间窗口 , 当前时间戳 )，可以快速统计出时间窗口内的次数。下面的代码比固定窗口的代码短的原因是因为直接将 err 忽略了（均不影响限流功能）。

var limit struct {
count int64
cycle int64 // 单位s
}
func init() {
limit.count = 2
limit.cycle = 3
}
func ratelimit() func(c *gin.Context) {
return func(c *gin.Context) {
clientIp := c.ClientIP()
path := c.Request.URL.Path
key := clientIp + path
t := time.Now().Unix()
has, _ := rdb.Exists(context.Background(), key).Result()
count, _ := rdb.ZCount(context.Background(), key, fmt.Sprintf("%d", t-limit.cycle), "+inf").Result()
if has == 0 { // 如果是第一次创建，最长时间不超过1小时
rdb.Expire(context.Background(), key, 1*time.Hour) // 从功能上来说，此处不管是否设置成功，都不影响限流功能
}
if count >= limit.count { // 超出次数，限制
c.AbortWithStatusJSON(http.StatusTooManyRequests, gin.H{
"code": 1,
"msg": "请求过于频繁",
})
return
}
rdb.ZAdd(context.Background(), key, &redis.Z{Score: float64(t), Member: strconv.Itoa(int(t))})
// 删除窗口外的数据
go func() {
memberToRemove, _ := rdb.ZRangeByScore(context.Background(), key, &redis.ZRangeBy{
Max: strconv.Itoa(int(t - limit.cycle)),
Min: "0",
}).Result()
if len(memberToRemove) > 0 {
rdb.ZRem(context.Background(), key, memberToRemove)
}
}()
}
}

复制代码

漏桶算法

实现思想
漏桶算法就像小学的游泳池加水放水问题，不管如何加水，放水的速度都是固定的。
漏桶算法的原理是将请求视为水，漏桶用来存贮这些请求。漏桶有一个固定的容量，并且底部有一个小孔，以固定的速度漏水，如果漏桶已满，超出部分的流量将被丢弃（或排队等待）。

优点：

平滑限制请求的处理速度，避免瞬间请求过多导致系统崩溃，通过桶的大小和漏出速率灵活时应不同场景。

缺点：

太平滑了，无法应对突发流量场景。

中间件
go有相关的中间件，何苦自己造轮子。

"go.uber.org/ratelimit"

复制代码

包正是基于漏桶算法实现的。
使用方式：

通过 ratelimit.New 创建限流器对象，参数为每秒允许的请求数（RPS）。
使用 Take() 方法来获取限流许可，该方法会阻塞请求知道满足限速要求。

官方示例：

import (
"fmt"
"time"
"go.uber.org/ratelimit"
)
func main() {
rl := ratelimit.New(100) // 每秒多少次
prev := time.Now()
for i := 0; i < 10; i++ {
now := rl.Take() // 平均时间
fmt.Println(i, now.Sub(prev))
prev = now
}
// Output:
// 0 0
// 1 10ms
// 2 10ms
// 3 10ms
// 4 10ms
// 5 10ms
// 6 10ms
// 7 10ms
// 8 10ms
// 9 10ms
}

复制代码

代码实现
如果是以所有的请求为粒度则定义一个全局的 ratelimit 即可。下面是以

ip+接口

复制代码

为粒度的限制，需要定义一个map存放 key 和与之对应的限流器。

import (
"github.com/gin-gonic/gin"
"go.uber.org/ratelimit"
"sync"
"time"
)
var limiters sync.Map
func ratelimitMiddleware() func(c *gin.Context) {
return func(c *gin.Context) {
clientIp := c.ClientIP()
path := c.Request.URL.Path
key := clientIp + path
var rl ratelimit.Limiter
if limiterVal, ok := limiters.Load(key); ok {
rl = limiterVal.(ratelimit.Limiter)
} else {
newLimiter := ratelimit.New(1) // 每秒只能请求1次
limiters.Store(key, newLimiter)
rl = newLimiter
go func(string) { // 简易回收key，防止limiters 无限增大
time.Sleep(1 * time.Hour)
limiters.Delete(key)
}(key)
}
rl.Take() // 超过请求次数会进行阻塞，直到放行或放弃请求
}
}

复制代码

令牌桶算法

实现思想
令牌桶（Token Bucket）算法与漏桶十分相似，不过前者是服务端产生“水”，后者是服务端消费“水”。
令牌桶算法是指在固定时间间隔内向“桶”中添加“令牌”，桶满则暂时不放。请求在处理前需要从桶中获取令牌。如果桶中有足够的令牌，请求被处理；否则，请求被拒绝或等待。

中间件
基于此算法实现的中间件有：

github.com/juju/ratelimit

复制代码

、

golang.org/x/time/rate

复制代码

等。
下面简单说一下

time/rate

复制代码

的使用。
声明一个限流器

limiter := rate.NewLimiter(10, 2)

复制代码

第一个参数代表每秒向令牌桶中产生多少token。第二个参数代表令牌桶的大小，且初始状态下令牌桶是满的。
消费Token
Wait、WaitN

func (lim *Limiter) Wait(ctx context.Context) (err error)
func (lim *Limiter) WaitN(ctx context.Context, n int) (err error)

复制代码

Wait实际上就是

WaitN(context.Background(),1)

复制代码

。当桶内 Token 数组不足（小于N），那么Wait方法将会阻塞一段时间，直至Token满足条件。如果充足则直接返回。
Allow、AllowN
Allow与Wait十分相似，都是用来消费Token，区别是当桶中Token数量不足时，前者立即返回，后者阻塞至满足条件。

func (lim *Limiter) Allow() bool
func (lim *Limiter) AllowN(now time.Time, n int) bool

复制代码

Allow 实际上是 AllowN(time.Now(),1)。
AllowN方法表示，截止到当前某一时刻，目前桶中数目是否至少为n个，满足则返回true，同时从桶中消费 n 个 token。反之返回不消费 Token，false。
通常应对这样的线上场景，如果请求速率过快，就直接丢弃到某些请求。
Reserver、ReserveN
官方提供的限流器有阻塞等待式的 Wait，也有直接判断方式的 Allow，还有提供了自己维护预留式的，但核心的实现都是下面的 reserveN 方法。

func (lim *Limiter) Reserve() *Reservation
func (lim *Limiter) ReserveN(now time.Time, n int) *Reservation

复制代码

当调用完成后，无论 Token 是否充足，都会返回一个

*Reservation

复制代码

对象。
你可以调用该对象的

Delay()

复制代码

方法，该方法返回了需要等待的时间。如果等待时间为0，则说明不用等待。必须等到等待时间结束之后，才能进行接下来的工作。
如果不想等待，可以调用

Cancel()

复制代码

方法，该方法会将 Token 归还。
代码实现
下面还是以

Ip + path

复制代码

为粒度进行限制，和令牌桶差不多。

func ratelimitMiddleware() func(gin.Context) {
return func(c gin.Context) {
client := c.ClientIP()
path := c.Request.URL.Path
key := client + path
var rl *rate.Limiter
if limitersVal, ok := limiters.Load(key); ok {
rl = limitersVal.(*rate.Limiter)
} else {
newLimiter := rate.NewLimiter(1, 10)
limiters.Store(key, newLimiter)
rl = newLimiter
go func(string2 string) {
time.Sleep(1 * time.Second)
limiters.Delete(key)
}(key)
}
if !rl.Allow() {
c.AbortWithStatusJSON(http.StatusTooManyRequests, gin.H{
"code": 1,
"msg": "请求过于频繁",
})
}
}
}

复制代码

小结

固定窗口计数器算法:
- 优点
  - 实现简单，易于理解。
  - 可以精确控制每个窗口期内的请求数量。
- 缺点
  - 无法应对短时间内的请求高峰，可能导致请求在窗口切换时突然增加，造成瞬时压力。
  - 无法平滑处理请求，可能导致用户体验不佳。
滑动窗口算法:
- 优点
  - 相对于固定窗口算法，可以更平滑地处理请求，减少瞬时压力。
  - 可以更灵活地应对请求的波动。
- 缺点
  - 实现相对复杂，需要维护多个计数器。
  - 可能会因为窗口滑动导致计数器更新的开销。
漏桶算法:
- 优点
  - 实现简单，易于控制数据的输出速率。
  - 可以平滑处理请求，避免瞬时压力。
- 缺点
  - 无法应对突发请求，可能导致请求长时间等待。
  - 处理速度固定，不够灵活。
令牌桶算法:
- 优点
  - 可以控制平均传输速率，同时允许一定程度的突发请求。
  - 灵活性高，适用于请求速率不均匀的场景。
- 缺点
  - 实现相对复杂，需要维护令牌的生成和消耗。
  - 需要合理设置令牌的生成速率和桶的大小，否则可能无法达到预期的限流效果。

到此这篇关于golang常见接口限流算法的实现的文章就介绍到这了,更多相关golang 接口限流内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

来源：互联网
免责声明：如果侵犯了您的权益，请联系站长（1277306191@qq.com），我们会及时删除侵权内容，谢谢合作！

本帖子中包含更多资源

您需要登录才可以下载或查看，没有账号？立即注册

golang常见接口限流算法的实现

本帖子中包含更多资源

最新评论

新人须知

常见问题

维权申诉

关注微博

扫描微信

关于合作

通讯联系