随机或轮询无法支持动态权重调整，必须用原子操作维护节点current权重并保证并发安全；go用atomic+环形数组，java用atomiclong+版本号校验，避免状态不一致与调度偏斜。
直接用随机或简单轮询无法支持动态权重调整，必须维护节点状态并保证并发安全；Go 里最轻量可行的方案是 atomic + 环形数组，Java 则需用 ReentrantLock 或 CAS 配合 volatile 字段。
为什么 rand.Float64() 加权选节点在生产环境会出问题
归一化后靠随机数落区间看似能按比例分发，但实际暴露两个致命缺陷：一是高并发下短期分布严重偏斜（比如连续 10 次请求全打到同一高权节点），二是权重变更时正在执行的选择逻辑仍按旧权重计算，导致新旧状态混用。这不是精度问题，而是状态缺失导致的逻辑断裂。
常见错误现象：weight 字段被修改后，部分请求仍按旧值参与调度；压测时流量分配比例和预期偏差超过 30%；节点下线后仍有少量请求被转发过去。
- 该方式完全无状态，无法感知“当前已分配了多少次”
- 不适用于服务发现场景——节点增删、权重热更、健康状态变化都会让结果失真
- 即便加锁同步
weight和选择逻辑，也会因锁竞争拖慢吞吐
Go 中用 atomic 实现线程安全的动态加权轮询
核心不是“每次算比例”，而是为每个节点维护一个 current 剩余权重，并用原子操作读取、扣减、重置。这样既避免锁，又天然支持运行时调权。
实操建议：
- 节点结构体至少含：
addr string、weight int64（防止原子溢出）、current int64（初始值 =weight） - 选择逻辑：遍历所有节点，用
atomic.LoadInt64(&node.current)读当前值；取最大值对应节点；再用atomic.AddInt64(&node.current, -1)扣减 - 重置时机：扣减后若
atomic.LoadInt64(&node.current) == 0，则atomic.StoreInt64(&node.current, node.weight)——这步必须在扣减之后、且不能和其他节点重置并发执行 - 注意：
current归零不代表立刻重置，而是“本轮调度结束后的下一轮才生效”，这是算法收敛的关键
Java 中如何安全更新权重并保持调度一致性
Java 没有原生的 atomic.AddInt64，但可用 AtomicLong 模拟相同语义。重点在于：不能只改 weight 字段，必须让 current 的重置逻辑感知权重变更。
容易踩的坑：
- 直接写
node.weight = newWeight→ 此时若有线程刚执行完current.getAndDecrement()，还没走到重置分支，就会用旧weight重置current - 用
synchronized包裹整个选择逻辑 → QPS 直降 40% 以上，尤其在节点数 > 20 时明显 - 忽略
volatile修饰weight→ 其他线程可能永远看不到新值
推荐做法：给节点加 version 字段（AtomicLong），每次调权时 version.incrementAndGet()；选择逻辑中，读 current 前先读 version，重置时校验版本未变；若版本已变，放弃本次重置，由下次循环处理。
动态权重更新的边界条件必须显式处理
真实系统里，权重不是静态配置项，而是随 CPU 使用率、RT、错误率实时变化的。这意味着你不仅要实现“怎么选”，还要定义“何时重算权重”和“如何通知调度模块”。
容易被忽略的地方：
- 权重归零时节点是否应立即剔除？还是仅降低被选概率？这需要和健康检查模块协同，不能仅靠调度层判断
- 多个 goroutine / 线程同时调权时，
weight更新和current重置之间存在微小窗口期，必须用版本号或合并字段（如高 32 位存 weight、低 32 位存 current）来规避 - 节点列表动态增删时，环形索引或遍历顺序可能越界，需配合
sync.RWMutex或CopyOnWriteArrayList做快照保护
