要确保基于 Redis+Lua 的分布式限流器的高可用与高性能,可以从Redis 架构、Lua 脚本、降级策略、性能优化和运维监控五个核心方面入手。
🛡️ 高可用:保障 Redis 稳定运行
Redis 部署架构
- 主从 + 哨兵:实现故障自动切换,避免单点宕机。
- Redis Cluster:通过分片(Sharding)实现水平扩展,提升整体吞吐量。
- 多机房部署:同城多活或异地多活,防范机房级故障。
客户端高可用配置
- 连接池:合理配置最大连接数、最小空闲连接等,避免连接风暴。
- 超时与重试:设置合理的
connectTimeout和readTimeout(如 100-500ms),并采用指数退避策略进行重试,防止雪崩。 - 多地址配置:客户端配置多个 Redis 节点地址,自动剔除不可用节点。
限流降级策略 (Fail-Safe)
当 Redis 出现网络分区、超时等故障时,必须保证业务不被限流器拖垮。- Fail-Open (故障放行):记录告警日志,但允许请求通过。适用于非核心接口,优先保证可用性。
- Fail-Close (故障拒绝):直接拒绝所有请求。适用于支付等核心链路,严格保护后端。
- 本地限流降级:Redis 故障时,自动切换为 Guava RateLimiter 等本地限流器,使用保守阈值兜底。
Key 的过期与内存管理
为所有限流 Key 设置合理的过期时间(如窗口时间的2倍),并使用EXPIRE命令防止内存泄漏。对于滑动窗口(ZSET)实现,脚本中需主动清理窗口外的旧数据。
⚡ 性能优化:榨干 Redis 性能
精简 Lua 脚本
- 逻辑简单:脚本只做计数、比较、设置过期时间等核心操作,避免复杂计算。
- 原子性:将
GET/SET/INCR/EXPIRE等多步操作封装在 Lua 脚本中,保证原子性,减少网络开销。
优化 Key 设计与分片
- Key 命名:采用
业务:接口:维度的格式,如rate_limit:order:create:{userId},便于管理和排查。 - Key 分片:对海量 Key(如按用户ID)进行分片,防止单个 Key 过大或热点。可使用
{service}:{userId}的哈希标签(Hash Tag)确保同一用户的请求落到同一 Redis 节点。
- Key 命名:采用
减少网络开销
- Pipeline:当需要同时检查多个限流维度(如全局+用户)时,使用 Pipeline 将多个请求打包发送,减少 RTT。
- 脚本预加载:使用
SCRIPT LOAD加载脚本并缓存其 SHA1,后续通过EVALSHA调用,减少脚本传输开销。
选择高效算法
- 令牌桶:适合允许突发的场景,如接口 QPS 限制。
- 滑动窗口:流量控制更平滑,能有效避免固定窗口的“边界突刺”问题,精度更高。
部署与架构优化
- 就近部署:将 Redis 与应用部署在同一机房或可用区,降低网络延迟。
- 分层限流:在网关层进行粗粒度限流,应用层进行细粒度限流。这既能提前拦截流量,也能在 Redis 故障时由本地限流器提供保护。
📊 运维与监控:可观测性保障
监控核心指标
- Redis:CPU使用率、内存占用、QPS、延迟、连接数。
- 限流器:限流触发次数(429)、拒绝率、各维度(IP/用户)的限流分布。
动态配置管理
将限流规则(如 QPS、窗口大小)存储在 Nacos、Apollo 等配置中心。当触发限流告警时,可动态调整阈值,无需重启服务。引入多级防护
对于百万级 QPS 场景,可采用“边缘层 + 中心层 + 本地层”的多级限流架构,实现成本与精度的平衡。
🚀 核心要点速记
- 高可用:Redis 集群化 + 客户端超时重试 + 限流降级策略 (Fail-Open/Fail-Close)。
- 高性能:Lua 脚本原子化 + Key 设计分片 + Pipeline 减少网络开销 + 选择令牌桶/滑动窗口算法。