《WaLiAPI - 本地 LLM API 网关》第1-5节：负载均衡调度器

作者：小傅哥
博客：https://bugstack.cn (opens new window)

沉淀、分享、成长，让自己和他人都能有所收获！😄

大家好，我是技术UP主小傅哥。

前面几节我们有了数据库和渠道适配器。现在问题来了：当用户配置了多个渠道都能服务同一个模型时，请求应该发给谁？ 这就是调度器（Dispatcher）要解决的问题——负载均衡 + 故障转移。

一、本章诉求

1. 理解负载均衡的常见策略及其适用场景
2. 实现"模型匹配过滤 → 优先级分组 → 组内权重随机"的调度算法
3. 构建有序的故障转移队列（failover queue）
4. 实现 Channel → ChannelConfig 的转换方法

二、负载均衡策略选型

2.1 常见策略对比

策略	原理	优点	缺点	适用场景
轮询（Round Robin）	依次轮流	绝对均匀	无法区分渠道能力差异	同构后端
随机	纯随机选择	简单	分布不可控	简单场景
权重随机	按权重概率选择	流量按比例分配	实现稍复杂	异构后端
最少连接	选当前连接最少的	动态均衡	需要维护状态	长连接
优先级故障转移	只用最高优先级，失败降级	主备清晰	低优先级闲置	主备架构

2.2 WaLiAPI 的选择

WaLiAPI 的使用场景有这样的特点：

1. 主备需求：用户可能想"优先用 DeepSeek（便宜），DeepSeek 挂了自动切 OpenAI（兜底）"→ 需要优先级
2. 分摊需求：用户可能有 3 个 OpenAI Key（不同账号），想按 5:3:2 分摊请求 → 需要权重
3. 无状态：桌面应用不维护长连接计数，调度应该是无状态的纯函数 → 权重随机而非轮询

所以我们采用 "优先级分组 + 组内权重随机" 的混合策略：

请求 gpt-4o
   │
   ↓ 过滤：状态启用 且 支持该模型
┌─────────────────────────────┐
│ 优先级 10: [OpenAI-A(w:5), OpenAI-B(w:3)]  ← 先尝试这组，组内 5:3 概率
│ 优先级 5:  [DeepSeek(w:1)]                 ← 上面全失败后尝试
│ 优先级 1:  [Ollama(w:1)]                   ← 最后兜底
└─────────────────────────────┘
   │
   ↓ 输出有序队列
[OpenAI-A/B(随机序), OpenAI-B/A, DeepSeek, Ollama]
   │
   ↓ Proxy 层按顺序尝试，直到成功或耗尽