Soffio

核心要点

限流的数学本质

系统响应时间随负载率呈非线性增长： $T = \frac{1}{μ ( 1 - ρ )}$
当负载接近容量时，延迟指数级恶化

主要算法对比

固定窗口：简单但有边界突刺问题
滑动窗口：精确但开销大
令牌桶：优雅平衡，支持突发
漏桶：平滑流量，保护下游

分布式限流权衡

CP方案（Redis中心化）：精确但有延迟
AP方案（本地+同步）：快速但可能超限
分片方案：独立但负载不均

真实案例洞察

GitHub API过载：单客户端100万请求导致全站故障
Google分布式限流：P99延迟0.8ms，误差<2%
AWS分层限流：按用户价值分配资源

实践建议

测量真实容量，留30%余量
分析流量模式，选择匹配算法
多维度限流（用户/IP/API/全局）
持续监控调整，优化用户体验

限流不是技术炫技，而是保护系统稳定性的理性工具。

引言：限流是什么，为什么重要

当你的API在某个周五晚上突然收到10倍于正常流量的请求时，你会怎么办？

这不是假设。2021年，Fastly的CDN故障导致大量网站流量回源，某些源站在几秒内收到了平时一整天的请求量。那些没有限流保护的服务器瞬间崩溃，而那些有完善限流机制的系统则优雅地拒绝了部分请求，保持了核心服务的可用性。

限流（Rate Limiting）是高可用系统的最后一道防线。但它不仅仅是"拒绝请求"这么简单——限流是一个涉及数学、工程和商业权衡的复杂决策。

本文将深入探讨：

限流算法的数学本质和权衡
从单机到分布式的工程实践
Google、AWS、Cloudflare等大厂的真实案例
如何根据业务特征选择合适的算法

第一性原理：为什么需要限流

在讨论算法之前，我们需要理解限流的根本目的。

系统容量的数学现实

任何系统都有物理极限。一个典型的Web服务器可能在以下条件下达到瓶颈：

CPU：处理请求的计算能力
内存：缓存和会话数据
网络带宽：数据传输速度
数据库连接：并发查询数量

假设一个服务器的最大处理能力是 $C_{ma x}$ QPS（Queries Per Second），当请求速率 $R$ 超过 $C_{ma x}$ 时，系统会发生什么？

根据排队论（Queueing Theory），系统的平均响应时间 $T$ 与负载率 $ρ = \frac{R}{C _{ma x}}$ 的关系可以用M/M/1队列模型近似：

T = \frac{1}{μ - λ} = \frac{1}{μ ( 1 - ρ )}

其中：

$λ$ 是请求到达率（即 $R$ ）
$μ$ 是服务率（即 $C_{ma x}$ ）
$ρ$ 是系统利用率

关键洞察：当 $ρ \to 1$ 时（即负载接近容量），响应时间 $T \to \infty$ 。这不是线性增长，而是指数级恶化。

真实案例：没有限流的代价

案例1：GitHub API过载事件（2018）

2018年10月，某个流行的CI/CD工具更新后，错误地对GitHub API发起了大量重试请求。在没有合理限流的情况下：

问题客户端在5分钟内发送了超过100万次请求
GitHub的API服务器负载飙升至300%
所有用户的API请求延迟从平均50ms增加到15秒
级联效应导致Web界面也变得不可用

GitHub在事后报告中指出：如果有更细粒度的限流机制，可以在不影响正常用户的情况下快速隔离问题客户端。

案例2：AWS S3限流的必要性

AWS S3对单个前缀（prefix）有默认的性能限制：

3,500 PUT/COPY/POST/DELETE请求/秒
5,500 GET/HEAD请求/秒

这不是人为限制，而是基于存储系统的物理架构。S3在2018年之前没有这个限制，结果是：

热点对象会导致整个分区性能下降
一个客户的流量峰值可能影响同分区的其他客户
系统需要昂贵的重新分片操作

引入限流后，S3的P99延迟从几秒降低到100ms以下。

限流算法：从简单到复杂

让我们从第一性原理构建限流算法，理解每个设计选择背后的权衡。

1. 固定窗口算法（Fixed Window）

最简单的限流算法：在固定时间窗口内统计请求数量。

算法原理

数学表示

设：

