1. 项目概述：当接口遭遇流量洪峰时

上周五凌晨三点，我被一阵急促的报警短信惊醒——核心支付接口的QPS突然从200飙升到8000。登录监控系统一看，整个服务集群已经全线飘红，罪魁祸首是某个合作方脚本失控导致的异常调用。这种场景在分布式系统中并不罕见，今天我们就来聊聊如何用Spring Boot+Redis构建坚如磐石的限流防线。

限流本质上是一种保护机制，就像长江三峡大坝的泄洪闸门。当上游流量超过下游处理能力时，我们需要通过技术手段控制放行速率，避免系统被突发流量击垮。在微服务架构中，常见的限流算法有固定窗口、滑动窗口、漏桶和令牌桶四种方案，它们各有适用场景和实现特点。

2. 四种限流方案深度对比

2.1 固定窗口计数器：简单粗暴的守门人

固定窗口是最基础的限流实现，其核心思想是将时间划分为等长的窗口（比如1分钟），每个窗口内设置最大请求数阈值。Redis中的实现通常使用INCR命令：

// Spring Boot中通过RedisTemplate实现 public boolean isAllowed(String key, int maxRequests, long windowSizeInSeconds) { RedisTemplate<String, String> redisTemplate = getRedisTemplate(); Long currentCount = redisTemplate.opsForValue().increment(key); if (currentCount == 1) { redisTemplate.expire(key, windowSizeInSeconds, TimeUnit.SECONDS); } return currentCount <= maxRequests; }

关键细节：这里必须用原子操作保证"计数+过期时间设置"的原子性，否则在并发场景下可能出现计数永不过期的问题。实际生产环境建议直接使用Lua脚本实现。

固定窗口的缺陷在于存在"窗口临界点突刺"问题。假设限流100次/分钟，如果在第一分钟的最后一秒和第二分钟的第一秒各涌入100次请求，系统实际上在2秒内承受了200次请求——这可能导致瞬时过载。

2.2 滑动日志方案：精确但耗内存

滑动日志通过记录每个请求的时间戳来实现更精确的控制。Redis中可以用ZSET结构存储请求时间戳：

public boolean isAllowed(String key, int maxRequests, long windowSizeInMillis) { long now = System.currentTimeMillis(); long cutoff = now - windowSizeInMillis; redisTemplate.opsForZSet().removeRangeByScore(key, 0, cutoff); long count = redisTemplate.opsForZSet().zCard(key); if (count < maxRequests) { redisTemplate.opsForZSet().add(key, String.valueOf(now), now); return true; } return false; }

这种方案虽然精确，但会随着请求量增加消耗大量内存存储时间戳。我们的监控系统曾因此导致Redis内存告警，不得不每小时执行一次内存整理。

2.3 令牌桶算法：应对突发流量的弹性方案

令牌桶算法允许一定程度的突发流量通过。其原理是系统以恒定速率向桶中添加令牌，请求获取令牌后才能执行。Redis实现示例：

-- KEYS[1]: 令牌桶key -- ARGV[1]: 当前时间戳 -- ARGV[2]: 令牌生成速率(个/秒) -- ARGV[3]: 桶容量 -- ARGV[4]: 请求的令牌数 local tokens_key = KEYS[1] local now = tonumber(ARGV[1]) local rate = tonumber(ARGV[2]) local capacity = tonumber(ARGV[3]) local requested = tonumber(ARGV[4]) local last_time = tonumber(redis.call("hget", tokens_key, "last_time")) or now local tokens = tonumber(redis.call("hget", tokens_key, "tokens")) or capacity local delta = math.max(0, now - last_time) local new_tokens = math.min(capacity, tokens + delta * rate) local allowed = new_tokens >= requested if allowed then new_tokens = new_tokens - requested end redis.call("hmset", tokens_key, "last_time", now, "tokens", new_tokens) redis.call("expire", tokens_key, 2 * capacity / rate) return allowed and 1 or 0

这个算法特别适合需要允许合理突发流量的场景，比如秒杀系统的预热阶段。我们在电商大促时，就是通过调整令牌桶的容量和生成速率来平衡系统负载和用户体验。

2.4 滑动窗口计数器：精准与性能的平衡点

滑动窗口计数器是对固定窗口的改进，通过将大窗口划分为多个小格子来平滑流量统计。以下是基于Redis+Lua的实现：

-- KEYS[1]: 限流key -- ARGV[1]: 当前时间戳(秒) -- ARGV[2]: 窗口大小(秒) -- ARGV[3]: 子窗口数量 -- ARGV[4]: 限流阈值 local key = KEYS[1] local now = tonumber(ARGV[1]) local window = tonumber(ARGV[2]) local subWindows = tonumber(ARGV[3]) local limit = tonumber(ARGV[4]) local subWindowSize = window / subWindows local currentSubWindow = math.floor(now / subWindowSize) -- 获取所有子窗口的计数 local counts = redis.call("hgetall", key) local total = 0 local oldestSubWindow = currentSubWindow - subWindows + 1 -- 清理过期子窗口并统计有效计数 for i = 1, #counts, 2 do local subWindow = tonumber(counts[i]) local count = tonumber(counts[i+1]) if subWindow >= oldestSubWindow and subWindow <= currentSubWindow then total = total + count end end if total >= limit then return 0 end -- 更新当前子窗口计数 redis.call("hincrby", key, currentSubWindow, 1) redis.call("expire", key, window) return 1

