3. Rate Limiting 核心参数详解

速率限制（Rate Limiting）的配置质量直接决定系统的防护效果与用户体验。本章深入剖析五个核心参数：速率（rate）、容量（capacity）、突发（burst）、时间窗口（window）、拒绝策略（reject policy），并通过参数联动关系与配置案例，帮助你在实际项目中做出精准决策。

3.1 参数全景图

五个参数并非孤立存在，它们共同构成一个完整的限流决策模型。下图展示了参数之间的依赖与协作关系：

3.2 参数定义与配置规范

每个参数都有明确的数学含义和工程配置方式。下表从定义、单位、典型值、配置示例四个维度进行对比：

3.3 参数深度解析

3.3.1 速率（rate）—— 限流的“油门”

速率是限流系统最核心的参数，它定义了系统在单位时间窗口内能够处理的请求数量上限。速率设置过高会导致系统过载，设置过低则会浪费资源并影响用户体验。

• 固定速率：最常见的配置方式，如 rate=100 表示每秒最多处理 100 个请求。
• 动态速率：根据系统负载或业务优先级动态调整，如高峰期降低速率、低峰期提升速率。
• 多级速率：针对不同用户、API 或服务设置差异化速率，如 VIP 用户 500 req/s，普通用户 50 req/s。

3.3.2 容量（capacity）—— 令牌桶的“油箱”

容量决定了令牌桶或队列的最大存储能力。在令牌桶算法中，容量表示桶中最多能存放的令牌数；在漏桶算法中，容量表示队列的最大长度。

• 容量与速率的关系：容量通常设置为速率的 1~3 倍，以应对短时流量波动。
• 容量过小：即使速率足够，也会因为桶满而频繁丢弃请求，导致限流过于激进。
• 容量过大：会积累大量令牌，导致突发流量过大，可能压垮后端服务。

3.3.3 突发（burst）—— 应对流量尖峰

突发参数允许系统在短时间内处理超过速率限制的请求，用于吸收流量尖峰。突发能力通常由令牌桶算法提供：桶中积累的令牌可以在瞬间被消耗。

• 突发与容量的区别：容量是桶的最大存储，突发是允许瞬时超出的幅度。例如 rate=100, capacity=200, burst=50 表示桶最多存 200 个令牌，但允许瞬间多消耗 50 个。
• 突发配置原则：突发值应小于等于容量值，且通常为速率的 0.5~1 倍。
• 典型场景：秒杀活动、热点新闻推送、API 网关的初始连接突发。

3.3.4 时间窗口（window）—— 统计粒度

时间窗口定义了速率计算的统计周期。不同的窗口算法对限流效果有显著影响：

3.3.5 拒绝策略（reject policy）—— 超出限制后的行为

当请求超过限流阈值时，拒绝策略决定了系统的响应方式。常见的拒绝策略有三种：

• 静默丢弃（Drop）：直接丢弃超限请求，不返回任何响应。适用于日志收集、监控数据等非关键流量。
• 排队等待（Queue）：将超限请求放入队列，等待令牌释放后处理。适用于异步任务、消息推送等可延迟场景。
• 拒绝返回（Reject）：向客户端返回明确的错误码（如 HTTP 429 Too Many Requests），并携带重试时间。适用于 API 网关、用户请求等需要反馈的场景。

3.4 参数联动配置案例

以下是一个典型的 API 网关限流配置示例，展示了五个参数如何协同工作：

# 用户查询接口限流配置
rate_limiting:
  user_query:
    rate: 100           # 每秒最多 100 个请求
    capacity: 300       # 令牌桶容量 300
    burst: 50           # 允许突发 50 个请求
    window: 1s          # 时间窗口 1 秒
    reject_policy: reject  # 超限时返回 429
    queue_size: 0       # 不排队，直接拒绝

# 订单创建接口限流配置（高优先级）
rate_limiting:
  order_create:
    rate: 50
    capacity: 200
    burst: 30
    window: 1s
    reject_policy: queue    # 排队等待
    queue_size: 100         # 队列最大长度
    queue_timeout: 5000ms   # 排队超时 5 秒

3.5 参数配置的缓存一致性影响

在分布式限流系统中，参数配置需要与缓存（如 Redis）保持一致性，否则会导致限流失效或误判：

• 速率与窗口：缓存的 TTL 必须与时间窗口对齐，避免窗口过期后计数器未重置。
• 容量与突发：缓存中的令牌数必须实时同步，分布式节点间需通过原子操作（如 Lua 脚本）保证一致性。
• 拒绝策略：策略变更后，缓存中的限流状态需要平滑迁移，避免正在排队的请求丢失。

3.6 参数配置检查清单

在实际项目中，建议按照以下清单逐项确认参数配置：

1. 速率合理性：是否基于压测数据设定？是否预留了 20% 的余量？
2. 容量与突发匹配：capacity ≥ burst 是否成立？突发值是否在后端承受范围内？
3. 窗口算法选择：固定窗口是否会导致边界尖峰？是否需要升级为滑动窗口？
4. 拒绝策略反馈：是否返回了明确的错误码和重试时间？排队策略是否有超时机制？
5. 缓存一致性：分布式节点间的限流状态是否通过原子操作同步？配置变更后缓存是否及时刷新？