要确保基于 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 减少网络开销 + 选择令牌桶/滑动窗口算法。
