加权一致性哈希是核心机制：通过为高权重节点分配更多虚拟节点，使其在哈希环上覆盖面积更大，从而在保持请求粘性（如同一用户总落在同一后端）的同时，实现按权重比例的长期流量倾斜，兼顾单调性与负载均衡。
要实现既按权重分配、又保持请求粘性（比如同一用户总落在同一后端），关键不是“二选一”，而是把权重和哈希结合起来——用加权一致性哈希，而不是简单叠加两种策略。
加权一致性哈希是核心机制
普通一致性哈希把每个后端映射成固定数量的虚拟节点，环上分布均匀，流量自然均分。而加权一致性哈希会让高权重节点在哈希环上占据更多虚拟节点位置。比如A权重10、B权重5，A可能生成200个虚拟节点，B只生成100个——它们在环上的覆盖面积不同，被选中的概率就按比例拉开。
像Katran用的Maglev算法、Talos优化的一致性哈希，底层都是这个逻辑：权重不直接参与哈希计算，而是决定虚拟节点密度。这样既保留哈希的会话保持特性，又实现近似权重比的长期流量倾斜。
权重需反映真实服务能力
配置权重不能只看CPU或内存规格，得结合实际业务负载特征：
- 如果后端处理的是计算密集型请求（如图像识别），权重应主要参考CPU核数与主频
- 如果是IO密集型（如数据库代理），更要看磁盘IOPS或网络吞吐余量
- 灰度发布时，新实例可设低权重（如10），等监控指标稳定后再逐步调高
- Shenyu网关还会叠加预热机制：刚上线的服务，即使配置权重100，初始实际权重也从1开始线性增长，避免冷启动打满
哈希因子选择影响粘性效果
哈希输入值决定了“谁会被粘住”。常见选项有：
- 客户端IP：适合Web类服务，但NAT环境下可能多个用户共用一个出口IP
- 请求Header中指定字段（如X-User-ID）：更精准，需客户端配合透传
- URL路径或查询参数：适用于API网关场景，能保证相同资源路径总由同一后端处理
- 注意：若选IP做哈希，又用了CDN或四层LB，真实IP可能被覆盖，需提前开启proxy protocol或提取X-Forwarded-For
静态权重 + 动态反馈更可靠
纯静态权重在业务波动时容易失准。建议搭配轻量级反馈机制：
- 定期采集各后端的平均响应时间、错误率、连接数，对权重做小幅衰减或提升（如±5%）
- Katran虽以XDP层静态路由为主，但可通过外部控制器读取eBPF map统计，动态重载Maglev表
- 避免每秒都调权——高频调整反而破坏哈希稳定性，一般5–15分钟同步一次较稳妥
