redis 4.0 以后开始支持扩展模块，redis-cell 是一个用rust语言编写的基于令牌桶算法的的限流模块，提供原子性的限流功能，并允许突发流量，可以很方便的应用于分布式环境中。
令牌桶限流算法原理及步骤
令牌桶算法的原理是定义一个按一定速率产生token的桶，每次去桶中申请token，若桶中没有足够的token则申请失败，否则成功。在请求不多的情况下，桶中的token基本会饱和，此时若流量激增，并不会马上拒绝请求，所以这种算法允许一定的流量激增。
- 定义一个令牌桶，其拥有几个关键属性
- 桶容量
- 令牌产生速率
- 当前桶中令牌数
- 最近一次取（生成）令牌时间
- 从桶中申请令牌，这一步中有两个关键动作
- 根据上一次生成令牌时间到现在的时间，及生成速率计算出当前令牌桶中的令牌数
- 判断令牌桶中是否有足够的令牌，并返回结果
这几个步骤可以采用redis提供的原生命令去实现，但是，但是，但是高并发的时候数据会不一致，所以 redis-cell 将这个过程原子化，完美解决了分布式环境下数据的一致性问题。
安装方式
官方提供了安装包和源码编译两种方式，源码编译要安装rust环境，比较复杂，这里介绍安装包方式安装：
- 根据操作系统下载安装包;
- 将文件解压到redis能访问到的路径下；
- 进入 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 ，否则可以考虑细粒度的控制到每个服务节点去限流，配合相应的负载均衡策略去实现。以上为个人理解，仅供参考。
