1. 适用场景#

适用于 Java、Spring Cloud 微服务项目，需要在统一入口控制请求流量的场景。

2. 工程流程#

客户端请求 → Spring Cloud Gateway → 限流检查 → 业务服务 → 数据库。

3. 具体实施步骤#

第一步：制定限流规则。

根据接口的重要程度和数据库承载能力设置规则，例如：

• 单个用户每秒最多请求 10 次。
• 某个查询接口全局每秒最多放行 200 次。
• 对复杂报表查询设置更严格的限制。

具体阈值需要通过压测和线上监控确定。

第二步：接入限流组件。

使用 Spring Cloud Gateway 提供的 RequestRateLimiter 过滤器，配合 Redis 限流器实现请求速率限制。

主要配置包括：

• KeyResolver：确定限流维度，例如用户 ID。
• RedisRateLimiter：配置令牌桶的填充速率和容量。
• RequestRateLimiter：在请求转发前执行限流检查。

第三步：处理超限请求。

• 未超过限制：转发到业务服务。
• 超过限制：拒绝请求，返回 HTTP 429。
• 根据业务需要返回统一错误码和友好提示。

第四步：压测与监控。

观察网关请求量、拒绝率、响应时间、数据库 QPS 和连接池使用情况，调整限流规则。

4. 优缺点#

优点：

• 统一管理多个微服务的入口流量。
• 与 Spring Cloud 体系集成方便。
• 可以按用户或接口配置规则。

缺点：

• 需要部署和维护网关。
• 仅限制单个用户不能保证数据库安全，还需要接口级全局限制。
• 使用 Redis 限流时，需要考虑 Redis 的可用性和访问开销。

1. 适用场景#

适用于已有 Nginx 作为反向代理或 HTTP 入口的系统，适合快速实现基础流量保护。

2. 工程流程#

客户端请求 → Nginx → 限流检查 → 后端业务服务 → 数据库。

3. 具体实施步骤#

第一步：确定需要保护的接口。

例如，复杂报表接口 /api/report/query 会执行成本较高的 SQL，需要设置单独的限流规则。

第二步：配置限流规则。

使用 Nginx 的 limit_req_zone 和 limit_req：

1
http {
2
    limit_req_zone $binary_remote_addr
3
        zone=report_limit:10m rate=5r/s;
4

5
    server {
6
        location /api/report/query {
7
            limit_req zone=report_limit burst=10;
8
            limit_req_status 429;
9

10
            proxy_pass http://backend;
11
        }
12
    }
13
}

配置含义：

• limit_req_zone：创建限流区域，按客户端 IP 记录请求速率。
• rate=5r/s：平均速率限制为每秒 5 个请求。
• burst=10：允许一定程度的短时突发请求。
• limit_req_status 429：超限时返回 HTTP 429。
• proxy_pass：通过限流检查后才转发请求。

默认情况下，突发请求可能被延迟处理；如果配置 nodelay，允许的突发请求可以立即处理，但不会改变长期速率限制。

第三步：验证效果。

通过压测确认超限请求被拒绝，并观察后端请求量和数据库负载是否下降。

4. 优缺点#

优点：

• 配置相对简单。
• 性能开销较低。
• 可以在请求进入应用前进行拦截。

缺点：

• 原生规则主要围绕 IP、请求速率等维度，业务身份识别能力有限。
• 多个 Nginx 实例独立计数时，不会自动形成统一的全局额度。
• 需要正确处理反向代理和客户端 IP，避免限流规则失效。

1. 适用场景#

适用于多个应用实例需要共享限流额度，或者需要灵活实现用户级、接口级业务限流的场景。

2. 工程流程#

客户端请求 → 网关或业务服务中的限流代码 → Redis + Lua 检查额度 → 放行或拒绝。

关键点：Redis 负责记录和判断额度，真正执行拦截的是调用 Redis 的代码。

如果在网关中调用 Redis，属于入口限流；如果在业务服务中调用 Redis，则请求已经进入应用，不能完全替代网关防护。

3. 具体实施步骤#

第一步：确定限流维度。

例如：

• 单用户每秒最多请求 5 次。
• 整个报表接口每秒最多放行 500 次。

前者防止单个用户占用过多资源，后者控制接口总流量。

第二步：设计 Redis Key。

例如：

1
rate:user:1001:report:window
2
rate:global:report:window

分别记录用户级和接口全局级的请求额度。实际实现中，需要正确设计时间窗口或令牌桶状态。

第三步：使用 Lua 原子检查。

将计数更新、额度检查和放行判断放在同一个 Lua 脚本中执行，避免并发请求之间发生计数竞争。

常见算法包括：

• 固定窗口：实现简单，但窗口边界可能出现突发流量。
• 滑动窗口：更精细地控制时间范围内的请求数量。
• 令牌桶：允许一定程度的突发流量，同时限制长期请求速率。

第四步：根据判断结果处理请求。

• 额度充足：放行请求。
• 超过限制：返回 HTTP 429。
• Redis 不可用：根据业务重要性制定故障策略，不能不加判断地全部放行。

第五步：保证集群运行稳定。

考虑 Redis 高可用、故障切换、网络延迟和限流状态的一致性。

4. 优缺点#

优点：

• 限流规则灵活。
• 多个实例可以共享限流额度。
• 适合用户级和全局业务级限流。

缺点：

• 需要维护 Redis 和限流代码。
• 每次判断会产生 Redis 访问开销。
• Redis 故障可能影响请求处理。
• 应放在合适的入口位置，避免请求已经占用大量业务资源才开始限流。

1. 适用场景#

适用于部署在云上的系统，希望使用托管式流量管理和安全防护能力的场景。

2. 工程流程#

客户端请求 → 云 API 网关或 WAF → 云上业务服务 → 数据库。

3. 具体实施步骤#

第一步：统一接入云端入口。

让客户端请求通过云 API 网关进入后端，避免客户端绕过网关直接访问业务服务。

第二步：配置流量和安全规则。

例如：

• 按接口设置请求速率上限。
• 按账号、用户或 IP 设置请求配额。
• 对异常流量配置拦截规则。
• 对不同业务设置不同的流量额度。

需要注意：API 网关主要负责 API 管理与流量控制；WAF 更侧重 Web 攻击检测和恶意流量防护。WAF 不能替代数据库容量保护。

第三步：设置超限处理。

根据云产品的功能设置请求拒绝、错误响应和告警等动作。

第四步：验证防护效果。

观察超限请求是否被拦截、后端请求量是否下降，以及数据库 CPU、连接数和查询延迟是否改善。

4. 优缺点#

优点：

• 减少自建中间件的部署和维护工作。
• 可以利用云平台已有的流量管理和安全能力。
• 适合云上业务的统一入口管理。

缺点：

• 依赖云厂商的产品能力和计费规则。
• 复杂的业务级限流可能仍需应用逻辑或 Redis 配合。
• 必须避免后端存在绕过入口的访问路径。