rate limiter's设计

1）为何评分限制

Rate limiting保护API的可用性和经济性：停止盗版，"盗版"抢购，保护昂贵的交易（现金交易，报告生成），平滑依赖系统（DB/提供商）的负担。良好的设计提供了公平性（公平性），潜伏性的可预测性和清晰的SLO。

关键目标

RPS稳定性和后端过载保护。
受控的"弹性"（爆发）。
客户区分（per-User/per-Organization/per-Key/per-IP/per-Region）。
成本模型：不同交易的"价格"不同。

2）限制类型

RPS限制：每秒/分钟查询。
配额：每个月的总预算。
竞争力：同时操作（checkout, heavy job）。
速度/条带：字节/秒（加载/卸载）。
加权限制：复杂性查询的"成本"（例如GraphQL复杂性，batch大小）。
适应性：在异常情况下（可疑活动/错误401/403/5xx）收紧。

3）算法以及何时应用

3.1 Fixed window counter

简而言之：每个间隔的计数器（例如100 r/min）。
优点：最低成本。缺点：窗户边界上的"边缘条纹"。

时间：海军上将面板，精度低，成本低。

3.2 Sliding window (log / counter)

Log：存储最新查询的时间戳,准确,内存路径。
Counter：平均两个相邻窗口（滚动）,精度和价格权衡。

时间：公共平均流量的API，需要平稳而没有复杂的数学。

3.3 Token bucket

参数：速度'r'（令牌/秒）和容量'b'（爆破）。每个请求"燃烧"令牌。
优点：自然爆发，简单的实现。缺点：没有严格的均匀性。

时间：如果需要"b"内的"齐射"，几乎总是用于RPS。

3.4 Leaky bucket (drip)

以固定速度"泄漏"的队列。
优点：水平输出流。缺点：更多延误。

时间：平滑到外部"脆弱"提供商。

3.5 GCRA (Generalized Cell Rate Algorithm)

• "TAT_next=max（TAT_current，now）+1/r"，如果"now<=TAT_current+burst/r"，则接受该请求。
• 优点：严格，准确，几乎没有记忆（通过键存储TAT）。缺点：难以理解。

时间：需要严格的控制和流畅，分布式限制。

3.6竞争信号灯

活动操作计数器；入场-如果有"门票"；出路-释放。
时间：长运行操作,线程,WebSocket,下载。

4）限制密钥模型

• `client_id`/`api_key`/`user_id`/`org_id`
• 'IP/ASN/geo'（粗略保护）
• 'endpoint/method'（热线）
• "scope/plan/tier"（货币化）
• "idempotency_key"（写操作）
• 使用层次结构：首先是严格的per键,然后是per组织,然后是全局。

5）请求权重（成本模型）

• GraphQL：跨领域的复杂性×深度。
• REST：响应/请求的大小，操作类型（read=1，write=3，报告=10）。
• Batch: `cost = min(n, cap)`.
• 我们限制令牌而不是"查询"："budget-=cost （q）"。

6）分布式实现

6.1个存储

进程：超快，但不一般限制（适用于本地"软"限制）。
Redis：事实上的标准。INCR/EXPIRE，Lua脚本（原子性），用于滑动窗口的ZSET，TTL键。
Envoy/NGINX/Kong/Traefik：嵌入式过滤器；方便周边。
Service Mesh： sidecar+全局同步的本地限制。

6.2原子性和赛车

Lua in Redis：验证和嵌入一个步骤。
GCRA：存储一个带有CAS/脚本的 TAT。
时钟一致性：NTP，单调计时器。
Sharding：按键一致哈希；避免"热"沙丁鱼。

6.3地理分布

区域集群上的本地限制+全局顶部（coarse）。
CRDT/复制-小心（延迟、双流量）。区域库存限制是可取的。

7）政策和优先级

计划：Free/Pro/Enterprise具有不同的"r"，"b"配额。
优先级："昂贵"路线获得较小的限制或更大的成本。
列表：allow-list for integrations, deny by ASN/proxy/TOR。
升级：如果再次超出-我们降低限制，我们引入工作证明/kapchu/挑战。

8）Configs示例

8.1 Envoy （HTTP限制过滤器,伪）

