在微服务架构的入口处API 网关负责抵挡外部突发的恶意爬虫、秒杀洪峰以及各业务系统的突发调用。Spring Cloud Gateway 官方提供了基于 Redis 的RequestRateLimiterGatewayFilterFactory过滤器使我们能够以极低的配置成本实现分布式限流。然而在生产环境的高并发实测中许多团队经常遇到一些诡异问题为什么设置了每秒允许 100 次请求在流量突发时却放行了 200 次为什么在集群时钟存在微小偏差时限流阈值会出现严重抖动要解决这些疑难杂症必须深入到令牌桶Token Bucket算法的数学模型以及 Redis 底层 Lua 脚本的实现细节中。常见限流算法对比与选型在网关流控领域常见的限流算法各具优缺点算法核心机制应对突发流量能力资源开销适用场景固定窗口在固定时间窗口如 1 秒内计数差存在窗口临界双倍流量突刺极低单个计数器粗粒度配额控制滑动日志记录每个请求的时间戳并精准统计良好极高内存随 QPS 线性膨胀低频高精度场景漏桶算法恒定速率流出水满则溢差完全抹平突发流量强行排队低保护下游慢速第三方系统令牌桶算法以恒定速率补充令牌允许突发消耗桶内令牌极佳支持突发流量平滑过渡低API 入口网关SCG 首选在我们的网关压测与流量塑形实践中令牌桶之所以成为生产首选正是因为它在应对瞬时突刺时的弹性表现它的工作机制非常直观系统以预设的恒定速率replenishRate向桶内持续补充令牌而桶的容量上限burstCapacity则直接决定了系统允许容忍的突发并发厚度。当并发请求到达网关时每个请求都必须从桶中申请指定数量的令牌requested。如果桶内积攒的可用令牌充足即便瞬时 QPS 远远超出稳态速率请求依然能被毫秒级放行至后端微服务而一旦突发流量将桶内令牌耗尽、生成速度赶不上消耗节奏时网关便果断触发熔断拦截返回 HTTP 429 Too Many Requests 强制客户端退避。然而将这套算法搬到无状态的分布式网关集群中时最大的挑战在于“如何在不依赖中心化定时器和分布式锁的前提下保证多节点并发扣减的绝对一致性”。这就需要深入到 Spring Cloud Gateway 极其精妙的底层实现中RedisRateLimiter 底层 Lua 脚本核心解析Spring Cloud Gateway 并没有在后台启动一个定时器线程去源源不断地向 Redis 写入令牌因为在千万级 Key 的分布式场景下定时器的心跳开销足以拖垮整个集群。其核心实现是通过惰性计算Lazy Evaluation在每次请求到达时通过执行一段原子性的 Lua 脚本计算“当前时间戳与上次请求时间戳的差值”从而动态补齐该时间段内应生成的令牌。在 Redis 中单个限流维度会维护两个键request_rate_limiter.{id}.tokens当前桶内剩余的可用令牌数。request_rate_limiter.{id}.timestamp上一次成功刷新令牌的 UNIX 时间戳秒。以下为 Spring Cloud Gateway 底层核心 Lua 逻辑的精简提炼-- 参数获取 local tokens_key KEYS[1] local timestamp_key KEYS[2] local rate tonumber(ARGV[1]) -- replenishRate 每秒生成速率 local capacity tonumber(ARGV[2]) -- burstCapacity 桶的最大容量 local now tonumber(ARGV[3]) -- 当前时间戳(秒) local requested tonumber(ARGV[4]) -- 本次请求消耗的令牌数(通常为1) local fill_time capacity / rate local ttl math.floor(fill_time * 2) -- 获取当前存储的令牌数与上次时间戳 local last_tokens tonumber(redis.call(get, tokens_key)) if last_tokens nil then last_tokens capacity end local last_refreshed tonumber(redis.call(get, timestamp_key)) if last_refreshed nil then last_refreshed 0 end -- 核心数学计算时间差 * 生成速率 补偿令牌数 local delta math.max(0, now - last_refreshed) local filled_tokens math.min(capacity, last_tokens (delta * rate)) local allowed filled_tokens requested local new_tokens filled_tokens if allowed then new_tokens filled_tokens - requested end -- 原子性写回 Redis 并设置过期时间防内存泄露 redis.call(setex, tokens_key, ttl, new_tokens) redis.call(setex, timestamp_key, ttl, now) -- 返回结果: [allowed (0/1), new_tokens] return { allowed and 1 or 0, new_tokens }这种设计的精妙之处在于零定时器、零分布式锁竞争、完全依靠单次 Redis EVALSHA 调用的原子性保证并发一致性。生产级动态限流与 KeyResolver 实现1. 多维度复合限流 Key 解析器在实际业务中限流不应仅针对单一 IP。我们通常需要组合用户 ID 接口 Path 客户端来源进行精细化流控package com.example.gateway.limiter; import org.springframework.cloud.gateway.filter.ratelimit.KeyResolver; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.Primary; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Mono; Configuration public class RateLimiterConfig { Bean Primary public KeyResolver compositeKeyResolver() { return exchange - { // 优先获取已认证的用户 ID String userId exchange.getRequest().getHeaders().getFirst(X-User-Id); if (userId ! null !userId.isBlank()) { String path exchange.getRequest().getURI().getPath(); return Mono.just(user_ userId : path); } // 未登录用户降级为基于真实客户端 IP 限流 String clientIp resolveClientIp(exchange); return Mono.just(ip_ clientIp); }; } private String resolveClientIp(ServerWebExchange exchange) { String xForwardedFor exchange.getRequest().getHeaders().getFirst(X-Forwarded-For); if (xForwardedFor ! null !xForwardedFor.isBlank()) { return xForwardedFor.split(,)[0].trim(); } return exchange.getRequest().getRemoteAddress() ! null ? exchange.getRequest().getRemoteAddress().getAddress().getHostAddress() : unknown; } }2. 路由配置与动态参数绑定spring: cloud: gateway: routes: - id: order-service-route uri: lb://order-service predicates: - Path/api/orders/** filters: - name: RequestRateLimiter args: key-resolver: #{compositeKeyResolver} redis-rate-limiter.replenishRate: 100 # 每秒补充 100 个令牌稳定 TPS 预期 redis-rate-limiter.burstCapacity: 200 # 允许最多积攒 200 个令牌应对瞬间翻倍洪峰 redis-rate-limiter.requestedTokens: 1生产调优与避坑经验时钟漂移问题由于 Lua 脚本强依赖传入的now时间戳网关集群各实例之间若存在明显 NTP 时钟偏差会导致计算出的delta为负数或突增。生产环境下各网关节点必须配置高精度的 NTP 同步服务。Redis 单分片热点当网关 QPS 达到数万级别时所有请求访问同一个 Redis 节点可能导致 CPU 达到瓶颈。应对方案是采用 Redis Cluster并在 Key 前缀中增加均匀的 Hash Tag 进行负载均衡。友好响应协议定制默认情况下限流会返回空的 HTTP 429 状态码。应在网关中注册全局ErrorWebExceptionHandler将其包装为规范的 JSON 响应体并附带Retry-After: 1响应头引导客户端进行指数退避重试。