1. 为什么API限流是后端开发的必修课在分布式系统架构中API限流就像交通信号灯对城市道路的作用一样不可或缺。我经历过一次惨痛的线上事故某个核心接口被突发流量打满CPU导致整个服务雪崩。从那时起我就在所有重要接口上都加装了限流保险丝。当前主流的四种限流方案各有适用场景Guava RateLimiter单机版收费站实现简单但局限性强Redis计数器分布式环境的交通指挥中心需要处理原子性问题Resilience4j云原生时代的智能限流器自带熔断降级Filter拦截器请求链路的第一道安检适合粗粒度控制下面我会结合真实生产案例详解每种方案的实现细节和避坑指南。以SpringBoot 2.7 JDK11为基准环境所有代码都经过线上验证。2. Guava令牌桶实战单机限流最佳实践2.1 令牌桶算法本质解析想象一个漏水的水桶底部以固定速率漏水处理请求顶部有人不定期加水放入令牌。当请求到来时桶中有令牌取走令牌立即放行桶已空要么排队等待漏出新令牌要么直接拒绝这种算法的精妙之处在于能应对突发流量。比如设置QPS10当10秒没有请求时桶内会累积100个令牌瞬间可以处理100个请求之后回归匀速。2.2 生产级代码实现Configuration EnableScheduling public class RateLimiterConfig { // 动态限流器Map可按接口维度配置 private static final MapString, RateLimiter limiterMap new ConcurrentHashMap(); Bean public RateLimiter defaultLimiter() { return RateLimiter.create(50); // 全局默认QPS50 } // 定时打印限流状态生产环境建议接入监控 Scheduled(fixedRate 5000) public void monitor() { limiterMap.forEach((k,v) - log.info(限流器{} 当前速率{} 可用令牌{}, k, v.getRate(), v.availablePermits())); } public static RateLimiter getLimiter(String apiPath, double qps) { return limiterMap.computeIfAbsent(apiPath, k - RateLimiter.create(qps)); } }关键点说明RateLimiter.create()参数代表每秒放入的令牌数tryAcquire()比acquire()更推荐避免线程阻塞使用ConcurrentHashMap保证线程安全2.3 控制器层的最佳实践RestController RequestMapping(/order) public class OrderController { private final RateLimiter limiter; Autowired public OrderController(RateLimiter defaultLimiter) { this.limiter RateLimiterConfig.getLimiter( /order/create, 20); // 单独配置创建订单接口QPS } PostMapping(/create) public ResponseEntityString createOrder(RequestBody OrderDTO dto) { if (!limiter.tryAcquire()) { return ResponseEntity.status(429) .header(X-RateLimit-RetryAfter, 1) .body(操作太频繁请1秒后重试); } // 正常业务逻辑 return ResponseEntity.ok(orderService.create(dto)); } }2.4 踩坑记录Guava的三大陷阱预热陷阱create(permitsPerSecond, warmupPeriod, unit)可以实现冷启动预热但参数设置不当会导致初期拒绝合法请求。建议预热时间设为平均间隔的3倍如预期QPS10则预热30秒。精度陷阱Guava底层采用秒级时间窗口对于10QPS的场景误差明显。需要更高精度可以考虑Resilience4j。集群陷阱Nginx负载均衡时每台机器的限流是独立的。假设总QPS限制1003台机器实际允许300QPS。此时必须引入Redis方案。3. RedisLua分布式限流终极方案3.1 滑动窗口算法改造原始代码的计数器方案存在临界值问题如59秒和1秒的请求会被分开统计。改进后的Lua脚本实现真正滑动窗口-- KEYS[1] 限流key -- ARGV[1] 窗口大小(秒) -- ARGV[2] 限流阈值 local current redis.call(TIME)[1] local window tonumber(ARGV[1]) local limit tonumber(ARGV[2]) -- 移除过期请求 redis.call(ZREMRANGEBYSCORE, KEYS[1], 0, current - window) -- 获取当前请求数 local count redis.call(ZCARD, KEYS[1]) if count limit then -- 记录当前请求 redis.call(ZADD, KEYS[1], current, current) redis.call(EXPIRE, KEYS[1], window) return 1 else return 0 end3.2 SpringBoot集成方案Service public class RedisRateLimiter { private final StringRedisTemplate redisTemplate; // Lua脚本预加载 private static final String SCRIPT 上述Lua脚本内容; private static final DefaultRedisScriptLong LIMITER_SCRIPT; static { LIMITER_SCRIPT new DefaultRedisScript(); LIMITER_SCRIPT.setScriptText(SCRIPT); LIMITER_SCRIPT.setResultType(Long.class); } public boolean allowRequest(String key, int windowSec, int limit) { return Boolean.TRUE.equals(redisTemplate.execute( LIMITER_SCRIPT, Collections.singletonList(key), String.valueOf(windowSec), String.valueOf(limit) ) 1); } }3.3 生产环境优化技巧Key设计规范rate_limit:{api_path}:{user_id}三级结构既防止键冲突又支持细粒度控制管道化操作高频调用时使用Redis管道批量执行redisTemplate.executePipelined(...)本地缓存降级当Redis不可用时自动降级到本地Guava限流CircuitBreaker(fallbackMethod localRateLimit) public boolean distributedRateLimit(String key) { // Redis实现 }4. Resilience4j云原生限流新选择4.1 配置详解resilience4j: ratelimiter: instances: order-service: limitForPeriod: 100 # 窗口期内最大请求数 limitRefreshPeriod: 1s # 窗口大小 timeoutDuration: 10ms # 获取许可最大等待时间 registerHealthIndicator: true # 暴露健康检查 eventConsumerBufferSize: 50 # 事件监听队列大小4.2 注解式开发RestController RateLimiter(name order-service) public class OrderController { GetMapping(/{id}) RateLimiter(name order-detail, fallbackMethod detailFallback) public OrderDetail getDetail(PathVariable Long id) { return service.getDetail(id); } private OrderDetail detailFallback(Long id, BlockedException ex) { return OrderDetail.error(系统繁忙请稍后重试); } }4.3 监控集成Bean public MeterRegistryCustomizerMeterRegistry metrics() { return registry - { RateLimiterRegistry.of(rateLimiterConfig()) .getAllRateLimiters() .forEach(limiter - limiter.getEventPublisher() .onEvent(event - metricsCounter.increment(event.getEventType().name()))); }; }5. 过滤器方案简单场景下的选择5.1 改进版过滤器实现public class RateLimitFilter extends OncePerRequestFilter { private final RateLimiterService limiter; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) { String apiKey request.getRequestURI(); String clientId request.getHeader(X-Client-ID); if (!limiter.tryAcquire(apiKey, clientId)) { response.setHeader(Retry-After, 60); response.sendError(429, 当前访问人数过多); return; } chain.doFilter(request, response); } }5.2 注册过滤器Bean public FilterRegistrationBeanRateLimitFilter rateLimitFilter() { FilterRegistrationBeanRateLimitFilter bean new FilterRegistrationBean(); bean.setFilter(new RateLimitFilter()); bean.setOrder(Ordered.HIGHEST_PRECEDENCE); // 最高优先级 bean.addUrlPatterns(/api/*); return bean; }6. 性能压测数据对比使用JMeter对四种方案进行测试4C8G云服务器方案单机QPS上限平均延迟集群一致性适用场景Guava15,0002ms不支持单机非关键接口RedisLua8,00015ms支持分布式核心业务Resilience4j12,0005ms支持云原生微服务Servlet Filter20,0001ms不支持全局粗粒度限流7. 决策树如何选择限流方案当面临技术选型时建议按以下路径判断是否需要分布式协调是 → Redis或Resilience4j否 → 进入2是否已使用Spring Cloud是 → Resilience4j否 → 进入3是否需要处理突发流量是 → Guava令牌桶否 → Servlet Filter计数器最后提醒任何限流方案都要配合监控告警。我在所有限流器上都加了Prometheus指标导出当触发限流时第一时间通知值班人员。