要确保基于 Redis+Lua 的分布式限流器的高可用与高性能，可以从 Redis 架构、Lua 脚本、降级策略、性能优化 和 运维监控 五个核心方面入手。

🛡️ 高可用：保障 Redis 稳定运行

1. Redis 部署架构

   • 主从 + 哨兵：实现故障自动切换，避免单点宕机。
   • Redis Cluster：通过分片（Sharding）实现水平扩展，提升整体吞吐量。
   • 多机房部署：同城多活或异地多活，防范机房级故障。

2. 客户端高可用配置

   • 连接池：合理配置最大连接数、最小空闲连接等，避免连接风暴。
   • 超时与重试：设置合理的 connectTimeout 和 readTimeout（如 100-500ms），并采用指数退避策略进行重试，防止雪崩。
   • 多地址配置：客户端配置多个 Redis 节点地址，自动剔除不可用节点。

3. 限流降级策略 (Fail-Safe)
   当 Redis 出现网络分区、超时等故障时，必须保证业务不被限流器拖垮。

   • Fail-Open (故障放行)：记录告警日志，但允许请求通过。适用于非核心接口，优先保证可用性。
   • Fail-Close (故障拒绝)：直接拒绝所有请求。适用于支付等核心链路，严格保护后端。
   • 本地限流降级：Redis 故障时，自动切换为 Guava RateLimiter 等本地限流器，使用保守阈值兜底。

4. Key 的过期与内存管理
   为所有限流 Key 设置合理的过期时间（如窗口时间的2倍），并使用 EXPIRE 命令防止内存泄漏。对于滑动窗口（ZSET）实现，脚本中需主动清理窗口外的旧数据。

⚡ 性能优化：榨干 Redis 性能

1. 精简 Lua 脚本

   • 逻辑简单：脚本只做计数、比较、设置过期时间等核心操作，避免复杂计算。
   • 原子性：将 GET/SET/INCR/EXPIRE 等多步操作封装在 Lua 脚本中，保证原子性，减少网络开销。

2. 优化 Key 设计与分片

   • Key 命名：采用 业务:接口:维度 的格式，如 rate_limit:order:create:{userId}，便于管理和排查。
   • Key 分片：对海量 Key（如按用户ID）进行分片，防止单个 Key 过大或热点。可使用 {service}:{userId} 的哈希标签（Hash Tag）确保同一用户的请求落到同一 Redis 节点。

3. 减少网络开销

   • Pipeline：当需要同时检查多个限流维度（如全局+用户）时，使用 Pipeline 将多个请求打包发送，减少 RTT。
   • 脚本预加载：使用 SCRIPT LOAD 加载脚本并缓存其 SHA1，后续通过 EVALSHA 调用，减少脚本传输开销。

4. 选择高效算法

   • 令牌桶：适合允许突发的场景，如接口 QPS 限制。
   • 滑动窗口：流量控制更平滑，能有效避免固定窗口的“边界突刺”问题，精度更高。

5. 部署与架构优化

   • 就近部署：将 Redis 与应用部署在同一机房或可用区，降低网络延迟。
   • 分层限流：在网关层进行粗粒度限流，应用层进行细粒度限流。这既能提前拦截流量，也能在 Redis 故障时由本地限流器提供保护。

📊 运维与监控：可观测性保障

1. 监控核心指标

   • Redis：CPU使用率、内存占用、QPS、延迟、连接数。
   • 限流器：限流触发次数（429）、拒绝率、各维度（IP/用户）的限流分布。

2. 动态配置管理
   将限流规则（如 QPS、窗口大小）存储在 Nacos、Apollo 等配置中心。当触发限流告警时，可动态调整阈值，无需重启服务。

3. 引入多级防护
   对于百万级 QPS 场景，可采用“边缘层 + 中心层 + 本地层”的多级限流架构，实现成本与精度的平衡。

🚀 核心要点速记

• 高可用：Redis 集群化 + 客户端超时重试 + 限流降级策略 (Fail-Open/Fail-Close)。
• 高性能：Lua 脚本原子化 + Key 设计分片 + Pipeline 减少网络开销 + 选择令牌桶/滑动窗口算法。

🔥 关注公众号【云技纵横】，目前正在更新分布式缓存进阶技巧和干货