1. 项目概述接口被刷爆了Spring BootRedis限流4种方案滑动窗口最稳这个标题直指现代分布式系统中最常见的痛点之一——接口防刷问题。作为一名经历过多次流量洪峰的后端开发者我深刻理解一个不设防的接口如何在恶意刷单或突发流量下瞬间崩溃。本文将基于Spring Boot和Redis这对黄金组合详解四种不同粒度的限流方案并重点分析为什么滑动窗口算法在实际业务中最稳定可靠。2. 限流技术选型分析2.1 为什么需要限流当API接口面临以下场景时限流就成为系统稳定的生命线恶意用户高频调用登录接口进行撞库攻击电商秒杀活动引发的瞬时流量高峰第三方服务异常导致的连锁雪崩效应内部服务循环调用产生的请求风暴2.2 Redis在限流中的核心价值Redis之所以成为限流方案的首选主要基于三大特性单线程模型保证原子性操作内存读写达到微秒级响应丰富的数据结构支持复杂算法3. 四种限流方案实现3.1 计数器固定窗口算法// Spring Boot中基于Redis的计数器实现 public boolean isAllowed(String key, int maxRequests, long timeWindow) { Long current redisTemplate.opsForValue().increment(key); if (current 1) { redisTemplate.expire(key, timeWindow, TimeUnit.SECONDS); } return current maxRequests; }注意该方法存在临界时间窗口问题比如在时间窗口切换瞬间可能允许2倍流量通过3.2 令牌桶算法实现// 使用RedisLua实现令牌桶 String luaScript local tokens tonumber(redis.call(get, KEYS[1])) if tokens then local newTokens math.min(tokens (ARGV[1] * ARGV[3]), ARGV[2]) if newTokens ARGV[4] then redis.call(set, KEYS[1], newTokens - ARGV[4]) return true end end return false;参数说明KEYS[1]: 存储令牌的keyARGV[1]: 当前时间戳ARGV[2]: 桶容量ARGV[3]: 令牌生成速率ARGV[4]: 请求需要的令牌数3.3 漏桶算法对比漏桶与令牌桶的核心区别漏桶强制恒定流出速率令牌桶允许突发流量只要桶中有令牌漏桶更适合平滑流量令牌桶更灵活3.4 滑动窗口算法详解3.4.1 核心数据结构设计使用Redis的ZSET实现时间窗口member: 请求ID或时间戳score: 请求时间戳毫秒public boolean slidingWindow(String key, int maxRequests, long windowMs) { long now System.currentTimeMillis(); long windowStart now - windowMs; redisTemplate.opsForZSet().removeRangeByScore(key, 0, windowStart); long currentCount redisTemplate.opsForZSet().zCard(key); if (currentCount maxRequests) { redisTemplate.opsForZSet().add(key, UUID.randomUUID().toString(), now); return true; } return false; }3.4.2 性能优化技巧使用Lua脚本保证原子性local key KEYS[1] local now tonumber(ARGV[1]) local windowMs tonumber(ARGV[2]) local max tonumber(ARGV[3]) redis.call(ZREMRANGEBYSCORE, key, 0, now - windowMs) local count redis.call(ZCARD, key) if count max then redis.call(ZADD, key, now, now) return 1 end return 0集群环境下使用Redisson的RRateLimiter4. 生产环境实战要点4.1 限流维度设计根据业务需求选择不同维度用户级别userId作为key前缀接口级别uri作为key前缀全局级别固定key值4.2 动态配置策略通过Spring Cloud Config或Nacos实现动态调整rate: limit: user: 100/60s api: /order/create: 500/10s /payment/callback: 2000/1m4.3 监控与告警建议监控指标限流触发QPS请求拒绝率各接口平均耗时变化5. 方案对比与选型建议方案优点缺点适用场景固定窗口实现简单临界时间问题对精度要求不高的场景令牌桶允许突发流量实现较复杂需要弹性限流的场景漏桶流量绝对平滑无法应对突发严格控速场景滑动窗口精度高内存消耗大精准控流的业务场景在实际项目中我建议普通管理接口使用固定窗口核心交易接口采用滑动窗口与第三方对接使用令牌桶6. 常见问题排查6.1 Redis连接池耗尽现象限流接口突然失效 解决方案调整Jedis/Lettuce连接池大小添加连接池监控使用连接池预热6.2 时间同步问题现象集群环境下限流不准 解决方案部署NTP时间同步服务使用Redis服务器时间代替本地时间6.3 热key问题现象某个用户限流导致Redis性能下降 解决方案对key进行hash分散使用本地缓存Redis二级限流7. 高级优化方案7.1 分布式限流架构对于超大规模系统可以采用前置网关层限流如Nginx应用层限流本文方案服务熔断降级Sentinel/Hystrix7.2 自适应限流算法基于系统负载动态调整限流阈值// 根据CPU负载动态调整 double load ManagementFactory.getOperatingSystemMXBean().getSystemLoadAverage(); int dynamicThreshold (int) (baseThreshold * (1 - Math.min(load, 0.7)));7.3 灰度发布配合新接口上线时先设置严格限流监控实际流量模式逐步调整限流策略经过多个百万级QPS项目的验证滑动窗口算法在保证精度的同时配合Redis的优异性能确实能成为系统稳定的守护者。特别是在618、双11等大促场景下合理的限流配置往往能让系统在流量洪峰中屹立不倒。