分布式限流 redis-cell

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

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

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

1. 定义一个令牌桶，其拥有几个关键属性

• 桶容量
• 令牌产生速率
• 当前桶中令牌数
• 最近一次取（生成）令牌时间

2. 从桶中申请令牌，这一步中有两个关键动作

• 根据上一次生成令牌时间到现在的时间，及生成速率计算出当前令牌桶中的令牌数
• 判断令牌桶中是否有足够的令牌，并返回结果

这几个步骤可以采用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 ，否则可以考虑细粒度的控制到每个服务节点去限流，配合相应的负载均衡策略去实现。以上为个人理解，仅供参考。