加权轮询通过平滑递减current_weight与周期重置实现动态调度，确保高权重节点高频但不连续被选中；一致性哈希依托哈希环与虚拟节点，保障扩缩容时请求迁移率最低。
加权轮询：按权重动态分配，核心在“平滑递减+周期重置”
加权轮询不是简单地按权重重复派发，而是通过维护每个节点的 current_weight 实现平滑调度。Nginx 源码中（ngx_http_upstream_module.c）的关键逻辑是：
- 每次选择前，对所有健康节点执行
peer->current_weight-- - 选出 effective_weight 最大的节点作为本次目标（注意不是原始 weight）
- 当所有节点的 current_weight 累计归零时，触发重置：将每个节点的 current_weight 恢复为原始 weight
这个机制确保高权重节点被更频繁选中，但又不会连续霸占——比如权重为 3、2、1 的三台服务器，实际请求序列接近 1-2-1-3-1-2，而非 1-1-1-2-2-3。更重要的是，effective_weight 会随节点健康状态实时衰减（如超时一次默认 -10），恢复期缓慢回升（+1/轮），形成轻量级被动熔断。
一致性哈希：环形结构 + 虚拟节点，解决扩容/缩容抖动
一致性哈希不依赖节点数量做模运算，而是把物理节点和请求都映射到一个 0～2³²−1 的哈希环上。Dubbo 的 ConsistentHashSelector.java 典型实现包含两个关键设计：
- 使用 MD5 对 key 散列，再取前几位计算 hash 值，保证分布均匀性
- 每个物理节点默认生成 160 个虚拟节点（由 VIRTUAL_NODES 常量控制），分散在环上
这样做的效果是：当新增或下线一台机器时，仅影响环上邻近的一小段区间。实测显示，虚拟节点优化可将请求迁移率从 52% 降至 8%，大幅减少缓存击穿与会话中断风险。而 Nginx 中启用一致性哈希只需在 hash 指令后加 consistent 关键字，例如：hash $arg_user consistent;。
两者根本差异不在“是否带权重”，而在调度视角
加权轮询是面向服务能力的静态适配：它假设节点性能差异稳定，靠配置 weight 刻画吞吐能力，适合长期稳定的异构集群（如 CPU/内存明显不同的 VM）。但一旦某节点响应变慢或失败，它无法自动规避——除非配合 max_fails 和 fail_timeout 做被动剔除。
一致性哈希是面向数据亲和性的动态稳定：它不关心节点快慢，只保证相同 key 总落到同一节点，天然支持会话保持与局部缓存。即使节点数变化，也只扰动局部流量。但它本身不提供权重调节能力——若需加权，必须在虚拟节点数量上做文章（如权重为 3 的节点部署 480 个虚拟节点）。
Nginx 配置中如何体现这两种逻辑
在 upstream 块内，两种算法的启用方式截然不同，且不能混用：
-
加权轮询 是默认策略，直接写
weight=3即生效，无需额外指令 -
一致性哈希 必须显式声明
hash或ip_hash，并追加consistent才启用环形查找；否则hash默认是普通取模哈希，扩缩容时仍全量迁移 - 二者都可结合
max_conns、max_fails等参数做基础健康管控，但只有加权轮询原生耦合了 effective_weight 的运行时衰减逻辑