$W$ = 窗口大小（秒）
$L$ = 窗口内允许的最大请求数
$C_{t}$ = 当前窗口的请求计数

算法逻辑：

Allow (t) = {true false if C_{⌊ t / W ⌋} < L otherwise

优点

实现简单：只需一个计数器和时间戳
内存开销低：O(1)空间复杂度
性能高：O(1)时间复杂度

致命缺陷：窗口边界突刺

假设限制是100请求/分钟：

时间：    [00:00 ━━━━━━━━━━ 00:59] [01:00 ━━━━━━━━━━ 01:59]
请求分布：           ↑↑↑↑↑↑↑↑↑↑(100)   ↑↑↑↑↑↑↑↑↑↑(100)
实际速率：                     ↑________________↑
                              00:30          01:30
                          200请求/60秒 = 3.33倍限制！

在00:59的最后一秒和01:00的第一秒，系统可能瞬间处理200个请求，是限制的2倍。

真实影响：这种突刺可能导致：

数据库连接池耗尽
内存溢出
下游服务过载

2. 滑动窗口算法（Sliding Window）

为了解决固定窗口的突刺问题，我们需要更平滑的限流。

滑动窗口日志（Sliding Window Log）

记录每个请求的时间戳，滚动统计。

算法逻辑

维护一个时间戳队列 $Q$ ：

Allow (t) = {true false if ∣ {τ \in Q : τ > t - W} ∣ < L otherwise

优点

精确限流：没有窗口边界问题
实时统计：任意时间点都准确

缺点

内存开销大：需要存储所有请求时间戳，O(L)空间
性能开销：每次请求需要遍历清理，O(L)时间

实际数据：

对于1000 QPS的限制，每分钟需要存储60,000个时间戳
假设每个时间戳8字节，内存占用约480KB
对于分布式系统，这个开销会乘以节点数

3. 令牌桶算法（Token Bucket）

令牌桶是最优雅和实用的限流算法之一，被广泛应用于实际系统。

核心思想

想象一个桶，以恒定速率往里放令牌。每个请求需要消耗一个令牌，桶满了新令牌会溢出。

数学模型

设：

$r$ = 令牌生成速率（tokens/秒）
$b$ = 桶容量（最大突发请求数）
$t_{n}$ = 当前令牌数
$T_{l a s t}$ = 上次更新时间

算法步骤：

更新令牌数：

t_{n} = min (b, t_{n - 1} + r \cdot (T_{c u rre n t} - T_{l a s t}))

检查是否允许请求：

Allow () = {true, t_{n} \leftarrow t_{n} - 1 false if t_{n} \geq 1 otherwise

关键特性：支持突发流量

令牌桶的桶容量 $b$ 决定了系统可以处理的突发流量：

平均速率限制：长期来看，请求速率不能超过 $r$
突发容量：短时间内可以处理 $b$ 个请求

示例：

假设 $r = 10$ req/s， $b = 100$ tokens

场景1：平稳流量
时间    0s  1s  2s  3s  4s  5s
请求    10  10  10  10  10  10
令牌    100→0→10→0→10→0→10
结果    ✓   ✓   ✓   ✓   ✓   ✓

场景2：突发流量
时间    0s  1s  2s  3s  4s  5s
请求    0   0   0   150 10  10
令牌    100→100→100→0  10  0
结果    -   -   -   前100✓  ✓   ✓
                    后50✗

参数调优：艺术与科学的结合

问题：如何选择 $r$ 和 $b$ ？

这取决于你的系统特征和业务目标。

原则1：稳态速率 $r$ 应该略低于系统容量

根据利特尔法则（Little's Law）：

L = λ \cdot W

其中：

$L$ = 系统中的平均请求数
$λ$ = 请求到达率
$W$ = 平均响应时间

假设你的系统：

单个请求平均耗时 $W = 10 m s$
希望保持 $L \leq 100$ 个并发请求（避免排队）

则：

r = \frac{L}{W} = \frac{100}{0.01} = 10, 000 req/s

但实际中应该留有安全余量：

r_{a c t u a l} = 0.7 \times r_{t h eore t i c a l} = 7, 000 req/s

原则2：突发容量 $b$ 应该覆盖合理的峰值

分析历史流量数据，计算 $P 95$ 或 $P 99$ 的突发倍数：

b = r \times t_{b u rs t} \times k

其中：

$t_{b u rs t}$ = 典型突发持续时间
$k$ = P99突发倍数（通常2-5倍）

案例：Cloudflare的令牌桶配置

Cloudflare为不同级别的客户配置不同的限流参数：

计划	稳态速率 (r)	突发容量 (b)	设计思想
Free	100 req/s	200 tokens	2秒突发
Pro	1000 req/s	5000 tokens	5秒突发
Enterprise	定制	定制	基于实际容量和SLA

4. 漏桶算法（Leaky Bucket）

漏桶与令牌桶类似，但理念相反：请求进入队列，以固定速率流出。

数学表示

设：

$Q$ = 请求队列，容量 $Q_{ma x}$
$r$ = 固定出队速率

算法：

Enqueue (re q) = {true false if ∣ Q ∣ < Q_{ma x} otherwise

Dequeue () = every \frac{1}{r} seconds

令牌桶 vs 漏桶：哲学上的差异

维度	令牌桶	漏桶
核心机制	生成令牌，消耗令牌	请求入队，固定出队
突发处理	允许突发（桶容量内）	平滑突发到固定速率
响应时间	立即处理或拒绝	排队等待
适用场景	保护自身系统	保护下游服务

真实案例：Nginx的限流选择

Nginx的 ngx_http_limit_req_module 使用的是漏桶算法：

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
    
    server {
        location /api/ {
            limit_req zone=mylimit burst=20 nodelay;
        }
    }
}

rate=10r/s：固定出队速率
burst=20：队列容量
nodelay：不等待，立即拒绝超出部分

这种设计的原因：

Web服务器通常是上游，需要保护下游应用服务器
平滑流量峰值，避免下游过载
简单可靠，不需要复杂的令牌管理

分布式限流：从单机到集群

单机限流很简单，但现代系统都是分布式的。如何在多个节点间协调限流？

挑战：CAP定理的限制

分布式限流面临CAP定理的根本限制：

一致性（Consistency）：所有节点对限流配额的理解一致
可用性（Availability）：限流决策快速，不能阻塞请求
分区容错（Partition Tolerance）：网络分区时仍能工作

你不可能同时拥有三者。实际系统需要权衡。

方案1：中心化限流（CP方案）

使用共享存储（如Redis）作为中心化限流器。

架构

Redis实现：固定窗口

-- Redis Lua脚本：原子性限流
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])

local current = redis.call('INCR', key)
if current == 1 then
    redis.call('EXPIRE', key, window)
end

if current > limit then
    return 0  -- 拒绝
else
    return 1  -- 允许
end

Redis实现：令牌桶

-- Redis令牌桶实现
local key = KEYS[1]
local rate = tonumber(ARGV[1])      -- tokens/秒
local capacity = tonumber(ARGV[2])  -- 桶容量
local now = tonumber(ARGV[3])       -- 当前时间戳
local requested = tonumber(ARGV[4]) -- 请求令牌数

local bucket = redis.call('HMGET', key, 'tokens', 'last_time')
local tokens = tonumber(bucket[1])
local last_time = tonumber(bucket[2])

if tokens == nil then
    tokens = capacity
    last_time = now
end

-- 计算新增令牌
local delta = math.max(0, now - last_time)
local new_tokens = math.min(capacity, tokens + delta * rate)

if new_tokens >= requested then
    new_tokens = new_tokens - requested
    redis.call('HMSET', key, 'tokens', new_tokens, 'last_time', now)
    redis.call('EXPIRE', key, math.ceil(capacity / rate))
    return 1  -- 允许
else
    redis.call('HMSET', key, 'tokens', new_tokens, 'last_time', now)
    return 0  -- 拒绝
end

性能考虑

Redis限流的性能瓶颈：

假设：

Redis单节点性能：100,000 ops/s
每次限流检查需要1次Redis操作
系统总吞吐：100,000 QPS

看起来刚好够用？错。

实际中还要考虑：

网络往返延迟（RTT）：1-5ms
Redis命令执行时间：0.1ms
多个限流维度（用户、IP、API）：3x操作

实际限流开销 = (RTT + 执行时间) \times 操作数

= (2 m s + 0.1 m s) \times 3 = 6.3 m s

对于P99延迟要求50ms的API，限流开销占了12.6%！

方案2：本地限流+定期同步（AP方案）

为了减少延迟，每个节点维护本地限流器，定期与中心同步。

权衡：一致性换性能

设：

$N$ = 节点数
$L$ = 全局限制
$L_{i}$ = 节点i的本地限制
$t_{sy n c}$ = 同步间隔

最坏情况：所有节点同时达到本地限制

L_{a c t u a l} = N \times L_{i}

要保证全局限制，需要：

L_{i} \leq \frac{L}{N}

但这会导致资源浪费：如果某些节点空闲，其配额无法被其他节点使用。

优化：动态配额分配

Google的Doorman系统使用分层配额管理：

中心控制器：管理全局配额
本地限流器：维护租约（lease）
定期续约：根据实际使用动态调整

节点1：使用80% → 请求增加配额 → 获得额外20%
节点2：使用20% → 配额被回收 → 释放60%

方案3：一致性哈希分片

将用户空间分片，每个节点负责一部分用户的限流。

优点

无需中心协调：每个节点独立决策
低延迟：本地计算
高可用：节点故障只影响部分用户

缺点

负载不均：热点用户会集中在某些节点
扩缩容复杂：需要重新分片
跨节点限流困难：全局限流需要额外机制

真实案例：Google的分布式限流

Google在论文"Distributed Rate Limiting at Scale"中描述了其生产环境的限流系统。

设计目标

低延迟：P99 < 1ms
高准确性：误差 < 5%
高可用：99.99% uptime

架构

关键技术：自适应配额

Google的限流器使用加性增-乘性减（AIMD）算法，类似于TCP拥塞控制：

Q_{n e w} = ⎩ ⎨ ⎧ Q_{o l d} + α Q_{o l d} \times β Q_{o l d} if 使用率 > 80% if 检测到违规 otherwise

其中：

$α = 10%$ 的当前配额（加性增）
$β = 0.5$ （乘性减）

效果：

节点在需要时快速增加配额
违规时快速收缩，保护系统
长期来看，配额动态平衡

性能数据

Google的限流系统在生产环境的表现：

指标	数值
吞吐量	1000万+ QPS
P50延迟	0.1ms
P99延迟	0.8ms
全局准确性	误差 < 2%
可用性	99.99%

真实世界的权衡：不存在完美的限流

限流算法的选择不是技术问题，而是业务和工程的权衡。

权衡1：精确性 vs 性能

场景：API限流

假设你的API限制是1000 req/s/user：

方案	精确性	延迟开销	适用场景
Redis中心化	99.9%	2-5ms	严格计费API
本地限流+同步	95%	0.1ms	一般Web API
本地限流（无同步）	90%	0.01ms	高性能服务

决策树：

权衡2：公平性 vs 吞吐

问题：如何处理不同价值的请求？

假设你的系统有两类用户：

免费用户：限制100 req/min
付费用户：限制10,000 req/min

当系统整体过载时，应该：

绝对公平：所有用户按比例降级
分层保护：优先保证付费用户

案例：AWS API Gateway的方案

AWS使用分层限流：

这种设计保证：

免费用户不会影响付费用户
系统整体不超载
商业价值对齐技术资源

权衡3：快速失败 vs 排队等待

漏桶会排队，令牌桶会拒绝。哪个更好？

这取决于用户体验和下游系统：

场景	推荐策略	原因
实时API调用	令牌桶（立即拒绝）	客户端可以快速重试或降级
异步任务提交	漏桶（排队）	用户期望任务最终完成
数据库写入	漏桶（排队）	平滑写入压力，避免锁竞争
前端资源请求	令牌桶（立即拒绝）	浏览器会自动重试

案例：Stripe的API限流哲学

Stripe的API使用令牌桶，并在响应头中提供丰富信息：

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1609459200
Retry-After: 30

这种设计让客户端可以：

知道何时可以重试（Retry-After）
实现智能退避策略
监控自己的配额使用

权衡4：单维度 vs 多维度限流

真实系统通常需要多个维度的限流：

性能考虑：

每个维度的检查都有开销。如果有4个维度，每个维度检查1ms，总开销就是4ms。

优化：短路求值

按照从严到松的顺序检查：

def rate_limit(request):
    # 1. 最严格：用户级别
    if not user_limiter.allow(request.user_id):
        return False
    
    # 2. IP级别（防止滥用）
    if not ip_limiter.allow(request.ip):
        return False
    
    # 3. API级别
    if not api_limiter.allow(request.api_endpoint):
        return False
    
    # 4. 最宽松：全局
    return global_limiter.allow()

实战指南：如何选择和实施限流

步骤1：测量系统容量

在设置限流之前，你需要知道系统的真实容量。

容量测试方法

使用负载测试工具（如Apache Bench、wrk、Gatling）进行压测：

# 使用wrk测试容量
wrk -t12 -c400 -d30s --latency http://api.example.com/endpoint

# 输出分析
Running 30s test @ http://api.example.com/endpoint
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    45.32ms   12.45ms  289.11ms   89.24%
    Req/Sec   738.21     89.43     1.01k    76.15%
  Latency Distribution
     50%   43.21ms
     75%   51.23ms
     90%   61.45ms
     99%  112.34ms
  265234 requests in 30.03s, 89.32MB read
Requests/sec:   8834.21
Transfer/sec:      2.98MB

容量评估：

C_{s a f e} = C_{m e a s u re d} \times 0.7 \times (1 - \frac{P 99 - P 50}{P 99})

其中：

$C_{m e a s u re d}$ = 测试中的最大QPS（8834）
0.7 = 安全系数（预留30%余量）
$(1 - \frac{P 99 - P 50}{P 99})$ = 延迟稳定性因子

对于上面的测试：

C_{s a f e} = 8834 \times 0.7 \times (1 - \frac{112.34 - 43.21}{112.34}) = 6184 \times 0.615 = 3803 req/s

建议限流配置：3500-4000 req/s

步骤2：分析流量模式

不同的流量模式需要不同的限流策略。

流量模式分类

案例：电商网站的限流策略

假设一个电商网站的日常流量分析：

时间段	平均QPS	P99 QPS	特征
凌晨(00:00-06:00)	1000	1200	平稳低谷
工作时间(09:00-18:00)	5000	7000	平稳高峰
晚高峰(20:00-22:00)	8000	15000	高突发
秒杀活动	50000	100000	极端突发

分层限流策略：

# 伪代码
def get_rate_limit(hour, is_flash_sale):
    base_config = {
        'night': {'rate': 2000, 'burst': 3000},
        'work': {'rate': 8000, 'burst': 12000},
        'peak': {'rate': 12000, 'burst': 20000},
    }
    
    if is_flash_sale:
        # 秒杀活动：更大的突发，但严格的用户级限流
        return {
            'global': {'rate': 50000, 'burst': 100000},
            'user': {'rate': 10, 'burst': 10},  # 每用户10 req/min
            'ip': {'rate': 100, 'burst': 100},   # 每IP 100 req/min
        }
    
    if 0 <= hour < 6:
        return base_config['night']
    elif 9 <= hour < 18:
        return base_config['work']
    else:
        return base_config['peak']

步骤3：实施和监控

限流不是"一次配置，永久有效"。需要持续监控和调整。

关键监控指标

# 监控指标定义
metrics = {
    'rate_limit_hit_ratio': '被限流的请求占比',
    'rate_limit_by_dimension': '各维度限流分布',
    'p99_latency_with_rate_limit': '限流后的P99延迟',
    'false_positive_rate': '误杀率（正常用户被限流）',
    'capacity_utilization': '容量利用率',
}

告警规则

# Prometheus告警规则示例
groups:
- name: rate_limit_alerts
  rules:
  # 限流率过高
  - alert: HighRateLimitRatio
    expr: rate_limit_hit_ratio > 0.05  # 超过5%
    for: 5m
    annotations:
      summary: "过多请求被限流"
      description: "{{ $value }}% 的请求被限流"
  
  # 容量利用率过低（限流过严）
  - alert: UnderutilizedCapacity
    expr: capacity_utilization < 0.5  # 低于50%
    for: 15m
    annotations:
      summary: "系统容量利用不足"
      description: "当前利用率仅 {{ $value }}%"
  
  # 限流器延迟过高
  - alert: RateLimiterHighLatency
    expr: histogram_quantile(0.99, rate_limiter_duration_seconds) > 0.01
    for: 5m
    annotations:
      summary: "限流器P99延迟过高"
      description: "P99延迟 {{ $value }}s"

步骤4：用户体验优化

限流不应该是突然的"墙"，而应该是渐进的反馈。

优雅降级策略

案例：Twitter的限流响应

Twitter的API在接近限流时会主动提示：

HTTP/1.1 200 OK
X-Rate-Limit-Limit: 180
X-Rate-Limit-Remaining: 10
X-Rate-Limit-Reset: 1609459200
Warning: "Approaching rate limit, 10/180 requests remaining"

当完全达到限流：

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded",
    "rate_limit": {
      "limit": 180,
      "remaining": 0,
      "reset": 1609459200,
      "reset_relative": "in 1 minute"
    }
  }]
}

