Redis怎样分析当前集群因淘汰受损最严重的节点_聚合监控各分片evicted

必须手动遍历各主节点执行info memory提取evicted_keys累计值，结合槽位分布计算单位槽位淘汰压力比值才能准确定位瓶颈点。

redis怎样分析当前集群因淘汰受损最严重的节点_聚合监控各分片evicted_keys差异进行数据重新分布

没有直接暴露“因淘汰受损最严重节点”的指标，必须靠 evicted_keys 聚合 + 槽位分布交叉比对才能定位真实瓶颈点。

如何准确抓取各节点的 `evicted_keys` 累计值

Redis 集群每个主节点独立统计自己的 evicted_keys（被内存淘汰策略驱逐的 key 数），它不跨节点聚合，也不自动上报到集群视图。必须手动遍历所有主节点执行 INFO memory 并提取该字段：

先用 redis-cli --cluster nodes <any-node></any-node> 列出全部节点，过滤出 role=master 且 state=connected 的地址
对每个主节点逐个调用：redis-cli -h <ip> -p <port> INFO memory | grep evicted_keys</port></ip>
注意：evicted_keys 是累计值，不是速率；若需判断“当前压力”，应间隔固定时间（如 60s）两次采集做差值
某些旧版 Redis（如 5.0.14 之前）可能不返回该字段——需确认版本 ≥ 4.0.0 且启用了淘汰策略（非 no-eviction）

为什么只看 `evicted_keys` 不够，必须结合槽位分布

高 evicted_keys 只说明该节点内存压力大，但不等于它是“数据分布不均”的根源——有可能是它承载了更多热 key、更大 value、或更激进的淘汰策略配置。真正要判断“是否该迁移槽位”，得看：

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

该节点的 evicted_keys 是否显著高于其他主节点（比如 >2 倍中位数）
它的实际内存使用率（used_memory_rss_human）是否逼近物理内存上限
它负责的哈希槽数量是否明显偏多（redis-cli -h <node> -p <port> CLUSTER SLOTS</port></node> 可查范围）
关键：对比它的 evicted_keys / slot_count 比值 —— 若远高于集群平均值，才说明“单位槽位淘汰压力”异常，适合迁出部分槽

用 `redis-cli --cluster rebalance` 时容易忽略的关键参数

redis-cli --cluster rebalance 默认行为是“尽量均匀分配槽位数”，但它**完全不感知 evicted_keys 或内存使用率**，所以盲目执行可能让问题恶化：

必须加 --threshold <num></num>：指定槽位迁移触发阈值（默认是 2），设为 1 可让微小不均也触发迁移，更适合淘汰敏感场景
必须加 --weight <node-id>=<weight></weight></node-id>：给高淘汰节点设 weight=0.5，低淘汰节点设 weight=1.2，强制 rebalance 倾向于从高压节点迁出
禁止用 --use-empty-masters：空 master 节点权重为 0，若误启用，可能导致槽全堆到少数节点上，加剧淘汰
执行前务必用 --dry-run 预览迁移计划，确认源节点确实是高 evicted_keys 节点，且目标节点 used_memory_rss_human 有足够余量

迁移过程中客户端报 `ASK` 错误但业务没断，这正常吗

正常。只要不是持续大量 ASK，就说明迁移正在按 Redis Cluster 协议推进：

ASK 出现是因为 key 所在槽正处于迁移中：源节点查不到，返回 ASK 让客户端重定向到目标节点
客户端 SDK（如 lettuce、redis-py）都自动处理 ASK，无需业务代码修改
但如果 ASK 响应占比突然超过 5%，说明迁移节奏过快或目标节点网络延迟高，建议暂停并检查 redis-cli -h <target> -p <port> INFO replication</port></target> 中 master_sync_in_progress 和 slave_repl_offset 是否滞后
真正危险的是 MOVED 错误大量出现——那意味着槽已正式归属变更，但客户端本地缓存未刷新，属于配置或 SDK 版本问题