如果你写一个 bug 管理系统，用了这个 PeriodLimit 你就能够限度每个测试人员每天只能给你提一个 bug。工作是不是就轻松很多了？:P

现在微服务架构大行其道实质起因是因为要升高零碎的整体复杂度，将零碎危险均摊到子系统从而最大化保证系统的稳定性，通过畛域划分拆成不同的子系统后各个子系统能独立的开发、测试、公布，研发节奏和效率能明显提高。

但同时也带来了问题，比方：调用链路过长，部署架构复杂度晋升，各种中间件须要反对分布式场景。为了确保微服务的失常运行，服务治理就不可或缺了，通常包含：限流，降级，熔断。

其中限流指的是针对接口调用频率进行限度，免得超出承载下限拖垮零碎。比方：

  1. 电商秒杀场景
  2. API 针对不同商户限流

罕用的限流算法有：

  • 固定工夫窗口限流
  • 滑动工夫窗口限流
  • 漏桶限流
  • 令牌桶限流

本文次要解说固定工夫窗口限流算法，次要的应用场景比方：

  • 每个手机号每天只能发5条验证码短信
  • 每个用户每小时只能间断尝试3次明码
  • 每个会员每天只能领3次福利

工作原理

从某个工夫点开始每次申请过去申请数+1，同时判断以后工夫窗口内申请数是否超过限度，超过限度则回绝该申请，而后下个工夫窗口开始时计数器清零期待申请。

优缺点

长处

实现简略高效，特地适宜用来限度比方一个用户一天只能发10篇文章、只能发送5次短信验证码、只能尝试登录5次等场景，理论业务中此类场景十分多见。

毛病

固定工夫窗口限流的毛病在于无奈解决临界区申请突发场景。

假如每 1s 限流 100 次申请，用户在两头 500ms 时开始 1s 内发动 200 次申请，此时 200 次申请是能够全副通过的。这就和咱们预期 1s 限流 100 次不合了，本源在于限流的细粒度太粗。

go-zero 代码实现

core/limit/periodlimit.go

go-zero 中应用 redis 过期工夫来模仿固定工夫窗口。

redis lua 脚本：
-- KYES[1]:限流器key-- ARGV[1]:qos,单位工夫内最多申请次数-- ARGV[2]:单位限流窗口工夫-- 申请最大次数,等于p.quotalocal limit = tonumber(ARGV[1])-- 窗口即一个单位限流周期,这里用过期模仿窗口成果,等于p.permitlocal window = tonumber(ARGV[2])-- 申请次数+1,获取申请总数local current = redis.call("INCRBY",KYES[1],1)-- 如果是第一次申请,则设置过期工夫并返回 胜利if current == 1 then  redis.call("expire",KYES[1],window)  return 1-- 如果以后申请数量小于limit则返回 胜利elseif current < limit then  return 1-- 如果以后申请数量==limit则返回 最初一次申请elseif current == limit then  return 2-- 申请数量>limit则返回 失败else  return 0end
固定工夫窗口限流器定义
type (  // PeriodOption defines the method to customize a PeriodLimit.  // go中常见的option参数模式  // 如果参数十分多，举荐应用此模式来设置参数  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    // 线性限流，开启此选项后能够实现周期性的限流    // 比方quota=5时，quota理论值可能会是5.4.3.2.1呈现出周期性变动    align      bool  })

留神一下 align 参数，align=true 时申请下限将会出现周期性的变动。
比方quota=5时理论quota可能是5.4.3.2.1呈现出周期性变动

限流逻辑

其实限流逻辑在下面的 lua 脚本实现了,须要留神的是返回值

  • 0：示意谬误，比方可能是 redis 故障、过载
  • 1：容许
  • 2：容许然而以后窗口内已达到下限，如果是跑批业务的话此时能够休眠 sleep 一下期待下个窗口（作者思考的十分粗疏）
  • 3：回绝
// Take requests a permit, it returns the permit state.// 执行限流// 留神一下返回值：// 0：示意谬误，比方可能是redis故障、过载// 1：容许// 2：容许然而以后窗口内已达到下限// 3：回绝func (h *PeriodLimit) Take(key string) (int, error) {  // 执行lua脚本  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  }}

这个固定窗口限流可能用来限度比方一个用户一天只能发送5次验证码短信，此时咱们就须要跟中国时区对应(GMT+8)，并且其实限流工夫应该从零点开始，此时咱们须要额定对齐（设置 align 为 true）。

// 计算过期工夫也就是窗口工夫大小// 如果align==true// 线性限流，开启此选项后能够实现周期性的限流// 比方quota=5时，quota理论值可能会是5.4.3.2.1呈现出周期性变动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-zero 并 star 反对咱们！

微信交换群

关注『微服务实际』公众号并点击 交换群 获取社区群二维码。