当系统处理能力有限，如何组织计划外的请求对系统施压。首先我们先看下一些简单的限流策略，防止暴力攻击。比如要对IP访问，没5s只能访问10次，超过进行拦截。
如上图，一般使用滑动窗口来统计区间时间内的访问次数。
使用 zset 记录 IP 访问次数，每个 IP 通过 key 保存下来，score 保存当前时间戳，value 唯一用时间戳或者UUID来实现
代码实现
执行结果 访问第1次, 结果：允许访问 访问第2次, 结果：允许访问 访问第3次, 结果：允许访问 访问第4次, 结果：允许访问 访问第5次, 结果：允许访问 访问第6次, 结果：限制访问 访问第7次, 结果：限制访问 ... ...
缺点：要记录时间窗口所有的行为记录，量很大，比如，限定60s内不能超过100万次这种场景，不太适合这样限流，因为会消耗大量的储存空间。
二、漏斗限流 基本原理 漏斗的容量是限定的，如果满了，就装不进去了。 如果将漏嘴放开，水就会往下流，流走一部分之后，就又可以继续往里面灌水。 如果漏嘴流水的速率大于灌水的速率，那么漏斗永远都装不满。 如果漏嘴流水速率小于灌水的速率，那么一旦漏斗满了，灌水就需要暂停并等待漏斗腾空。示例代码
执行结果 访问第1次, 结果：允许访问 # 第1次，容量剩余2，执行后1 访问第2次, 结果：允许访问 # 第2次，容量剩余1，执行后0 访问第3次, 结果：允许访问 # 第3次，由于过了2s, 漏斗流水剩余1个空间，所以容量剩余1，执行后0 访问第4次, 结果：限制访问 # 第4次，过了1s, 剩余空间小于1， 容量剩余0 访问第5次, 结果：允许访问 # 第5次，由于过了2s, 漏斗流水剩余1个空间，所以容量剩余1，执行后0 访问第6次, 结果：限制访问 # 以此类推... 访问第7次, 结果：允许访问 访问第8次, 结果：限制访问 访问第9次, 结果：允许访问 访问第10次, 结果：限制访问
我们观察 Funnel 对象的几个字段，我们发现可以将 Funnel 对象的内容按字段存储到一个 hash 结构中，灌水的时候将 hash 结构的字段取出来进行逻辑运算后，再将新值回填到 hash 结构中就完成了一次行为频度的检测。
但是有个问题，我们无法保证整个过程的原子性。从 hash 结构中取值，然后在内存里运算，再回填到 hash 结构，这三个过程无法原子化，意味着需要进行适当的加锁控制。而一旦加锁，就意味着会有加锁失败，加锁失败就需要选择重试或者放弃。 如果重试的话，就会导致性能下降。如果放弃的话，就会影响用户体验。同时，代码的复杂度也跟着升高很多。这真是个艰难的选择，我们该如何解决这个问题呢？Redis-Cell 救星来了！
Redis-CellRedis 4.0 提供了一个限流 Redis 模块，它叫 redis-cell。该模块也使用了漏斗算法，并提供了原子的限流指令。 该模块只有1条指令cl.throttle，它的参数和返回值都略显复杂，接下来让我们来看看这个指令具体该如何使用。
15 : 15 capacity 这是漏斗容量 30 60 : 30 operations / 60 seconds 这是漏水速率 1 : need 1 quota (可选参数，默认值也是1)
在执行限流指令时，如果被拒绝了，就需要丢弃或重试。cl.throttle 指令考虑的非常周到，连重试时间都帮你算好了，直接取返回结果数组的第四个值进行 sleep 即可，如果不想阻塞线程，也可以异步定时任务来重试。
参考来源《Redis深度历险 核心原理与应用实践》_钱文品
到此这篇关于Redis限流的几种实现的文章就介绍到这了,更多相关Redis限流内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
