不能直接用 requestid % totalweight 实现加权随机分配，因其缺乏随机性、无法映射概率区间、不支持权重动态变化；正确做法是 random.nextint(totalweight) 生成随机偏移量，再通过累减权重定位节点。
% 运算符本身不能直接实现加权随机分配，它只负责取余——但很多人误以为「用请求 ID 对总权重取模」就能得到加权效果，结果流量严重倾斜。真正可行的做法是：用 Random.nextInt(totalWeight) 生成一个落在 [0, totalWeight) 区间内的随机数，再通过累减各节点权重来定位归属。
为什么不能直接用 requestId % totalWeight
取模运算本质是等距切分，而权重分配需要的是「概率区间映射」。比如节点 A 权重 50、B 权重 30、C 权重 20，总权重 100。你希望 A 被选中的概率是 50%，B 是 30%，C 是 20%。但如果你对某个固定 requestId（比如 12345）反复取模，结果永远是同一个值，完全不随机。
- 真实场景中，
requestId往往是单调递增或带业务语义的（如用户 ID、订单号），不具备随机性 -
%无法体现权重的累积分布特性；它只是线性折叠，不是概率采样 - 若后端节点上下线导致总权重变化，旧
requestId % totalWeight结果会批量漂移，破坏一致性
Random.nextInt(totalWeight) + 累减定位才是正解
这是 Dubbo、Spring Cloud LoadBalancer 等主流框架实际采用的方式，核心逻辑是把权重展开成一条数轴，然后在轴上随机打点。
假设节点列表为：[{A,50}, {B,30}, {C,20}]，总权重 totalWeight = 100：
- 生成随机数
offset = random.nextInt(100)，范围是 [0, 99] - 遍历节点，用
offset减去当前节点权重：
— 若减完后offset ，说明落在此节点区间，返回该节点<br>— 否则继续减下一个节点权重
int offset = random.nextInt(totalWeight);
for (Server node : nodes) {
offset -= node.getWeight();
if (offset <p>这个过程不需要预分配数组，空间复杂度 O(1)，时间复杂度 O(n)，n 是节点数——对百节点内规模完全无感。</p><hr><h3>权重为 0 或负数时会出什么问题</h3><p>一旦某个节点权重 ≤ 0，上面的累减逻辑就会失效：要么跳过该节点（因为 <code>offset -= 0</code> 不改变值），要么触发负数比较提前命中（如果权重为负，<code>offset</code> 反而变大）。更糟的是，某些实现没做校验，直接让 <code>random.nextInt(0)</code> 抛 <code>IllegalArgumentException</code>。</p>
- 必须在初始化阶段过滤掉权重 ≤ 0 的节点，否则
nextInt(totalWeight)可能传入 0 - 运行时若动态更新权重，需保证新权重 > 0，且重新计算
totalWeight - Dubbo 的做法是：权重为 0 时仍保留在列表中，但调度时跳过；不过这要求你显式处理跳过逻辑，别依赖累减自动规避
和一致性哈希、轮询比，这种算法适合什么场景
它适合「权重需频繁调整」「节点数稳定」「不要求相同请求固定打到同一节点」的场景。比如灰度发布时临时把某台机器权重调到 1，或根据 CPU 使用率动态升降权。
- 对比轮询：
RoundRobin有状态（要维护当前索引），且加权轮询（如 Dubbo 的WeightedRoundRobin）需维护每个节点的当前权重快照，实现更重；而随机权重无状态，天然适合无共享架构 - 对比一致性哈希：后者强调「相同 key → 相同节点」，用于缓存/会话粘滞；随机权重不保证这一点，但吞吐更高、实现更轻量
- 注意：高并发下
Random实例最好复用（如ThreadLocalRandom），避免多线程竞争Random内部原子计数器
真正的难点不在写几行代码，而在于——权重配置是否真实反映节点能力？监控是否能及时发现权重与实际负载倒挂？ 没有反馈闭环的权重，只是自欺欺人的数字游戏。
