核心是让缓存节点按真实服务能力分担请求量。需实测QPS与P99延迟后设权，代理层（Nginx/twemproxy）精准注入weight，再通过监控指标动态调权，最终验证各节点ops与weight比例一致且延迟合理。
用 weight 微调缓存节点权重，核心不是“平均分流量”，而是让每台缓存服务器承担与其真实服务能力匹配的请求量。尤其在 Redis 或 Memcached 集群中，硬件差异、网络延迟、IO 能力不同，直接导致部分节点 CPU 打满、响应变慢，而其他节点空转——这就是典型的性能不均。解决它，靠的是“可测、可设、可调”的三层动作。
先实测再设权：别按CPU核数拍脑袋
缓存服务的瓶颈往往不在 CPU，而在网络带宽、连接数上限或磁盘 I/O（如持久化 Redis）。单纯按 16 核 vs 8 核设 weight=2:1，容易失准。
- 对每台缓存节点单独压测：用 redis-benchmark 或 memtier_benchmark 模拟相同并发（如 500 连接），跑 2 分钟，记录实际 QPS 和 P99 延迟
- 以最高 QPS 节点为基准（比如 40,000 QPS → weight=10），其余按比例折算（32,000 QPS → weight=8；20,000 QPS → weight=5）
- 若某节点延迟明显偏高（如 P99 > 15ms），即使 QPS 不低，也主动降权 20%～30%，防止拖累整体 SLA
在代理层精准注入 weight：Nginx 或 twemproxy 是主力
缓存流量通常经由代理层分发，weight 必须落在这一层才有效。绕过 upstream 直连 IP，weight 就完全失效。
- Nginx 中，在 http → upstream 块内配置：server 192.168.2.10:6379 weight=8;，不可写在 location 里
- twemproxy 支持更细粒度的 per-server 权重字段（如 weight: 8），且原生适配 Redis/Memcached 协议，无额外解析开销
- 避免和 ip_hash 同时启用——它会强制会话绑定，彻底覆盖 weight 的加权逻辑
动态兜底：静态 weight 只是起点，不是终点
一台 Redis 节点刚完成 RDB 保存，iowait 瞬间飙到 90%，但 weight 还是 8，请求照打不误。必须引入实时反馈闭环。
- 监控项聚焦缓存关键指标：connected_clients（连接数超限预警）、used_memory_rss（内存水位）、latency_percentile_99（P99 延迟）
- 设定自动降权规则：例如 P99 > 20ms 持续 60 秒 → weight 临时减半；恢复后 5 分钟内线性回升
- 借助外部控制器实现：用 Prometheus + Alertmanager 触发脚本，修改 Nginx 配置并 reload；或用 Consul Template 自动渲染 twemproxy 配置
验证是否真消灭了不均：看后端，别只盯代理
不能只看 Nginx 的 $upstream_addr 日志里请求分配比，要穿透到每台缓存节点的真实负载。
- 检查各节点每秒处理命令数（Redis info commandstats 中 cmdstat_get.instantaneous_ops_per_sec）是否与 weight 比例基本一致（如 weight=8:5:2，对应 ops 应接近 8:5:2）
- 对比高权重点的平均延迟是否显著高于低权重点——若是，说明它已实际过载，当前 weight 设高了
- 观察故障隔离效果：当一台节点因磁盘 IO 飙高被临时降权后，其他节点的 ops 是否平稳承接，无抖动或错误率上升
