1. 为什么需要API限流在分布式系统架构中API限流是保护系统稳定性的第一道防线。去年双十一期间某电商平台因为未做好限流防护导致瞬时流量激增引发系统雪崩直接损失超过千万。这个惨痛教训告诉我们没有限流的系统就像没有刹车的汽车随时可能失控。API限流的核心价值主要体现在三个方面防止资源耗尽避免单个用户或服务占用过多系统资源保障服务质量确保系统在承受范围内平稳运行应对突发流量为系统提供缓冲时间进行弹性扩容2. 主流限流算法对比2.1 令牌桶算法Token BucketGuava RateLimiter采用的就是令牌桶算法。它的工作原理类似于游乐园门票发放系统有一个固定容量的桶比如容量100以恒定速率往桶里放令牌比如每秒10个每个请求需要消耗一个令牌当桶空时拒绝新请求// 创建每秒10个令牌的限流器 RateLimiter limiter RateLimiter.create(10.0); // 获取令牌阻塞等待 limiter.acquire(); // 尝试获取令牌非阻塞 if(limiter.tryAcquire()) { // 执行业务逻辑 }实际项目中建议使用tryAcquire带超时参数的版本避免线程长时间阻塞2.2 漏桶算法Leaky Bucket漏桶算法可以理解为带孔的水桶请求像水一样流入桶中桶以固定速率漏水处理请求当水满时桶满拒绝新请求与令牌桶的区别在于令牌桶允许突发流量只要桶里有令牌漏桶强制恒定速率更平滑2.3 滑动窗口算法Redis限流示例中使用的就是滑动窗口的变种。它的核心思想是将时间划分为多个小窗口比如1分钟划分为6个10秒窗口统计最近N个窗口的请求总数超过阈值则拒绝这种算法能平衡精度和性能是分布式限流的常用方案。3. SpringBoot集成Guava限流实战3.1 最佳实践配置在电商项目中我们这样配置多维度限流Configuration public class RateLimiterConfig { // 普通API限流100次/秒 Bean Qualifier(apiRateLimiter) public RateLimiter apiRateLimiter() { return RateLimiter.create(100.0); } // 支付接口限流20次/秒 Bean Qualifier(paymentRateLimiter) public RateLimiter paymentRateLimiter() { return RateLimiter.create(20.0); } }3.2 控制器层实现建议使用AOP实现统一限流Aspect Component public class RateLimitAspect { Autowired Qualifier(apiRateLimiter) private RateLimiter apiRateLimiter; Around(annotation(rateLimited)) public Object rateLimit(ProceedingJoinPoint joinPoint, RateLimited rateLimited) throws Throwable { if(apiRateLimiter.tryAcquire(500, TimeUnit.MILLISECONDS)) { return joinPoint.proceed(); } throw new RateLimitExceededException(请求过于频繁); } } // 自定义注解 Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RateLimited {}3.3 性能优化技巧预热模式对于冷启动系统使用预热限流器// 预热期5分钟最终达到100qps RateLimiter.create(100.0, 5, TimeUnit.MINUTES);动态调整根据系统负载动态调整速率// 监控系统CPU负载 double load ManagementFactory.getOperatingSystemMXBean().getSystemLoadAverage(); if(load 4.0) { rateLimiter.setRate(rateLimiter.getRate() * 0.8); // 降级20% }4. 分布式限流Redis方案进阶4.1 Lua脚本实现原子操作原生Redis命令存在竞态条件使用Lua脚本可以保证原子性local key KEYS[1] local limit tonumber(ARGV[1]) local window tonumber(ARGV[2]) local current redis.call(GET, key) local count 0 if current then count tonumber(current) end if count limit then return 0 else redis.call(INCR, key) redis.call(EXPIRE, key, window) return 1 endSpring中调用public boolean isAllowed(String key, int limit, int window) { String script 上述Lua脚本内容; RedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result redisTemplate.execute(redisScript, Collections.singletonList(key), String.valueOf(limit), String.valueOf(window)); return result 1; }4.2 红锁算法实现为避免单点故障可以使用RedLockpublic boolean redLockRateLimit(String resource, int limit, int windowSec) { ListRedisNode nodes getRedisNodes(); // 获取集群所有节点 int quorum nodes.size()/2 1; int success 0; for(RedisNode node : nodes) { if(acquireLock(node, resource, limit, windowSec)) { success; if(success quorum) break; } } if(success quorum) { // 释放已获取的锁 return false; } return true; }5. Resilience4j生产级配置5.1 完整配置示例resilience4j: ratelimiter: instances: order-service: limitForPeriod: 50 limitRefreshPeriod: 1s timeoutDuration: 100ms registerHealthIndicator: true eventConsumerBufferSize: 50 payment-service: limitForPeriod: 10 limitRefreshPeriod: 1s subscribeForEvents: true circuitbreaker: instances: order-service: registerHealthIndicator: true slidingWindowSize: 100 minimumNumberOfCalls: 105.2 监控集成Bean public MeterRegistryCustomizerMeterRegistry metrics() { return registry - { RateLimiterMetrics.ofRateLimiterRegistry(rateLimiterRegistry) .bindTo(registry); }; } // Prometheus配置 management: endpoints: web: exposure: include: health,metrics,prometheus metrics: export: prometheus: enabled: true6. 过滤器限流的陷阱与解决方案6.1 内存泄漏问题示例代码中的ConcurrentHashMap会持续增长必须实现清理机制Scheduled(fixedRate 1, timeUnit TimeUnit.HOURS) public void cleanUp() { long now System.currentTimeMillis(); requestCounts.keySet().removeIf(key - now - lastRequestTimes.getOrDefault(key, 0L) TimeUnit.HOURS.toMillis(1)); }6.2 集群同步方案使用Redis本地缓存二级方案// 本地缓存 LoadingCacheString, AtomicInteger localCache Caffeine.newBuilder() .expireAfterWrite(1, TimeUnit.MINUTES) .build(key - { Integer count redisTemplate.opsForValue().get(key); return new AtomicInteger(count ! null ? count : 0); }); // 定期同步到Redis Scheduled(fixedRate 30, timeUnit TimeUnit.SECONDS) public void syncToRedis() { localCache.asMap().forEach((key, value) - { redisTemplate.opsForValue().set(key, value.get()); }); }7. 性能压测数据对比使用JMeter对四种方案进行测试单机4核8G方案吞吐量 (req/s)平均延迟99线延迟适用场景Guava单机12,0002ms15ms单机服务RedisLua8,5005ms25ms分布式系统Resilience4j10,0003ms20ms微服务架构Servlet Filter9,0004ms22ms统应用8. 常见问题排查指南8.1 限流不生效检查清单配置检查确认RateLimiter.create()的参数单位是否正确检查Spring的Bean是否被正确注入拦截路径确认Filter或AOP拦截了正确路径使用Actuator的mappings端点验证Redis连接检查Redis是否正常运行确认RedisTemplate配置正确8.2 性能问题优化现象限流导致TP99升高解决方案使用tryAcquire替代acquire调整等待超时时间建议100-500ms考虑使用异步模式CompletableFuture.supplyAsync(() - { if(rateLimiter.tryAcquire()) { return service.process(); } throw new RateLimitException(); }).exceptionally(ex - { // 处理限流异常 return fallback(); });9. 多级限流架构设计在实际生产环境中建议采用多级限流策略客户端限流 → API网关限流 → 服务限流 → 方法限流具体实现Nginx层限流limit_req_zone $binary_remote_addr zoneapi:10m rate100r/s; location /api { limit_req zoneapi burst50; proxy_pass http://backend; }Spring Cloud GatewayBean public CustomizerRedisRateLimiter rateLimiterCustomizer() { return config - config.setIncludeHeaders(true); } // 路由配置 routes: - id: order-service uri: lb://order-service predicates: - Path/orders/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 50 redis-rate-limiter.burstCapacity: 100方法级注解RateLimiter(value order-service, fallbackMethod createOrderFallback) public Order createOrder(OrderRequest request) { // 业务逻辑 }10. 限流与熔断的协同在实际项目中限流需要与熔断器配合使用resilience4j: circuitbreaker: instances: order-service: failureRateThreshold: 50 waitDurationInOpenState: 5s slidingWindowSize: 20 ratelimiter: instances: order-service: limitForPeriod: 50 limitRefreshPeriod: 1s协同策略当熔断器打开时直接拒绝请求半开状态下允许少量请求通过关闭状态下正常限流监控看板应同时展示两种指标限流拒绝次数熔断状态变化请求成功率变化曲线