分布式限流 redis-cell

redis 4.0 以后开始支持扩展模块,redis-cell 是一个用rust语言编写的基于令牌桶算法的的限流模块,提供原子性的限流功能,并允许突发流量,可以很方便的应用于分布式环境中。

令牌桶限流算法原理及步骤

令牌桶算法的原理是定义一个按一定速率产生token的桶,每次去桶中申请token,若桶中没有足够的token则申请失败,否则成功。在请求不多的情况下,桶中的token基本会饱和,此时若流量激增,并不会马上拒绝请求,所以这种算法允许一定的流量激增。

  1. 定义一个令牌桶,其拥有几个关键属性
  • 桶容量
  • 令牌产生速率
  • 当前桶中令牌数
  • 最近一次取(生成)令牌时间
  1. 从桶中申请令牌,这一步中有两个关键动作
  • 根据上一次生成令牌时间到现在的时间,及生成速率计算出当前令牌桶中的令牌数
  • 判断令牌桶中是否有足够的令牌,并返回结果

这几个步骤可以采用redis提供的原生命令去实现,但是,但是,但是高并发的时候数据会不一致,所以 redis-cell 将这个过程原子化,完美解决了分布式环境下数据的一致性问题。

安装方式

官方提供了安装包和源码编译两种方式,源码编译要安装rust环境,比较复杂,这里介绍安装包方式安装:

  1. 根据操作系统下载安装包;
  2. 将文件解压到redis能访问到的路径下;
  3. 进入 redis-cli,执行命令module load /path/to/libredis_cell.so;

执行完以上步骤就可以使用其提供的限流功能了。

命令

该模块只提供了一个命令:CL.THROTTLE

参数说明

CL.THROTTLE test 100 400 60 3

test: redis key

100: 官方叫max_burst,没理解什么意思,其值为令牌桶的容量 - 1, 首次执行时令牌桶会默认填满

400: 与下一个参数一起,表示在指定时间窗口内允许访问的次数

60: 指定的时间窗口,单位:秒

3: 表示本次要申请的令牌数,不写则默认为 1

以上命令表示从一个初始值为100的令牌桶中取3个令牌,该令牌桶的速率限制为400次/60秒

返回值说明

127.0.0.1:6379> CL.THROTTLE test 100 400 60 3
1) (integer) 0
2) (integer) 101
3) (integer) 98
4) (integer) -1
5) (integer) 0

1: 是否成功,0:成功,1:拒绝

2: 令牌桶的容量,大小为初始值+1

3: 当前令牌桶中可用的令牌

4: 若请求被拒绝,这个值表示多久后才令牌桶中会重新添加令牌,单位:秒,可以作为重试时间

5: 表示多久后令牌桶中的令牌会存满

示例

下面以一个速率稍慢一点的令牌桶来演示一下,连续快速执行以下命令:

127.0.0.1:6379> CL.THROTTLE test1 10 5 60 3
1) (integer) 0
2) (integer) 11
3) (integer) 8
4) (integer) -1
5) (integer) 36
127.0.0.1:6379> CL.THROTTLE test1 10 5 60 3
1) (integer) 0
2) (integer) 11
3) (integer) 5
4) (integer) -1
5) (integer) 71
127.0.0.1:6379> CL.THROTTLE test1 10 5 60 3
1) (integer) 0
2) (integer) 11
3) (integer) 2
4) (integer) -1
5) (integer) 106
127.0.0.1:6379> CL.THROTTLE test1 10 5 60 3
1) (integer) 1
2) (integer) 11
3) (integer) 2
4) (integer) 10
5) (integer) 106

通过命令可以看到,每次从桶中取出3个令牌,当桶中令牌不足时,请求被拒绝。


思考:

因为业务的原因(周末请求比平时多),最近公司的服务一到周末就嗝屁,消防群里忙的不可开交,有几次跟redis有关系导致服务雪崩,后来架构那边出建议各个业务组减少对其他服务的依赖。

一方面其他服务都不可靠,一方面一些核心业务不能做降级,并且公司日益壮大,服务太多,出错排查的成本太大,基于这些原因,能在自己服务内解决的就不要依赖其他服务。

个人觉得,项目不大的,维护成本不高的话,可以采用 直接使用 redsi-cell ,否则可以考虑细粒度的控制到每个服务节点去限流,配合相应的负载均衡策略去实现。以上为个人理解,仅供参考。