如今微服务架构大行其道本质原因是因为要降低系统的整体复杂度，将系统风险均摊到子系统从来最大化保证系统的稳定性，通过领域划分拆成不同的子系统后各个子系统能独立的开发、测试、发布，研发节奏和效率能明显提高。

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

其中限流指的是针对接口调用频率进行限制，以免超出承载上限拖垮系统。
比如：

  1. 电商秒杀场景
  2. openApi不同商户限流

常用的限流算法有：

  • 固定时间窗口限流
  • 滑动时间窗口限流
  • 漏桶限流
  • 令牌桶限流

本文主要讲解固定时间窗口限流算法。

工作原理

从某个时间点开始每次请求过来请求数+1，同时判断当前时间窗口内请求数是否超过限制，超过限制则拒绝该请求，然后下个时间窗口开始时计数器清零等待请求。

go-zero高可用-分布式限流器periodLimit - 图1

优缺点

优点

实现简单高效

缺点

固定时间窗口限流的缺点在于无法处理临界区请求突发场景。

假设每1s限流100此请求，用户在中间500ms时开始1s内发起200次请求，此时200次请求时可以全部通过的。这就和我们预期1s限流00次不合了，根源在于限流的细粒度太粗。

go-zero高可用-分布式限流器periodLimit - 图2

go-zero代码实现

core/limit/periodlimit.go

go-zero中使用redis过期时间来模拟固定时间窗口。

redis lua脚本：

  1. --KYES[1]:限流器key
  2. --ARGV[1]:qos,单位时间内最多请求次数
  3. --ARGV[2]:单位限流窗口时间
  4. --请求最大次数,等于p.quota
  5. local limit = tonumber(ARGV[1])
  6. --窗口即一个单位限流周期,这里用过期模拟窗口效果,等于p.permit
  7. local window = tonumber(ARGV[2])
  8. --请求次数+1,获取请求总数
  9. local current = redis.call("INCRBY",KYES[1],1)
  10. --如果是第一次请求,则设置过期时间并返回 成功
  11. if current == 1 then
  12.     redis.call("expire",KYES[1],window)
  13.     return 1
  14. --如果当前请求数量小于limit则返回 成功
  15. elseif current < limit then
  16.     return 1
  17. --如果当前请求数量==limit则返回 最后一次请求
  18. elseif current == limit then
  19.     return 2
  20. --请求数量>limit则返回 失败
  21. else
  22.     return 0
  23. end

固定时间窗口限流器定义

  1. type (
  2.     // PeriodOption defines the method to customize a PeriodLimit.
  3.     //go中常见的option参数模式
  4.     //如果参数非常多，推荐使用此模式来设置参数
  5.     PeriodOption func(l *PeriodLimit)
  7.     // A PeriodLimit is used to limit requests during a period of time.
  8.     //固定时间窗口限流器
  9.     PeriodLimit struct {
  10.         //窗口大小，单位s
  11.         period     int
  12.         //请求上限
  13.         quota      int
  14.         //存储
  15.         limitStore *redis.Redis
  16.         //key前缀
  17.         keyPrefix  string
  18.         //线性限流，开启此选项后可以实现周期性的限流
  19.         //比如quota=5时，quota实际值可能会是5.4.3.2.1呈现出周期性变化
  20.         align      bool
  21.     }
  22. )

注意一下align参数，align=true时请求上限将会呈现周期性的变化。
比如quota=5时实际quota可能是5.4.3.2.1呈现出周期性变化

限流逻辑

其实限流逻辑在上面的lua脚本实现了,需要注意的是返回值

  • 0：表示错误，比如可能是redis故障、过载
  • 1：允许
  • 2：允许但是当前窗口内已到达上限，如果是跑批业务的话此时可以休眠sleep一下等待下个窗口（作者考虑的非常细致）
  • 3：拒绝
  1. // Take requests a permit, it returns the permit state.
  2. // 执行限流
  3. // 注意一下返回值：
  4. // 0：表示错误，比如可能是redis故障、过载
  5. // 1：允许
  6. // 2：允许但是当前窗口内已到达上限
  7. // 3：拒绝
  8. func (h *PeriodLimit) Take(key string) (int, error) {
  9.     //执行lua脚本
  10.     resp, err := h.limitStore.Eval(periodScript, []string{h.keyPrefix + key}, []string{
  11.         strconv.Itoa(h.quota),
  12.         strconv.Itoa(h.calcExpireSeconds()),
  13.     })
  15.     if err != nil {
  16.         return Unknown, err
  17.     }
  19.     code, ok := resp.(int64)
  20.     if !ok {
  21.         return Unknown, ErrUnknownCode
  22.     }
  24.     switch code {
  25.     case internalOverQuota:
  26.         return OverQuota, nil
  27.     case internalAllowed:
  28.         return Allowed, nil
  29.     case internalHitQuota:
  30.         return HitQuota, nil
  31.     default:
  32.         return Unknown, ErrUnknownCode
  33.     }
  34. }
  1. //计算过期时间也就是窗口时间大小
  2. //如果align==true
  3. //线性限流，开启此选项后可以实现周期性的限流
  4. //比如quota=5时，quota实际值可能会是5.4.3.2.1呈现出周期性变化
  5. func (h *PeriodLimit) calcExpireSeconds() int {
  6.     if h.align {
  7.         unix := time.Now().Unix() + zoneDiff
  8.         return h.period - int(unix%int64(h.period))
  9.     }
  11.     return h.period
  12. }

资料