Spring Boot与Redis实现高并发限流方案实战

1. 为什么我们需要限流方案上周五凌晨两点我被一阵急促的报警短信惊醒。打开监控一看某个核心接口的QPS突然从平时的200飙升到8000整个服务集群已经处于崩溃边缘。紧急扩容后我开始排查问题根源——原来是有个新上线的爬虫程序没有做请求间隔控制对我们的API进行了疯狂调用。这种场景在分布式系统中太常见了恶意爬虫、用户误操作、促销活动带来的流量洪峰...如果没有合理的限流措施再强大的服务器也会被瞬间击垮。今天我就结合Spring Boot和Redis分享四种经过生产验证的限流方案特别是最后那个滑动窗口算法在多次大促活动中帮我扛住了百万级流量。2. 基础版计数器限流2.1 实现原理计数器限流是最简单直观的方案。其核心思想是在固定时间窗口内比如1分钟统计请求次数超过阈值就拒绝服务。用Redis实现时我们可以使用INCR命令原子性递增计数器。// 伪代码示例 public boolean tryAcquire(String key, int limit, int timeout) { Long count redisTemplate.opsForValue().increment(key); if (count 1) { redisTemplate.expire(key, timeout, TimeUnit.SECONDS); } return count limit; }2.2 生产环境问题但在实际使用中我发现两个致命缺陷边界突刺问题假设限流每分钟100次如果在59秒时突然涌入100请求下一秒又进来100请求实际上两秒内处理了200请求完全击穿限流保护内存占用高每个接口每个用户都需要独立计数器当用户量暴涨时Redis内存消耗会呈线性增长提示计数器方案仅适用于对精度要求不高的内部系统生产环境慎用3. 进阶版漏桶算法3.1 算法模型漏桶算法模拟了一个固定容量的桶请求像水一样流入桶中而桶底以恒定速率漏出请求进行处理。当桶满时新请求会被丢弃或排队。Redis实现可以用LIST数据结构public boolean tryAcquire(String key, int capacity, int rate) { long now System.currentTimeMillis(); // 移除已处理的请求 redisTemplate.opsForList().trim(key, -capacity, -1); // 获取当前队列长度 Long size redisTemplate.opsForList().size(key); if (size capacity) { redisTemplate.opsForList().rightPush(key, now); return true; } return false; }3.2 实战优化点在我的电商项目中对漏桶算法做了三点改进动态容量调整根据CPU负载自动调整桶容量负载高时缩小容量优先级队列将VIP用户的请求放入高优先级队列预热机制系统启动时缓慢增加处理速率避免冷启动击穿// 动态调整示例 public void adjustCapacity(String key, double loadAvg) { int newCapacity (int)(baseCapacity * (1 / loadAvg)); redisTemplate.opsForValue().set(key_capacity, newCapacity); }4. 高性能版令牌桶算法4.1 原理对比令牌桶与漏桶的主要区别在于漏桶强制恒定输出速率令牌桶允许一定程度的突发流量Redis实现方案-- Lua脚本保证原子性 local tokens tonumber(redis.call(get, KEYS[1]) or 0) local capacity tonumber(ARGV[1]) local rate tonumber(ARGV[2]) local now tonumber(ARGV[3]) local requested tonumber(ARGV[4]) local new_tokens math.min(capacity, tokens (now - last_time) * rate) if new_tokens requested then redis.call(set, KEYS[1], new_tokens - requested) return true end return false4.2 参数调优经验在API网关中应用令牌桶时这几个参数需要特别注意参数推荐值说明capacity突发QPS×2例如预计突发1000QPS设2000rate平均QPS×1.2留20%余量timeout500ms获取令牌最长等待时间实测发现令牌桶算法特别适合秒杀场景。去年双十一我们通过动态调整令牌生成速率成功将下单接口的异常率控制在0.5%以下。5. 终极方案滑动窗口限流5.1 为什么选择滑动窗口前三种方案都有明显缺陷计数器边界问题严重漏桶无法应对突发流量令牌桶实现复杂滑动窗口通过将时间切分为多个小格子每个格子独立计数完美解决了边界问题。下面是我们的生产级实现public boolean slidingWindow(String key, int windowSize, int limit) { long now System.currentTimeMillis(); // 使用ZSET存储请求时间戳 redisTemplate.opsForZSet().removeRangeByScore(key, 0, now - windowSize*1000); long count redisTemplate.opsForZSet().zCard(key); if (count limit) { redisTemplate.opsForZSet().add(key, String.valueOf(now), now); return true; } return false; }5.2 性能优化技巧当QPS超过1万时原始方案会出现Redis性能瓶颈。我们通过以下优化将性能提升了8倍分片存储按用户ID哈希分片到不同Redis节点本地缓存先用Guava Cache做第一层过滤批量提交每10ms合并一次Redis操作// 优化后的伪代码 public boolean tryAcquireOptimized(String userId, String apiKey) { // 第一层本地缓存 if (localCache.get(userId) threshold) { return false; } // 第二层Redis分片 String shardKey rate_limit: (userId.hashCode() % 16) : apiKey; return redisTemplate.execute(slidingWindowScript, Collections.singletonList(shardKey), windowSize, limit); }6. 生产环境踩坑实录6.1 Redis集群问题我们在AWS上遇到过经典问题跨AZ访问Redis导致延迟飙升。解决方案是使用Lettuce而非Jedis客户端开启TCP Keepalive设置合理的超时时间# application.yml配置示例 spring: redis: lettuce: pool: max-active: 16 max-wait: 100ms timeout: 200ms6.2 限流策略选择不同场景适合不同算法场景推荐算法原因支付接口滑动窗口精度要求高商品详情令牌桶允许突发风控系统漏桶平稳处理6.3 监控指标完善的监控应该包括限流触发次数请求延迟分布Redis内存/CPU使用率我们使用PrometheusGrafana搭建的监控看板关键指标配置了企业微信报警。7. 扩展思考分布式一致性在百万QPS的场景下单纯依赖Redis也可能成为瓶颈。我们正在测试的混合方案第一层本地限流Guava RateLimiter第二层Redis集群限流第三层Sentinel集群流控这种分层防御体系在今年618大促中成功将Redis负载降低了70%。具体实现涉及到一致性哈希和动态权重调整下次可以单独展开讲讲。