平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“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 脚本实现令牌桶/滑动窗口，并加入坚控与自动化清理机制；

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

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