yaml rate_limit:
domain: public-api descriptors:
- key: api_key rate_limit:
unit: second requests_per_unit: 50 burst: 100
- key: api_key value: payments. write rate_limit:
unit: second requests_per_unit: 5 burst: 10

8.2 NGINX （lua+Redis, pseudo）

nginx lua_shared_dict limits 10m;

location /api/ {
access_by_lua_block {
local key = ngx. var. arg_apikey.. ":".. ngx. var. request_method.. ":".. ngx. var. uri
-- token bucket in Redis (evalsha)
local allowed, retry_after = ratelimit_allow(key, 50, 100) -- r=50/s, b=100 if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}
proxy_pass http://backend;
}

8.3竞争限制（伪代码）

pseudo on_request_start(key):
if redis. incr_with_ttl("sem:" + key, ttl=60) > MAX_CONCURRENCY:
redis. decr("sem:" + key); reject(429)
on_request_finish(key):
redis. decr("sem:" + key)

8.4 GCRA（伪代码）

pseudo params: r tokens/sec, burst b tat = redis. get(key) or now allowed_time = tat - (b / r)
if now < allowed_time: reject(429, retry_after = allowed_time - now)
tat_next = max(tat, now) + 1/r redis. set(key, tat_next, ttl = ceil(b/r) + safety)

9）与retrais、taymout和circuit breaker整合

Retry-budget：将转发份额限制在主流量的X%。
Jitter：在backoff时,始终添加jitter-减少同步爆发。
巡回赛决胜局：在高谬误（'5xx'，timeouts）下，降低限制或将部分路线转换为"只读"。
刺伤：整洁；考虑到成本，以免预算支出增加一倍。

10）可观察性和控制

Метрики: `rps_allowed`, `rps_blocked`, `429_rate`, `retry_after_avg`, `burst_used`, `quota_remaining`, `active_concurrency`.

标签：通过限制键，区域，结束点，计划。
解决方案逻辑（采样）：故障原因，当前计数器，密钥的TTL。
Dashbords：按钥匙/残局计算的热卡，"热门"客户。
Alerts：在关键路线上增长429>2-5%,经常出现"用尽"配额,沙丁鱼失衡。

11）测试和验证

合同策略测试（如果有的话，表）。
负载：bursts（x 10 from r），长高原，"脏"模式（慢开机，长连接）。
混沌流量：不均匀的流，时钟漂移，Redis/mesh影响。
A/B开启：在开启之前,加那利滚动限制,阴影解决方桉（我们计算但不锁定）。

12） Edge桉例和复杂性

Clock skew：使用单一来源（服务器）的"now（）"而不是客户端标题。
Idempotency-Key：对于write-减少在后退时的放大。
击球操作：限制击球的大小和总费用。
Long-poll/WebSocket：限制频道/订阅次数和持续时间。
冷启动：计数器/预装的"温暖"开始；否则，假爆发429。
计算上昂贵的查询：在运行业务逻辑之前限制。
TTL：TTL密钥边界必须覆盖窗口+库存（安全马尔金）。

13）反机器人升级

步骤：警告→ 429+"Retry-After" → challenge（kapcha/pazl）→临时单元。
信号：设备指纹,游标行为/时间,TOR/代理/托管。
策略必须具有确定性，并且可以复制用于伪装。

14）安全和合规性

Deny-by-default在关键路线（写作/财务）。
审计：为监管桉例和事件分析保留限额解决方桉。
PII：限制密钥不得在日志中披露个人数据。

15）准备就绪支票清单

• 已定义限值键和成本模型。
• 选择了算法（token bucket/GCRA）和存储（Redis/网关）。
• 客户级别政策+全球"保险丝"。
• 长期运营的竞争限制。
• Retry-budget, backoff with jitter,与circuit breaker集成。
• Dashbords/Alerts，采样决策日志。
• 金丝雀启用和影子模式。
• Burst测试，漫长的高原，Redis失败，clock skew。
• 客户文档：代码429，"Retry-After"，指数备份示例。

16) TL;DR

使用带有Redis/网关的 token bucket或GCRA，设计限值键和查询成本，添加竞争性信号灯以进行长时间的操作，与复古预算和电路破解器集成，监视429和"暴风雨容量"，通过金丝雀/影子展开限值，并确保测试暴风雨以及存储故障。