限额和配额

利率极限和配额是管理共享资源需求的基本机制：CPU，网络，DB，队列，外部API。目标是公平（公平性），SLO的可预测性以及防止激增，滥用和"无声邻居"。

1）基本概念

利率限制-限制请求/操作强度（req/s, msg/min,字节/秒）。
Burst是允许的短期激增，超过平均水平。
Quota是每个时间窗口（文档/每天，GB/月）的数量限制。
Concurrency cap-限制并发操作（并发查询/job）。
Scope是一个应用领域：per-tenant，per-user，per-token，per-endpoint，per-IP，per-region，per-feature。

2）限制算法

2.1 Token Bucket（带令牌的水桶）

参数："rate"（令牌/秒）、"burst"（桶大小）。
作为"信用"工作：累积的令牌允许短峰。
适用于外部API和自定义查询。

2.2 Leaky Bucket（漏水桶）

以恒定的速度"平稳"流。
有利于平滑交通到敏感的后端。

2.3 Fixed/Sliding Window

固定窗口：简单但容易受到"窗口切换"的影响。
滑动窗口：更准确,但计算成本更高。

2.4 GCRA (Generic Cell Rate Algorithm)

就虚拟到达时间而言，相当于Token Bucket。
对于分布式限制器（较少冲突的状态），准确且稳定。

2.5 Concurrency Limits

限制同时执行的操作。
防止流/连接池和"线头块"耗尽。

3）在哪里应用限制

在边界（L7/API网关）：主要障碍,快速故障（429/503）,低成本检查。
在服务内部：重型操作（导出，报告，转化）的额外上限。
进入外部系统：第三方的个人限制（反卑鄙的）。
在队列/枪手：公平到共享池。

4） Scoops和优先级（multi-tenant）

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.

Priority-aware：VIP/Enterprise获得更大的"爆破"和重量，但不打破一般的SLO。
极限组成：最终公差='min（全球，区域，影子，定制，末尾）'。

5）数量配额

每日生活津贴/月份配额：每日文件、GB/月报告、/分钟报告。
软/刚性阈值：警告（80/90％）和"硬性停止"。
滚动：按对象（表、文件、事件）和"删除"计费。

6）分布式限量版

要求：低延迟、一致性、抗故障、水平扩展。

Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).

本地+probabilistic sync：本地shard水桶+周期同步。
Sharding：具有均匀分布的'limit： {scope}视图键：{id} {window}。
Clock skew：在限制服务器而不是客户端中存储"真相"。
相似性："操作"键（Idempotency-Key）减少了虚假注销。

7）防暴和防守

用于公共残局的Per-IP+设备指纹。
异常情况下的工作证明/CAPTCHA。
当UX更重要时，Slowdown（throttling）代替完全故障（搜索提示）。
Adaptive limits：在事件/昂贵的退化中动态降低阈值。

8）客户行为和协议

编码："429 Too Many Requests"（rate），"403"（超过配额/计划），"503"（保护性降解）。

• "Retry-After： "-何时再次尝试。

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff：指数+jitter （full jitter, equal jitter）。
• 相似性：标题"Idempotency-Key"和安全操作的可重复性。
• 超时和取消：正确地打断暂停的请求，以免被"捕获"限制。

9）可观察性和测试

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).

指标：带宽、429/403/503故障率、p95/p99延迟限制、密钥缓存的命中率、按计划分配。
审核日志：块的原因,顶部"嘈杂"的密钥。
测试："pila/burst/plateo"负载配置文件，混乱-Redis/shard故障，时钟同步。

10）与计费集成

Usage计数器在边界处组装，由batchas（每N分钟）以等容性聚集。
计划摘要：超支→超支或计划临时升级。
差异：usage与invoice的对账；在三角洲。

11） Fairness内部（队列,workers）

重量公平测验/DRR：按计划重量在租户之间分配插槽。
工作池：硬绝缘VIP/噪音。
管理控制：如果配额用尽，则在执行前拒绝；队列不会膨胀。
Caps on concurrency：限制同时重型乔巴。

12）示例计划简介（示例）

yaml plans:
starter:
rate: 50  # req/s burst: 100 concurrency: 20 quotas:
daily_requests: 100_000 monthly_gb_egress: 50 business:
rate: 200 burst: 400 concurrency: 100 quotas:
daily_requests: 1_000_000 monthly_gb_egress: 500 enterprise:
rate: 1000 burst: 2000 concurrency: 500 quotas:
daily_requests: 10_000_000 monthly_gb_egress: 5000

13）建筑基准（言语方案）

1.Edge/API网关：TLS →检索上下文（tenant/plan） →检查限制/配额→标题RateLimit-→ log/trace。
2.策略引擎：优先级规则（VIP）,自适应阈值。
3.Limiter Store： Redis/KeyDB （atomic ops, LUA）,键卡,复制。
4.服务：重型手术的二级限制和上限；等效性；WFQ/DRR队列。
5.Usage/Billing：收集、汇总、发票、阈值差。

6.Observability： 标记度量/logi/traces, dashbords per-tenant.

14）售前支票清单

• 定义了极限标记（tenant/user/token/endpoint/IP）及其层次结构。
• 选择了算法（Token Bucket/GCRA）和"rate/burst"参数。
• 实现了用于重型操作的concurrency caps和admission control。
• 包括标题"RateLimit-"和"Retry-After"；客户端支持backoff+jitter。
• 限制是分布式且具有抗故障性（shards,复制,降级）。
• Usage收集是偶数的；与计费挂钩，超支。
• 可观察性：标记度量/预告片/标记，前"嘈杂"键，alerter's。
• 测试：bursts，"pila"，stor故障，clock skew，冷启动。
• 客户文档：计划限制，示例429/Retry-After，最佳实践中继。
• 例外政策：如何暂时提高限制以及何时。

15）典型错误

没有per-tenant/per-endpoint的全球限制-"噪音邻居"打破了所有SLO。
缺乏"爆破"：UX短暂爆发。
仅使用固定窗口→"在窗口边界处双击"。
在重播风暴→，没有静止和静止。
限制仅在边界上，服务/队列中没有caps →内部的"塞子"。
在响应中未排出限制（没有"Retry-After"，"RateLimit-"）→客户无法适应。
将限制状态存储在OLTP DB中→高潜伏期和"热"锁定。

16）快速选择策略

具有峰值的公共API：Token Bucket+大型"爆破"，RateLimit是标题，CDN/edge kesh。
内部重型jobs：concurrency caps+WFQ/DRR，管理控制。
与第三方的集成：单独的输出，缓存/回收限制。
SaaS多重性：限制层次结构（global→tenant→user→endpoint），VIP优先级，每月配额。

二.结论

良好的评分限制和配额是平台与客户之间的系统合同：公平的资源份额，抗激增性，可预测的SLO和透明的计费。结合算法（Token/GCRA+concurrency caps）、实施鱼鹰层次结构、提供清晰的标题和指标,并定期检查真实流量配置文件下的电路-即使负载激增,该平台仍将保持稳定。