WRR不能直接用math/rand因其是无状态伪随机，不支持权重累积分布；需维护每个节点的current和maxWeight并动态更新，权重热更新时必须重置current且保证并发安全。
WRR 在 Go 中为什么不能直接用 math/rand 做权重轮询
因为 math/rand 默认是伪随机、无状态、不支持按权重累积分布的采样逻辑。WRR（Weighted Round Robin）本质需要维护每个后端的「当前权重」和「最大权重」两个变量，并在每次调度时动态更新——不是简单地按概率随机选一个节点。
- 常见错误现象：
select { case 模拟加权延迟，实际变成不可控的竞态调度 - 真实使用场景：API 网关、gRPC 服务发现、内部微服务间调用路由
- 性能影响：如果每次选节点都做一次归一化 + 遍历累加，O(n) 复杂度会拖慢高并发下的负载分发
用 sync/atomic 实现线程安全的 WRR 节点计数器
Go 的 WRR 实现核心在于「每个节点带一个可原子增减的当前权重值」，避免锁竞争。标准做法是让每个节点持有 current 和 weight 字段，每次选取前对所有节点做 atomic.AddInt32(&node.current, node.weight)，再挑 current 最大的那个。
- 必须用
int32或int64类型配合atomic，float64不支持原子操作 - 初始
current应设为 0，否则首次调度可能跳过低权节点 - 注意溢出：长期运行下
current可能溢出，需在取最大值后统一减去全局最大值（即“归零重置”）
balancer.Picker 接口里怎么嵌入 WRR 逻辑（gRPC 场景）
如果你在写 gRPC 自定义负载均衡器，Picker 的 Pick 方法就是 WRR 的执行入口。这里不能每次 Pick 都重建权重数组，而应把节点列表和对应原子计数器缓存在 Picker 实例中。
- 别在
Pick里调用rand.Intn或time.Now().UnixNano()做扰动——这会破坏权重收敛性 - 节点变更（如健康检查下线）时，要替换整个 Picker 实例，而不是原地修改 slice；gRPC 会自动 re-Pick
- 示例关键片段：
func (p *wrrPicker) Pick(info balancer.PickInfo) (balancer.PickResult, error) { var maxNode *node for _, n := range p.nodes { cur := atomic.AddInt32(&n.current, n.weight) if maxNode == nil || cur > atomic.LoadInt32(&maxNode.current) { maxNode = n } } if maxNode != nil { atomic.AddInt32(&maxNode.current, -p.maxWeight) // 归零重置 } return balancer.PickResult{SubConn: maxNode.conn}, nil }
权重配置热更新时容易漏掉的同步点
权重不是写死在代码里的，通常来自配置中心或服务发现。但很多人只更新了节点 weight 字段，忘了重置 current，导致后续调度严重偏离预期。
立即学习“go语言免费学习笔记（深入）”；
- 每次权重变更后，必须对对应节点执行
atomic.StoreInt32(&node.current, 0) - 如果用 map 存节点，记得加读写锁保护 map 本身，但节点字段仍靠 atomic；不要用
sync.RWMutex包裹整个 Pick 流程 - 兼容性注意：Go 1.19+ 的
atomic.Int32更安全，但老版本只能用atomic.AddInt32配合int32指针
