1. Redis集群下的固定窗口限流方案设计
在分布式系统中，限流是保护服务稳定的重要手段。固定窗口限流作为最基础的限流算法之一，其核心思想是在固定时间窗口内对请求次数进行计数，当计数超过阈值时拒绝后续请求。在Redis集群环境下实现这一方案，需要考虑数据一致性和高可用性问题。
1.1 固定窗口限流算法原理
固定窗口算法将时间划分为固定长度的窗口（如1秒、1分钟），每个窗口独立计数。当请求到达时：
- 获取当前时间对应的窗口起始时间戳
- 对Redis中该窗口的计数器执行INCR操作
- 比较计数值与预设阈值决定是否放行
这种算法的优点是实现简单，内存占用固定；缺点是窗口切换时可能出现流量突增，且无法应对突发流量。
1.2 Redis集群下的特殊考量
在集群环境中，我们需要解决两个核心问题：
- 数据分片问题：Redis集群采用分片存储，如何确保限流计数器的原子性操作
- 高可用问题：当部分节点故障时，如何保证限流功能持续可用
解决方案是使用Redis的哈希标签（hash tag）确保相关key分配到同一分片，同时配合集群的自动故障转移机制。
2. 核心实现方案
2.1 键设计规范
采用以下键命名方案：
ratelimit:{resource}:{window_start_timestamp}其中：
{resource}表示被限流的资源标识{window_start_timestamp}是窗口开始的时间戳（如除以窗口长度后取整）
使用花括号包裹resource部分确保相同资源的计数器落在同一分片：
ratelimit:{user_api}/v1/getData:16590132002.2 Lua脚本实现原子操作
为保证原子性，使用Lua脚本实现计数和判断逻辑：
local key = KEYS[1] local limit = tonumber(ARGV[1]) local window = tonumber(ARGV[2]) local current = redis.call('GET', key) or 0 if tonumber(current) >= limit then return 0 else redis.call('INCR', key) redis.call('EXPIRE', key, window * 2) -- 设置足够长的过期时间 return 1 end2.3 集群配置要点
哈希槽分配检查：
redis-cli --cluster check 127.0.0.1:6379重试机制：
- 对MOVED/ASK错误自动重定向
- 设置合理的连接超时和重试次数
客户端配置（以Jedis为例）：
JedisCluster jedis = new JedisCluster( new HostAndPort("127.0.0.1", 6379), 1000, // 连接超时 1000, // 读写超时 3, // 最大重试 "password" );
3. 高可用保障措施
3.1 多级降级策略
- 本地缓存计数：在应用层维护短期计数作为第一道防线
- 熔断机制：当Redis不可用时启用本地限流模式
- 动态阈值调整：根据系统负载自动调整限流阈值
3.2 监控与告警
关键监控指标：
- 限流触发次数
- Redis节点健康状态
- 请求延迟百分位值
推荐使用Prometheus+Granfa监控体系：
# Prometheus配置示例 scrape_configs: - job_name: 'redis_cluster' static_configs: - targets: ['redis-node1:9121', 'redis-node2:9121']4. 性能优化实践
4.1 批量处理技巧
对于高频访问的资源，可以采用批处理方式：
-- 批量获取10个资源的限流状态 local results = {} for i=1,10 do local key = KEYS[i] -- ...限流逻辑... results[i] = ... end return results4.2 内存优化
- 使用
INCRBY替代多次INCR：redis.call('INCRBY', key, #requests) - 设置合理的过期时间：
redis.call('EXPIRE', key, math.floor(window*1.5))
4.3 热点数据分离
对高频访问的限流计数器：
- 使用单独的Redis实例
- 采用本地缓存+异步刷新的策略
- 考虑使用Redis的Pipeline减少网络开销
5. 生产环境常见问题
5.1 时钟同步问题
在分布式环境下，各节点时钟不同步会导致窗口计算偏差。解决方案：
- 使用NTP服务保持时钟同步
- 在Redis中存储窗口开始时间：
local window_start = redis.call('GET', key..':start') or 0 if current_time - window_start > window then redis.call('SET', key..':start', current_time) redis.call('SET', key, 0) end
5.2 雪崩效应预防
当大量请求同时到达时可能造成Redis压力激增。应对措施：
- 在应用层添加随机延迟
- 使用令牌桶算法平滑流量
- 分级启用限流策略
5.3 集群扩容影响
扩容导致哈希槽重新分配时：
- 提前规划好扩容窗口期
- 使用
CLUSTER SETSLOT命令手动迁移关键槽位 - 在客户端实现自动重试逻辑
6. 与其他限流算法对比
6.1 固定窗口 vs 滑动窗口
| 特性 | 固定窗口 | 滑动窗口 |
|---|---|---|
| 精度 | 较低 | 较高 |
| 内存 | 固定 | 可能增长 |
| 实现 | 简单 | 复杂 |
| 适合场景 | 粗粒度控制 | 精细控制 |
6.2 固定窗口 vs 令牌桶
| 特性 | 固定窗口 | 令牌桶 |
|---|---|---|
| 突发流量 | 不支持 | 支持 |
| 平滑度 | 差 | 好 |
| 系统开销 | 低 | 中等 |
在实际生产中，可以根据业务特点组合使用多种算法。例如对API网关采用滑动窗口，对后台任务采用固定窗口。
7. 最佳实践建议
键过期策略：设置足够长的过期时间（建议窗口长度的2倍），防止因过期导致计数不准确
阈值设定：基于实际压力测试结果设置阈值，一般建议：
阈值 = 单机QPS * 节点数 * 安全系数(0.7)日志记录：详细记录被拒绝的请求，包括：
- 资源标识
- 请求时间
- 当前计数
动态配置：将限流阈值存储在配置中心，支持热更新
压测方案：使用JMeter等工具模拟突发流量，验证限流效果：
jmeter -n -t test_plan.jmx -l result.jtl
在电商大促场景中，我们曾用这套方案成功抵御了每秒10万+的突发流量。关键点在于：
- 提前做好容量规划
- 实施多级降级策略
- 建立完善的监控体系
当Redis集群出现故障时，系统会自动切换到本地限流模式，虽然精度下降但保证了基本可用性。事后分析显示，这种设计避免了因缓存层故障导致的全站雪崩。
