手动分配服务器流量本质是按后端节点权重比例分发请求；Nginx中weight须为正整数、需reload生效；Dubbo按累积权重区间计算概率；twemproxy的ketama权重决定虚拟节点数，不适用于精细负载分担。
手动分配服务器流量，本质就是给每个后端节点设一个整数权重值，让负载均衡器按比例分发请求——不是“平均分”，而是“按能力分”。
nginx 中 weight= 参数怎么写才不翻车
在 upstream 块里直接写 weight= 是最常用也最容易出错的方式。常见错误是：只改了权重却忘了 reload 配置，或把 weight 设为 0 却没意识到它等价于临时下线（Nginx 不会报错，但该节点彻底收不到新连接）。
-
weight必须是正整数，不支持小数或百分比（比如不能写weight=0.5或weight=50%） - 默认值是 1；所有节点权重相同时，退化为纯轮询
- 若某台机器性能是另一台的 3 倍，建议设为
weight=3和weight=1，而不是weight=300和weight=100——绝对数值不重要，比例才关键 - 修改后必须执行
nginx -s reload，否则配置不生效
Dubbo 的 weight=100 到底怎么算概率
Dubbo 默认用 RandomLoadBalance，选节点时不是“随机挑一个”，而是“生成一个 [0, 总权重) 区间内的随机数，再按累积权重定位”。比如三个 provider 权重分别是 100、200、100，总权重为 400，那么随机数落在 [100,300) 就选第二个节点——它被选中的理论概率就是 200/400 = 50%。
- 权重为 0 表示该实例不参与调度，常用于运维下线，无需重启服务
- 通过 Nacos/ZooKeeper 动态改权重，consumer 端会在几秒内拉取新值，但要注意：旧连接可能还在用老权重缓存
- 别在 application.yml 里全局配
dubbo.provider.weight后又在@DubboService注解里单独设 weight——后者会覆盖前者
twemproxy 的 ketama 权重和 nginx 完全不是一回事
twemproxy 的 weight 不是简单控制请求数量比例，而是在一致性哈希环上决定虚拟节点数量。比如 -127.0.0.1:6379:10 和 -127.0.0.1:6380:1，前者会在哈希环上生成 10 倍于后者的虚拟节点，从而大幅提高被命中的概率。这导致它的流量倾斜比 nginx 更剧烈，且无法靠“调小权重”来精细微调。
- ketama 模式下，权重差异过大（如 100000:1）会让低权节点几乎收不到请求，适合做“主备”而非“负载分担”
- 如果要用平滑过渡（比如灰度发布），建议换用
modula算法，它的权重响应更线性 - 修改
nutcracker.yml后必须重启 twemproxy 进程，不支持热重载
权重不是越细越好，也不是越大越准；真正难的是把硬件性能、业务峰值、故障恢复节奏这三件事对齐——比如一台 CPU 密集型服务刚扩容，权重调高了，但 GC 压力没监控到位，结果流量一压就超时。这时候权重本身没错，错的是没把它放进可观测闭环里。
