一、功能说明
RequestRateLimiterGatewayFilterFactory 是 Spring Cloud Gateway 的流量控制组件，用于实现 API 请求速率限制，核心功能包括：
- 限制单位时间内的请求数量（如每秒10次）
- 防止服务被突发流量击垮（通过令牌桶算法）
- 支持分布式限流（依赖Redis存储）
- 可自定义限流维度（按IP、用户ID等）
二、工作原理图
1. 动态流程（时序图）
2. 静态架构（类图）
三、示例
1. 配置示例（application.yml）
spring:cloud:gateway:routes:- id: rate-limit-routeuri: http://backend-servicepredicates:- Path=/api/**filters:- name: RequestRateLimiterargs:redis-rate-limiter:replenishRate: 10 # 每秒生成10个令牌burstCapacity: 20 # 令牌桶容量key-resolver: "#{@ipKeyResolver}" # 按IP限流
2. 自定义KeyResolver
@Bean
public KeyResolver ipKeyResolver() {return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
}
3. 触发限流时的响应
HTTP/1.1 429 Too Many Requests
X-RateLimit-Remaining: 0
X-RateLimit-Retry-After: 1
Content-Type: application/json{"error": "Too many requests","message": "You have exhausted your API request quota"
}
四、对比
在 Spring Cloud Gateway 的限流场景中，@remoteAddrKeyResolver（按 IP 限流） 是最常用且最方便的实现方式，其次是 @pathKeyResolver（按路径限流）。以下是详细对比和推荐场景：
1. 按 IP 限流（@remoteAddrKeyResolver）
特点：
- 最常用，适合大多数场景。
- 直接基于客户端 IP 区分流量来源，无需用户登录或额外参数。
- 能有效防止单一 IP 的恶意请求或爬虫。
适用场景：
- 匿名访问的 API（如公开接口、登录页）。
- 防止 DDoS 攻击或刷接口。
- 简单粗暴的限流需求。
代码示例：
@Bean
public KeyResolver remoteAddrKeyResolver() {return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
}
优点：
- 实现简单，无需业务逻辑。
- 对客户端无侵入性（不依赖 Cookie/Token）。
缺点：
- 如果用户使用 NAT 或代理（如公司出口 IP 相同），会误伤正常用户。
2. 按路径限流（@pathKeyResolver）
特点：
- 根据请求的 URL 路径区分限流规则。
- 适合不同 API 接口需要不同限流策略的场景。
适用场景：
- 核心接口（如
/payment/**）需要严格限流，非核心接口（如/public/**）放宽限制。 - 需要针对不同路径设置不同
replenishRate和burstCapacity。
代码示例：
@Bean
public KeyResolver pathKeyResolver() {return exchange -> Mono.just(exchange.getRequest().getPath().toString());
}
优点：
- 灵活性高，可精细化控制不同接口的流量。
- 不依赖用户身份信息。
缺点：
- 如果同一 IP 频繁请求不同路径，可能绕过限流。
3. 按用户限流（@userKeyResolver）
特点：
- 基于用户身份（如用户 ID 或 Token）限流。
- 适合需要区分用户权限或订阅等级的场景。
适用场景：
- 付费用户和免费用户的 API 调用限制不同。
- 防止单个用户滥用接口（如频繁提交订单）。
代码示例：
@Bean
public KeyResolver userKeyResolver() {return exchange -> Mono.just(exchange.getRequest().getHeaders().getFirst("Authorization") // 从 Header 取 Token// 或 exchange.getRequest().getQueryParams().getFirst("userId") // 从 Query 参数取用户 ID);
}
优点：
- 精准控制每个用户的请求量。
- 适合多租户或 SaaS 系统。
缺点：
- 需要用户已登录或携带身份信息。
- 实现复杂（需解析 Token 或 Session）。
推荐优先级
-
@remoteAddrKeyResolver（IP 限流）- 推荐指数：★★★★★
- 适合 80% 的场景，尤其是公开 API。
-
@pathKeyResolver（路径限流）- 推荐指数：★★★★☆
- 适合需要区分接口重要性的场景。
-
@userKeyResolver（用户限流）- 推荐指数：★★★☆☆
- 仅限需要用户身份识别的业务（如订单提交）。
最终建议
- 默认选择 IP 限流：简单、通用，能覆盖大多数恶意请求场景。
- 结合路径限流：如果不同接口的 QPS 需求差异大（如
/login严格限流，/public/news不限流）。 - 谨慎使用用户限流：除非业务明确需要（如 VIP 用户特权）。
配置示例（IP + 路径组合限流）
filters:- name: RequestRateLimiterargs:redis-rate-limiter.replenishRate: 10redis-rate-limiter.burstCapacity: 20key-resolver: "#{@ipAndPathKeyResolver}" # 自定义组合 Key
@Bean
public KeyResolver ipAndPathKeyResolver() {return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress() + ":" + exchange.getRequest().getPath());
}
五、关键机制解析
| 组件 | 作用 |
|---|---|
RedisRateLimiter | 基于令牌桶算法实现限流，依赖Redis存储计数 |
KeyResolver | 定义限流维度（如IP、用户ID、API路径等） |
replenishRate | 令牌填充速率（如10=每秒10个请求） |
burstCapacity | 突发流量容量（允许短时间内超过replenishRate的最大值） |
六、应用场景
- 防御CC攻击：限制单个IP的疯狂刷接口行为
- API分级管控：为VIP用户分配更高的请求配额
- 服务降级：在系统高负载时主动限流保核心功能
如果需要更复杂的限流策略（如滑动窗口、漏桶算法），可以自定义实现 RateLimiter 接口。