关键设计：

渐进式警告：在达到限流前提醒
详细的元数据：告诉用户何时可以重试
人性化的消息："in 1 minute" 而非时间戳

限流的局限性：它不是银弹

诚实地讨论限流的局限性，比盲目吹捧更有价值。

局限性1：无法防御分布式攻击

限流可以阻止单个IP的滥用，但无法防御分布式拒绝服务攻击（DDoS）。

假设你的限流配置：

单IP限制：1000 req/min
全局容量：100,000 req/min

攻击者使用100个不同IP，每个发送1000 req/min：

总攻击流量 = 100 \times 1000 = 100, 000 req/min

限流无效，因为每个IP都在限制内，但总流量刚好达到系统容量。

解决方案：需要更智能的机制：

行为分析：检测异常模式
验证码：人机验证
CDN/WAF：在边缘过滤

局限性2：无法处理合法突发

有些业务场景天然就有巨大突发：

案例：Apple的App Store

当Apple发布新系统更新时：

全球数亿设备同时检查更新
流量在几分钟内暴增1000倍
传统限流会拒绝大量合法请求

Apple的解决方案：

分批推送：按地区、设备型号分批
随机化延迟：客户端随机等待0-30分钟
CDN缓存：99%的请求命中缓存

启示：限流要结合业务逻辑，不是简单的数学公式。

