限流实现1

在实际业务中，经常会碰到突发流量的情况。如果公司基础架构做的不好，服务无法自动扩容缩容，在突发高流量情况下，服务会因为压力过大而崩溃。更恐怖的是，服务崩溃如同多米诺骨牌，一个服务出问题，可能影响到整个公司所有组的业务。

​ 为了减少损失，比较常用的方案是限流和熔断。本文会讲述常用的几种方法：

  • 随机拒流
  • 计数器方式
  • 基于滑动时间窗口限流
  • 漏斗算法
  • 令牌桶算法
  • Hystrix

Hystrix主要用来做熔断处理，不过从另一个维度而言，也算实现了限流的功能，就放在一起讨论了。这些方法都会用go写一个实现，鉴于自己时间有限，分三到四期写完。本期先实现随机拒流、计数器方式、基于滑动时间窗口限流。

Go使用的Gin框架，并且引入了swagger，如果大家不熟悉，可以看一下我的这三篇文章

  1. Gin源码剖析https://mp.weixin.qq.com/s/g_MQldFaMmvnhSsCIMJ7xg
  2. Gin简单实现https://mp.weixin.qq.com/s/X9pyPZU63j5FF4SDT4sHew
  3. Gin框架集成swagger过程

具体代码可以查看https://github.com/shidawuhen/asap/tree/master

代码里做了简单的单元测试和性能测试，大家可以执行如下命令查看效果

go test controller/limit/randomReject_test.go

go test -v -test.bench controller/limit/slidewindowsReject*

限流有分布式限流和单机限流两种大类，分布式限流是将集群看做整体，一般需要用到其他分布式工具，如Redis等，单机限流是将每个机器单做独立物理单元。两种方式各有利弊，分布式限流复杂度会更高一些，而且一般需要保证机器时间一致，单机限流实现相对简单，但是在扩缩容后需要更改限流的阈值。

随机拒流和基于滑动窗口的拒流，使用的是单机限流方案，技术限流使用的是分布式方案。

如下是三个方案的实现：

随机拒流

随机拒流代码最简单，也往往是最有效的。

一般的服务架构如下图所示，有一个客户端，有一个BFF层直接和客户端交互，BFF后面隐藏了公司内部的众多服务。

随机拒流一般用于客户端和BFF层之间。负责BFF层的业务组，在发现流量不可控情况下，按比例开启随机拒流，在部分影响业务的情况下，保证生产的正常运行，另外也保护了后端服务。

代码实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
package limit

import (
   "github.com/gin-gonic/gin"
   "math/rand"
   "net/http"
)

// @Tags limit
// @Summary 随机拒流
// @Produce  json
// @Success 200 {string} string "成功会返回ok"
// @Failure 502 "失败返回reject"
// @Router /limit/randomreject [get]
func RandomReject(c *gin.Context) {
   refuseRate := 200
   if refuseRate != 0 {
      temp := rand.Intn(1000)
      if temp <= refuseRate {
         c.String(http.StatusBadGateway, "reject")
         return
      }
   }
   c.String(http.StatusOK, "ok")
}

说明：refuseRate通常读取的是配置数据，通过refuseRate的值，可以控制拒流的比例。线上多次出现过大流量情况，开始随机拒流开关后，效果显著。

计数器

计数器使用分布式方案，此处用到了Redis，在本机调试的时候需要安装Redis，执行如下操作：

  1. 修改redis.conf的#requirepass foobared可设置auth，修改后启动时需要加载该文件
  2. 启动redis命令：redis-server /usr/local/Cellar/redis/6.0.1/.bottle/etc/redis.conf
  3. 登录命令：redis-cli -h 127.0.0.1 -a 111111

代码实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
package limit

import (
	"asap/aredis"
	"fmt"
	"github.com/gin-gonic/gin"
	"net/http"
	"time"
)

// @Tags limit
// @Summary 计数拒流，每秒超过指定次数会拒流掉
// @Produce  json
// @Success 200 {string} string "成功会返回ok"
// @Failure 502 "失败返回reject"
// @Router /limit/countreject [get]
func CountReject(c *gin.Context) {
	currentTime := time.Now().Unix()
	key := fmt.Sprintf("count:%d", currentTime)
	limitCount := 1
	fmt.Println(key)
	trafficCount, _ := aredis.GetRedis(aredis.BASEREDIS).Incr(key)
	if trafficCount == 1 {
		aredis.GetRedis(aredis.BASEREDIS).Expire(key, 86400)
	}
	if int(trafficCount) > limitCount {
		c.String(http.StatusOK, "reject")
		return
	}
	c.String(http.StatusOK, "ok")
}

说明：

  1. 实现计数器算法需要用到reids，这样能够确保整个服务在每秒内访问次数没有超过指定数值
  2. 使用时间戳为key
  3. 这种方案有个缺点，有可能在1s内最多有2倍的请求被处理，举个例子，在当前这一秒的后半秒，处理数量打满，在下一秒的前半秒，处理数量打满，这样在1s的时间内，处理了两倍的请求，某些极端情况下，仍然会导致服务崩溃。

