加权轮询（WRR）核心逻辑是动态累积当前权重并归一化比较：维护每个节点的currentWeight（初值为权重）和全局maxWeight，每轮选currentWeight最大者，选中后减totalWeight，其余节点加自身权重。
加权轮询（WRR）的核心逻辑怎么写
加权轮询不是简单地“轮着来”，而是按节点权重分配请求次数——权重高的节点，在一个完整周期里被选中的次数更多。关键在于：不能每次重置计数器，得用“当前权重”动态累积 + “最大权重”归一化比较。
常见错误是直接用 rand.Intn() 或固定数组索引模拟，结果变成随机或静态轮询，完全丢失权重语义；更隐蔽的坑是整数除法截断导致小权重节点永远不被选中（比如权重 1 和 3，总和 4，但没做归一化就直接模运算）。
- 维护每个后端的
currentWeight（初始为权重值）和全局maxWeight（所有权重最大值） - 每轮选出
currentWeight最大的节点，选中后执行currentWeight -= totalWeight - 其余节点统一执行
currentWeight += weight（注意：不是 += 1） - 必须在每次选择前更新所有节点的
currentWeight，否则状态漂移
Go 实现 WRR 的最小可行结构
用结构体封装状态比全局 map 更可控，避免并发读写冲突。重点不是“多线程安全”，而是“状态一致性”——哪怕单 goroutine 调用，多次 Next() 也必须基于同一套更新规则。
典型错误是把权重存在 map[string]int 里，每次 Next() 都重新遍历、临时计算，既慢又容易漏掉 currentWeight 累积逻辑；还有人误以为要预计算“周期长度”，其实 WRR 本就不依赖周期，它是流式决策。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义结构体包含
backends []Backend和mu sync.RWMutex（即使暂不并发，也预留扩展） -
Backend结构体必须含Weight int和currentWeight int字段 -
Next()方法内先锁读，遍历找currentWeight最大者，再统一更新所有currentWeight - 别在
Next()里做网络探测或健康检查——那是另一层的事，WRR 只管调度逻辑
func (w *WRR) Next() *Backend {
w.mu.Lock()
defer w.mu.Unlock()
var selected *Backend
max := -1
for i := range w.backends {
if w.backends[i].currentWeight > max {
max = w.backends[i].currentWeight
selected = &w.backends[i]
}
}
if selected != nil {
selected.currentWeight -= w.totalWeight
for i := range w.backends {
w.backends[i].currentWeight += w.backends[i].Weight
}
}
return selected
}
权重为 0 或负数时怎么处理
权重为 0 意味着“暂时下线”，但不能从列表中删除——否则破坏 WRR 的状态连续性，会导致其他节点的 currentWeight 累积失准。负数则属于非法输入，应拒绝初始化。
容易踩的坑是：把权重 0 当成“跳过”，在 Next() 中 continue 掉，结果剩下节点的权重比例被悄悄放大；或者初始化时静默忽略负权重，后续计算溢出 panic。
- 初始化时对每个
Weight做校验：if weight - 权重为 0 的节点仍保留在
backends切片中，其currentWeight始终为 0，不会被选中 - 如果所有权重都是 0，
Next()应返回 nil 并记录 warn，而不是死循环或 panic - 不要在运行时动态修改
Weight字段——改了也不生效，得重置整个 WRR 状态
和标准 round-robin、random 的性能差异在哪
WRR 比纯轮询多一次遍历和若干次加减，但仍是 O(n) 时间复杂度，n 是后端数量（通常
真正影响性能的是你在哪里调用它：如果在 HTTP handler 内每次请求都 new 一个 WRR 实例，那 GC 和初始化成本远超算法本身；还有人把 WRR 和 TLS 握手、DNS 解析混在一起测，误判为“WRR 慢”。
- WRR 实例应全局复用，或按服务粒度复用，绝不在请求路径上重建
- 避免在
Next()中嵌入日志、metric 打点等 IO 操作——这些该由上层统一做 - 如果后端数超过 500，考虑改用平滑加权轮询（SWRR），它用 GCD 归一化，避免大数累积误差
- Go 的
sync/atomic对currentWeight更新帮助不大，因为要批量读+写，还是得锁
权重调度的复杂点从来不在公式本身，而在于状态如何跨请求保持、如何与健康检查联动、以及权重变更时要不要平滑过渡——这些都不在 WRR 算法里，但线上出问题时，第一个被怀疑的总是它。