局限性3：复杂性成本

分布式限流系统本身也有成本：

组件	复杂度	维护成本
Redis集群	中	中
限流配置管理	高	高
多维度协调	高	高
监控告警	中	中

问题：对于小团队，限流系统的维护成本可能超过收益。

务实建议：

小型项目：使用Nginx的内置限流
中型项目：Redis + 简单令牌桶
大型项目：分布式限流系统

总结：限流是理性的艺术

限流不是技术炫技，而是保护系统稳定性的理性工具。

核心要点

理解数学原理
- 排队论告诉我们系统容量的非线性特性
- 不同算法适合不同场景，没有银弹
权衡而非绝对
- 精确性 vs 性能
- 公平性 vs 吞吐
- 一致性 vs 可用性
数据驱动决策
- 测量实际容量
- 分析流量模式
- 持续监控调整
承认局限性
- 限流无法防御所有攻击
- 无法处理所有业务场景
- 需要权衡复杂性成本

实践清单

在实施限流时，问自己这些问题：

我测量过系统的真实容量吗？
我分析过流量的模式和特征吗？
我选择的算法匹配业务特征吗？
我考虑过用户体验吗？
我有监控和告警机制吗？
我的限流配置会定期审查和调整吗？

最后的思考

限流的价值不在于算法有多复杂，而在于它是否合理地保护了系统，同时提供了良好的用户体验。

一个设计良好的限流系统应该：

平时无感知：大多数用户永远不会触发限流
过载时公平：按照业务价值合理分配资源
异常时稳定：保护系统不被压垮

这不是纯技术问题，而是数学、工程和商业智慧的结合。

如果你对限流有不同的见解或实践经验，欢迎在评论区讨论。技术的进步来自于不同观点的碰撞。

参考文献

Ananian, C. Scott. "The Token Bucket Algorithm." MIT Course Notes, 1995.
Google. "Distributed Rate Limiting at Scale." Google Research, 2021.
AWS. "Amazon API Gateway Throttling." AWS Documentation, 2023.
Cloudflare. "Rate Limiting in Production Systems." Cloudflare Blog, 2022.
Kleinrock, Leonard. "Queueing Systems, Volume 1: Theory." Wiley, 1975.