这个方案在我们的支付系统中表现最为稳定，能够将QPS波动控制在±5%以内。其核心优势在于：

1. 通过多个子窗口的滑动统计，有效避免了固定窗口的临界问题
2. 相比滑动日志方案，内存占用更小
3. 精度可根据业务需求调整子窗口数量

3. 生产环境实战要点

3.1 Redis集群下的限流一致性

在Redis Cluster环境中，限流key可能分布在不同的节点上。我们采用以下策略保证一致性：

1. 对限流key使用hash tag确保相同资源的请求落到同一节点
2. 在客户端实现后备降级策略，当Redis不可用时切换本地限流
3. 通过Redisson的RLock实现跨节点的分布式协调

// 使用Redisson实现分布式限流 RRateLimiter rateLimiter = redisson.getRateLimiter("api:" + apiKey); rateLimiter.trySetRate(RateType.OVERALL, 100, 1, RateIntervalUnit.MINUTES); if (rateLimiter.tryAcquire()) { // 执行业务逻辑 } else { throw new RateLimitExceededException(); }

3.2 多维度限流策略设计

实际业务中往往需要多层次的限流防护：

1. 全局维度：整个集群的QPS上限
2. 用户维度：单个用户的访问频率控制
3. 业务维度：重要接口的独立配额

// 组合限流策略示例 public boolean isAllowed(HttpServletRequest request) { String apiKey = request.getRequestURI(); String userId = getUserId(request); return globalLimiter.tryAcquire() && userLimiters.get(userId).tryAcquire() && apiLimiters.get(apiKey).tryAcquire(); }

3.3 监控与动态调参

完善的监控体系是限流系统的眼睛：

1. 实时采集被拒绝的请求数和通过率
2. 基于历史数据预测流量趋势
3. 通过配置中心动态调整限流参数

我们使用Prometheus+Grafana搭建的监控看板可以实时显示：

• 各接口的请求速率和限流阈值
• 被拒绝请求的分布情况
• 系统负载与限流策略的关联性

4. 性能优化与踩坑记录

4.1 Lua脚本的性能陷阱

初期我们直接在Java中拼接Lua脚本字符串，导致Redis节点CPU飙升。优化方案：

1. 提前编译并缓存脚本的SHA1
2. 使用KEYS和ARGV代替字符串拼接
3. 控制脚本复杂度，避免长时间运行

// 正确的脚本执行方式 private String scriptSha1; public void init() { String script = "return redis.call('get', KEYS[1])"; scriptSha1 = redisTemplate.getConnectionFactory() .getConnection() .scriptLoad(script.getBytes()); } public Object executeScript() { return redisTemplate.execute( (RedisCallback<Object>) connection -> connection.evalSha(scriptSha1, ReturnType.VALUE, 1, "key".getBytes()) ); }

4.2 热点key的解决方案

当某个接口突然成为热点时，对应的限流key可能造成Redis单节点压力过大。我们采用的解决方案：

1. 对热点key进行分片（如user:123 → user:123:1, user:123:2）
2. 使用本地缓存+Redis的二级限流
3. 在Nginx层面做前置限流

4.3 突发流量的柔性处理

对于突发流量完全拒绝可能影响用户体验，我们实现了以下柔性策略：

1. 请求排队：超出阈值的请求进入队列延迟处理
2. 降级返回：返回缓存数据或精简版响应
3. 优先级调度：VIP用户的请求优先处理

// 优先级队列示例 public class PriorityRateLimiter { private final PriorityBlockingQueue<Request> queue = new PriorityBlockingQueue<>(100, Comparator.comparingInt(Request::getPriority)); public void processRequest(Request request) { if (!queue.offer(request)) { sendTooBusyResponse(request); } } @Scheduled(fixedRate = 100) public void processQueue() { while (canProcessMore() && !queue.isEmpty()) { Request request = queue.poll(); handleRequest(request); } } }

5. 技术选型建议

经过多个项目的实战验证，我的技术选型建议如下：

对于大多数Java应用，我推荐使用Redisson的RRateLimiter作为基础组件，它已经实现了基于Redis的高性能分布式限流。对于特别敏感的核心服务，可以结合滑动窗口算法和本地限流做多层防护。

在最近的一次千万级流量活动中，我们的系统通过"滑动窗口+令牌桶"的组合策略，成功将峰值QPS控制在系统承载能力的80%左右，同时保证了99.95%的请求成功率。这充分验证了Redis限流方案在高并发场景下的可靠性。