mirror of
https://gitcode.com/JianFeeeee/webui4frpc.git
synced 2026-10-15 12:14:37 +00:00
875e5805eb
用户提出「加负载均衡算法，定期重新分配任务」。本提交只落**决策**部分： 给定当前环快照，算出「该不该迁、迁哪条、迁给谁」。运行时接线未包含在内。 ## 决策规则（刻意保守） - **阈值**：某节点 Score 超过均值 minOverRatio 倍，且与最闲节点相差**至少一条转发的量** （Score 里 Forwards 权重 100，所以差 <100 视为噪声）——避免为 1% 的差异重启 worker - **一次一条**：负载抖动时不会引发一批 worker 同时重启（每次迁移都断活跃连接） - **不动停用的转发**：迁走 disabled 的转发等于把用户明确关掉的东西重新拉起来 - **不动 offline 节点**：否则会迁到一台不存在的机器上 - **完全均衡时返回"无事可做"**：这就是阈值触发的意义——健康环零开销 ## 尚未实现（本提交不含） 1. **持续时间判定**：阈值命中需持续 N 分钟才动手，避免瞬时尖峰触发迁移。 当前 planBalance 是无状态的，时间维度留给调用方的 BalanceTracker。 2. **两阶段提交**：这是**安全性关键**，不能简单地把 RevokeTask 与 SubmitTask 一起发出去。实测 PendingList 按 `t<ID>` 字符串排序（`t10 < t5`），同轮内 顺序不可控；且旧 owner 停掉 worker 后自己的 Load 立刻下降，很可能又成为 最闲节点而把刚迁走的转发重新认领回去。正确做法是先确认旧条目已消失， 再提交新任务。 3. **周期性检查与 API/UI 暴露**。 ## 测试 4 条，均针对 planBalance：搬走超载节点的一条转发 / 不搬停用转发 / 均衡时不动 / 不选 offline 节点。构造 seed 时经 JSON 往返让每个 State 持有独立 Nodes 切片 （AdoptState 是值赋值但 Nodes 是切片，共享底层数组会造成假绿——这个坑本项目 已踩过多次）。