当然，虽然有上面说的这个问题，不过一般而言问题不大，因为流量大多都是比较均匀的。不过有个场景需要大家关注一下，如果有用户刷接口，使用该方法会导致大量正常用户无法正常使用系统，遇到这种情况，可以使用随机方案，另外可以迅速找出用户，将其封禁，这自然也需要健壮的基础设施支持。

基于滑动时间窗口限流

计数器方法有可能导致1s内的流量超过指定阈值，使用基于滑动时间窗口限流方案可以解决这个问题。


滑动时间窗口的逻辑很简单，就是将单位时间拆分成更小的块，计算在滑动的单位时间内数值是否超过阈值。举个例子，我们将1s拆分为10小块，则每小块时间长度为100ms，假设我们设置的阈值是500/s，极端情况下，第一秒的前九个小块都没有流量，第十个小块有500流量，时间往后移动，在第二秒的第一个小块，因为和第一秒的第十个小块在一个滑动窗口内，所以会将所有流量拒掉，只有时间移动到第二秒第十个小块时，系统才能继续处理请求。

代码实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
package limit

import (
   "container/ring"
   "github.com/gin-gonic/gin"
   "net/http"
   "sync"
   "sync/atomic"
   "time"
   "fmt"
)

var (
   limitCount int = 5 // 1s限频
   limitBucket int = 10 // 滑动窗口个数
   curCount int32 = 0  // 记录限频数量
   head *ring.Ring     // 环形队列（链表）
   printRes = 0
)

func init(){
   // 初始化滑动窗口
   head = ring.New(limitBucket)
   for i := 0; i < limitBucket; i++ {
      head.Value = 0
      head = head.Next()
   }
   // 启动执行器
   go func() {
      //ms级别，limitBucket int = 10意味将每秒分为10份，每份100ms
      timer := time.NewTicker(time.Millisecond * time.Duration(1000/limitBucket))
      for range timer.C { // 定时每隔指定时间刷新一次滑动窗口数据
         //subCount的作用，是因为当移动到head的时候，意味着该head要被废弃了。所以总count的值需要减去
         //head的值，并将head的值重新赋值为0
         subCount := int32(0 - head.Value.(int))
         newCount := atomic.AddInt32(&curCount, subCount)

         arr := make([]int,limitBucket)
         for i := 0; i < limitBucket; i++ { //打印出当前每个窗口的请求数量
            arr[i] = head.Value.(int)
            head = head.Next()
         }
         if printRes == 1 {
            fmt.Println("move subCount,newCount,arr", subCount, newCount,arr)
         }
         head.Value = 0
         head = head.Next()
      }
   }()
}
// @Tags limit
// @Summary 滑动窗口计数拒流，每秒超过指定次数会拒流掉
// @Produce  json
// @Success 200 {string} string "成功会返回ok"
// @Failure 502 "失败返回reject"
// @Router /limit/slidewindowsreject [get]
func SlideWindowsReject(c *gin.Context){
   n := atomic.AddInt32(&curCount, 1)
   if n > int32(limitCount) { // 超出限频
      atomic.AddInt32(&curCount, -1) //将多增加的数据减少
      c.String(http.StatusBadGateway, "reject")
   } else {
      mu := sync.Mutex{}
      mu.Lock()
      pos := head.Prev()
      val := pos.Value.(int)
      val++
      pos.Value = val
      mu.Unlock()
      c.String(http.StatusOK, "ok")
   }
}

说明：

  1. 本算法使用go的ring实现
  2. 每次head移动，意味当前head已经过期，需要将总计数减去该head的计数，将head的值重新设置为0
  3. 在改变总计数的时候，使用了原子操作保证了了计数的准确性
  4. 在更改ring中计数的时候，需要使用锁，防止数据不一致。性能压测结果表明性能可用。
  5. 本算法使用了定时器，算是比较取巧的一种方案

资料

  1. https://www.cnblogs.com/xiangxiaolin/p/12386775.html
  2. https://jingyan.baidu.com/article/d5a880ebdbed2113f047cc4e.html 安装redis服务
  3. https://www.h3399.cn/201906/702263.html 设置auth
  4. https://blog.csdn.net/Hedon954/article/details/107146301/ Mac 上安装 Redis 和配置密码详细过程
  5. https://blog.csdn.net/gx864102252/article/details/102213616 Go实现滑动窗口限频
  6. http://docscn.studygolang.com/pkg/container/ring/
  7. 限频方案比较
  8. https://blog.csdn.net/micl200110041/article/details/82013032 Golang实现请求限流的几种办法
  9. https://blog.csdn.net/u014691098/article/details/105601511 滑动窗口实现访问频率限制
  10. 限流算法之滑动窗口法
  11. https://zhuanlan.zhihu.com/p/85166364

扫一扫，分享到微信

微信分享二维码