Redis限流算法解析与实战教程

一、经典限流算法的深度对比与选型建议

关键差异总结

选型建议：

• 若追求极致性能且可接受“59秒+1秒”突发 → 用 固定窗口；
• 若业务对流量平滑性要求严格，如防止刷 单、抢购 → 用 滑动窗口 或 令牌桶；
• 若希望在突发情况下仍能放行一定数量请求，同时长期速率受控 → 优先选择 令牌桶；
• 若下游是数据库/文件系统等慢速资源，必须保证输入速率稳定 → 选 漏桶。

二、RedisCell 模块详解：官方推荐的“开箱即用”限流利器

为什么推荐使用 RedisCell？

命令详解（结合实例）

# 示例：用户 user123 每分钟最多 15 次请求，突发容量 15，正常速率 1次/秒
CL.THROTTLE user123 15 60 1

返回值解析：

[1, 14, 0]   # 允许，剩余令牌 14，无需等待
[0, 15, 2]   # 拒绝，剩余令牌 15，需等待 2 秒后再试

• 1: 允许请求
• 0: 拒绝请求
• remaining_tokens: 当前可用令牌数（可用于降级提示）
• delay: 如果拒绝，建议等待多少秒再尝试（单位：秒）

注意：CL.THROTTLE 的 period 是以秒为单位，但内部是以毫秒精度计算的，因此即使周期较短（如 1 秒），也能做到精确控制。

如何启用 RedisCell？

确保 Redis 版本 ≥ 4.0；

修改 redis.conf 启用模块：

loadmodule /path/to/redis-cell.so

通常安装 Redis 时会自带该模块（路径可能为 /usr/lib/redis/modules/redis-cell.so）；

启动后可通过 MODULE LIST 查看是否加载成功。

使用建议：

• 不要滥用 max_burst：虽然它提升了用户体验，但可能导致下游瞬间压力激增。
• 配合熔断机制使用：当 delay 大于阈值（如 >3 秒），应触发熔断或降级策略。
• 日志埋点：记录被限流的请求，用于分析异常流量来源。

三、工程优化与避坑指南（进阶篇）

1.原子性：必须用 Lua 脚本！

❌ 错误做法（易出并发问题）：

GET counter
IF count > limit: RETURN reject
INCR counter

→ 存在“竞态条件”，多个请求可能同时读到 count=14，导致超限。

✅ 正确做法（使用 Lua 脚本）：

-- 令牌桶逻辑（简化版）
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2]) -- 令牌生成速度（个/秒）
local now = tonumber(ARGV[3])

local bucket = redis.call('HMGET', key, 'last_time', 'tokens')
local last_time = tonumber(bucket[1]) or 0
local tokens = tonumber(bucket[2]) or capacity

local delta = math.max(0, now - last_time)
local add_tokens = delta * rate
tokens = math.min(capacity, tokens + add_tokens)

if tokens >= 1 then
    tokens = tokens - 1
    redis.call('HMSET', key, 'last_time', now, 'tokens', tokens)
    return 1
else
    return 0
end

使用方式：

EVAL "lua_script" 1 user123 10 1 1700000000

优势：所有操作在一个事务中完成，无中间状态暴露。

2.内存治理：防止“数据堆积”

常见陷阱：

• 滑动窗口使用 Zset：若不清理过期数据，会导致内存持续增长；
• 令牌桶使用 Hash：若用户过多，且未设置合理过期时间，也会造成内存泄漏；
• 漏桶使用 List：如果消费者处理慢，队列无限增长。

解决方案：

最佳实践：

# 滑动窗口：每分钟清理一次过期时间戳
SCHEDULED JOB:
    ZREMRANGEBYSCORE window_key -inf < (now - 60)

 强烈建议：将限流数据的 TTL 控制在合理范围内（如 1~2 小时），避免内存爆炸。

3.分布式环境下的限流一致性

问题：多个服务节点共享同一份 Redis，但各自缓存本地计数 → 不一致！

✅ 解决方案：

切忌：在本地内存做限流计数，除非配合 Redis 作为主源同步。

4.限流策略的可观测性 & 监控

限流不是“黑盒”，必须具备可观测性：

必须采集的关键指标：

推荐监控方式：

• 将限流返回结果写入日志（如 OpenTelemetry Trace）；
• 使用 Prometheus + Grafana 可视化限流率；
• 在网关层集成限流统计器，发送至 Metrics Server。

四、实战场景推荐组合

五、总结：构建健壮限流系统的黄金法则

附录：常用限流命令速查表

最终建议：

在生产环境中，优先使用 RedisCell，除非有特殊定制需求；

对于复杂场景，基于 Lua 脚本实现令牌桶/滑动窗口，并加入监控与自动化清理机制；

所有策略都应可配置、可观察、可降级。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论