由于Redis是直接操作内存的，所以性能很高，因此在大多数情况下，相较于Mysql，我们都会优先访问Redis，不过假设同一时间内打入Reids的请求过多，这就可能会导致Redis出现宕机的可能性，为了避免这种问题出现，Redis设计了分布式限流算法来限制同一时间段内的请求个数。像这种调优型的问题，在面试中是常常出现的。
Redis的限流算法一共有四种，分别是计数器，滑动窗口，漏桶以及令牌桶算法，接下来今天小编就来和大家分享一下这四种算法的知识点。
1.令牌桶算法
令牌桶算法，就是通过一个以固定速率生成令牌token的桶，桶的容量固定，使得只有获取到token的线程请求能够被处理而假设没有获取到token的线程进行请求，则会将请求拒绝，会有一个补充者以一定速率补充一定量的令牌，假设补充的令牌超过了桶的上限，则将多余的令牌丢弃。
令牌桶的算法大致有以下几个特点：
-
生成：以固定速率往桶里放令牌（桶满则丢弃）
-
消费：每个请求需要获取一个令牌，有令牌则通过，无则拒绝
-
突发：桶内有积累令牌时，可应对突发流量
接下来是一段代码实现
java
-- 令牌桶限流脚本
local key = KEYS[1] -- 桶的key
local rate = tonumber(ARGV[1]) -- 每秒产生令牌数
local capacity = tonumber(ARGV[2]) -- 桶容量
local now = tonumber(ARGV[3]) -- 当前时间戳（毫秒）
local requested = tonumber(ARGV[4]) -- 需要的令牌数
-- 获取当前状态
local bucket = redis.call('HMGET', key, 'tokens', 'last_time')
local tokens = tonumber(bucket[1]) or capacity
local last_time = tonumber(bucket[2]) or now
-- 计算新增令牌
local delta = math.max(0, now - last_time)
local added_tokens = delta * rate / 1000 -- 转换为毫秒
tokens = math.min(capacity, tokens + added_tokens)
-- 判断是否足够
local allowed = tokens >= requested
if allowed then
tokens = tokens - requested
end
-- 更新状态
redis.call('HMSET', key, 'tokens', tokens, 'last_time', now)
redis.call('EXPIRE', key, 60) -- 设置过期时间
return allowed and 1 or 02.漏桶算法
与令牌桶算法不同的是，漏桶算法是通过一个固定容量的桶去接受请求，并通过固定速率去逐一解决请求，假设当请求进入桶的时候超出了桶的容量上限则丢弃请求。
漏桶算法大致有以下几个特点：
-
流入：请求以任意速率进入（如果桶未满）
-
流出 ：请求以固定速率处理（漏出）
-
桶满：新请求被拒绝或等待
3.计数器算法
计数器算法相对比较简单，就是在固定时间窗口内统计请求次数，超过阈值则拒绝。
计数器算法大致有以下几个特点：
-
实现简单，性能高
-
临界问题窗口边界突发流量
-
无法平滑限流
4.滑动窗口算法
滑动窗口算法将时间窗口划分为多个小格子，每次滑动时丢弃过期格子的计数，解决临界问题。
滑动窗口算法大致有以下几个特点：
-
解决临界问题，精度可控（格子越小越精确），可获取请求分布
-
内存占用较大，实现相对复杂，需要存储每个请求的时间戳
今天的分享就到这里了，希望这篇博客能给你一些帮助，让你对关于Redis的分布式限流算法的问题得到进一步的提升，在面试的时候能从容面对面试官。