|
|
d072a03c9a
|
perf(gateway): 配额桶扫描改为窗口化 + pinned 桶惰性创建
审查本特性线的性能时发现两个问题，均有实测数据。
## 1. 窗口查询是全扫，代价落在每个请求上
sumBuckets 原来遍历整个 map（最多 960 个小时桶），实测 5.9us/op。
配额检查在每个请求上跑 2-3 次（key 总 token、key 请求数、scope token），
于是单请求多付约 18us。
注意这**不是本改动引入的成本**：main 上既有的 WindowTokens 同样是
5907ns/op（全扫）。是本改动让它在请求路径上被调用得更多。
改为只遍历窗口可能覆盖的桶（键是整点小时，范围是精确的，不是采样）：
- 24h 窗口 200ns -> 55ns
- 1h 窗口 80ns -> 49ns
- 30d 窗口 5.9us -> 3.9us（720 次查找，只有配 month 配额时才走到）
等价性由 TestSumBucketsMatchesFullScan 保证（400 组随机桶位置 x 6 种
窗口，对全扫逐项比对）。★ 第一次写错成 floor，判据立刻抓到：
30 天窗口报 8878 而全扫是 8649 —— 正确是 ceil。
## 2. pinned 桶无条件创建，内存最坏 26.7MB
每条记录写两个桶：裸 model 与 "source::model"。但 pinned 桶只有
「配额里显式 pin 了 source」时才会被查。
实测最坏情况（20 key x 8 model x 3 source x 40 天全 retention）：
HeapAlloc 26.67MB —— 而 README 宣传「16 源生产实例 ~32-35MB」，
等于吃掉 80% 内存预算。
改为惰性：只有 KeyWindowModelTokens 带 source 查询过某个 (key, model)
之后，才开始维护它的 pinned 桶。
20key x 8model x 3src 26.67MB -> 8.87MB (-67%)
5key x 6model（真实） 3.36MB -> 2.26MB (-33%)
5key x 12model 5.82MB -> 3.59MB (-38%)
代价：配 pinned 配额之前发生的用量无法事后按源拆分（记录里虽然有
Source，但桶只存了裸 model），所以 pinned 配额的首个窗口可能少算。
已在代码注释与判据中写明。
## 其余实测
Record main 基线 275ns/429B/3allocs -> 283ns/429B/3allocs
（+8ns，分配数不变；3 allocs 来自 ring buffer）
配额检查全路径 115ns / 0 allocs（每请求新增）
纯读路径 6.5ns / 0 allocs
## 100 并发调度/拒绝压测（真实进程 + 可报并发峰值的假上游）
容量 100（4+96），0.15s/请求，100 并发 ok=100 fail=0 上游峰值 42
容量 100，0.15s/请求，200 并发 ok=200 fail=0 上游峰值 97
容量 8，3s/请求，100 并发 ok=8 fail=92 上游峰值 8
容量 8，0.6s/请求，100 并发 ok=32 fail=68 上游峰值 8
容量 8，0.6s/请求，40 并发 ok=32 fail=8 上游峰值 8
上游峰值恒定不超过 max_concurrent，容量拒绝返回 503 + busyWait 有界
等待（约 2.6s）。main 基线在同条件下 ok=32 fail=68、上游峰值 8、
延迟分布相同 —— 配额改动没有触碰调度/拒绝路径。
配额拒绝单独验证（低并发避开容量拒绝）：req_quota=50 用尽后
100 并发全部 429 rate_limit_exceeded + Retry-After: 1661，
**延迟仅 19-21ms**、上游 total 未增加 —— 配额在入口廉价拒绝，
不占用任何上游槽位，与容量不足的昂贵等待形成明确分工。
## 判据
key_quota_perf_test.go：4 个基准 + 2 个判据（sumBuckets 等价性、
pinned 桶惰性）。3/3 变异全被抓（无条件建 pinned 桶、firstHour 用
floor、keyHour 不再写）。
(cherry picked from commit be11a06a46)
|
2026-09-27 18:44:41 +08:00 |
|
|
|
9c3aabb7f9
|
feat(gateway): per-key 用量配额（token + 请求数）与重置周期
问题：密钥控制只能限制模型范围。实测发现三个缺陷，其中前两个让
per-model token_quota 在真实链路上从未生效：
1. 桶键不含 key。scopeTokens 调 WindowTokens(model, source, win)，
桶键是 model / source::model，与调用方无关。实测两把 key 各用
1000 token，窗口报 2000 —— A key 的额度被 B key 消耗。
2. 无 source pin 的桶永远是空的。真实记录 Source 总被填上，桶键存成
"deepseek::m1"，而无 pin 的查询找 "m1" —— 读到 0，永远 < quota，
配额形同虚设。实测 WindowTokens("m1","",1h)=0 而 pinned=2000。
3. AUTO scope 走 KeyTokens(key)，是全时段累计、永不重置。实测 30 天
前的 200 token 仍计入 1 小时配额（报 210 而非 10）。配了
period: hour 也不会每小时归零。
生产 5 把 user key 全是 token_quota: 0，所以前两条一直没暴露。
改动：
- Stats 新增 per-key 小时桶 keyModelHour（key → model → hour）与
keyHour（key 总量）、keyReqHour（请求数），retention 40 天，与既有
modelHour 对齐以覆盖最长的 month 窗口；LoadAudit 走 aggregateLocked，
所以窗口用量跨重启存活。modelHour 保持 key-blind：它服务的是 AUTO
槽位配额（限制整个网关对某槽位的消耗），语义不同，不应被 per-key
改造污染。
- 每个请求写两份模型桶：裸 model 与 source::model。无 pin 的 scope
条目读前者，有 pin 的读后者。
- GWKey 新增 TokenQuota / ReqQuota / Period / Hours：整钥配额，
跨该 key 所有模型共享一份预算；ReqQuota 覆盖持续请求量（源上的
RPM 只管突发）。
- 配额耗尽返回 429 + Retry-After（rate_limit_exceeded），而不是 403：
403 让客户端以为这把 key 永远不能用该模型，直接放弃；429 + 等待
才能在窗口重置后自动恢复。模型越权仍是 403。
- admin key 永不受配额限制 —— 否则操作者会把自己锁在门外。
- 周期词表在写入时校验，拼错的 period 被拒绝而不是静默当成永不过期
（那与操作者输入的意图正好相反）。
- PUT /api/keys 的配额字段是指针：省略=保留原值，显式 0=解除限制。
否则只改模型范围就会悄悄清空预算。
判据 3 个文件 24 例，9 个变异全部被抓：key 隔离、pin 桶缺失、
AUTO 周期、key-blind 退化、429→403、admin 被限、PUT 清空配额、
Validate 失效、pinned 桶缺失。前三个变异最初漏网 —— 判据只测了
Stats 层没测接线，补了走真实 HTTP 的接线层与 API 层判据后抓住。
端到端验证：真实进程 + 加密配置往返，配额字段与 enc:v1 密钥均正常。
(cherry picked from commit 5306251840)
|
2026-09-27 18:44:41 +08:00 |
|
