一、限流的三种流派
当大模型请求量超过后端处理能力时，限流不可避免。业界常见做法有三种：
- 直接拒绝：返回 429，简单粗暴，用户体验差。
- 额度计数：控制每天或每段时间的使用次数，超限报错。
- 排队等待 + 进度展示：请求进入有序队列，客户端实时展示排名和预估等待时间，排到后自动继续。
我们选择了第三种。这不仅仅是一个队列，而是一个包含优先级编码、动态限速、抢占调度、存活检测、SLA 熔断等机制的完整生态。
二、存储：Redis Sorted Set 双队列
每个模型维护两个 Redis Sorted Set：主队列（score 编码优先级和时间戳，决定排队顺序）和心跳队列（score 为最近一次心跳时间戳，用于存活检测）。入队和出队通过 Lua 脚本原子操作两个 ZSet，保证一致性。
后台定时清理两层过期数据：一是时间戳超时的请求（已超过最大排队时间），二是心跳超时的请求（客户端已断开连接）。心跳队列还有独立的兜底清理，处理残留。
大 Key 问题：当前每个模型一个 ZSet，高峰期可能积压上万请求。可以通过一致性哈希将单个 ZSet 拆分为多个 shard，入队按 hash 路由，查排名跨 shard 聚合。
三、优先级编码：53-bit 位图
Redis ZSet 的 score 是双精度浮点数，精确整数上限 2^53。我们在 53 bit 内编码了多个优先级维度，低 44 位存放毫秒级时间戳。
所有优先级位使用”0 = 高优先级”约定，score 越小越靠前，天然利用 ZSet 的排序特性。
会话级”插队”机制
同一编程会话内的连续请求不会每次排到队尾。重试请求完全继承上次时间戳；连续请求在上次时间戳基础上加一个小偏移量，保持接近但不完全相同的排名。这避免了用户因连续交互而反复被”惩罚”。
四、主流程
请求到达后先尝试快速放行：如果队列很短且 QPM 令牌可用，直接通过不入队。否则计算优先级 score 后入队，进入轮询出队循环。
轮询中做五件事：刷新心跳、查排名、检测用户权益变化、按排名远近调整轮询频率（自适应间隔，离队头远的请求降频轮询以节省 Redis 负载）、通过 SSE 推送排名和预估等待时间。
到达队头且拿到 QPM 令牌即出队放行。
五、QPM 管控：五层配额叠加
出队速率由五个子系统从低到高叠加决定：
- 静态配置：基础 QPM。
- 动态 QPM：根据队列长度自适应调节，队列短时降速节省资源，积压时提速。
- 抢占式调度：同一资源池内的多个模型，闲置模型的 QPM 自动借给繁忙模型，严格守恒——
∑EffectiveQPM == TotalCapacity，不会凭空创造或销毁容量。高优先级层先借，同层内按等待压力分配。 - SLA 调节器：基于模型健康分数线性压缩 QPM。使用非对称 EMA 平滑——下降方向快速响应故障（α=0.5），上升方向谨慎恢复（α=0.2）。支持递进衰减（SLA 持续不恢复时逐轮压低上限）和渐进恢复（SLA 回升时按步进比例靠近原始配置）。即使模型判定为 Dead，也保留最小探测流量。
- 增速控制：限制分钟级 QPM 增长幅度，防止模型从低流量瞬间跳到高 QPM 造成上游雪崩。
六、出队限流器：双引擎热切换
限流算法支持 GCRA 和滑动窗口两种，可通过配置热切换。切换时通过影子双写保证平滑：主算法放行后同步写入备用算法的状态，确保切换瞬间新算法窗口内已有完整计数，零突刺。
七、队头阻塞缓解
当队头请求因 QPM 限流长时间无法出队时，所有后续请求都被阻塞。缓解方案：到达队头后连续多次拿不到令牌时触发强制出队，绕过 QPM 限流放行。付费用户触发阈值更低。强制出队本身有独立的速率保护，防止泄压阀失控。
八、总结
这套排队系统的核心特色：
- 53-bit 位图优先级：一个数字编码多个维度 + 时间戳，天然利用 ZSet 排序。
- 会话连续性：连续请求通过时间戳继承避免反复排到队尾。
- 五层 QPM 叠加：静态配置 → 动态调节 → 资源池借调 → SLA 熔断 → 增速控制，每层解决一个维度。
- 抢占调度守恒：资源池内 QPM 动态流转，总量始终不变。
- 非对称 EMA：快降慢升，符合渐进式容错理念。
- 限流热切换 + 影子双写：配置变更即可无缝切换算法，零突刺。
- 队头阻塞泄压：强制出队 + 差异化阈值。