集群内存要逐节点看
集群的内存分散在各个节点上，只看全局均值会掩盖个别节点的紧张。正确做法是逐节点采集 INFO memory，再配合槽位分布与键的空间分布做交叉判断。扩容与再平衡的决策依据是分节点条件，而不是平均值。
基本信息
| 采集方式 | 逐节点执行 INFO memory |
|---|---|
| 分析视角 | 分节点水位加槽位分布 |
| 工具支撑 | 监控系统按实例打标 |
| 决策依据 | 分节点条件，而非全局均值 |
| 端口 | 服务端口加集群总线端口 |
典型使用场景
- 集群整体水位正常，个别节点却先触线
- 扩容前的容量确认与目标节点选择
- 槽迁移期间源节点与目标节点的内存余量评估
- 热点键集中导致单节点压力偏高
- 节点间内存分布不均，需要再平衡
逐节点采集
逐节点采集
redis-cli -h node1 -p 7000 INFO memory | grep -E 'used_memory_human|maxmemory_human'
redis-cli -h node1 -p 7000 cluster info | grep -E 'cluster_state'
redis-cli --cluster check 127.0.0.1:7000 # 一致性检查与槽位分布
redis-cli -h node1 -p 7000 CLUSTER SLOTS # 槽位到节点的区间映射
redis-cli -h node1 -p 7000 CLUSTER COUNTKEYSINSLOT 0 # 抽查某槽的键数
redis-cli -h node1 -p 7000 CLUSTER NODES # 节点清单，便于循环逐节点采集汇总视角的盲区
| 视角 | 能看出什么 | 盲区 |
|---|---|---|
| 全局总内存 | 整体容量与水位的概览 | 掩盖单节点倾斜 |
| 分节点水位 | 找出先触线的节点 | 看不出键的空间分布 |
| 槽位分布 | 各节点负责的范围 | 不反映每个槽的数据量 |
| 槽内键数 | 定位数据量大的槽 | 需逐槽抽查，成本较高 |
| 热点键分布 | 判断是否需要重分片 | 依赖采样口径 |
槽迁移期间，源节点与目标节点会同时持有迁移中的键，规划内存余量时要把这部分双份占用算进去，否则迁移中途就可能触发淘汰。
只盯全局均值做扩容判断，容易出现某些节点已经触线、而集群整体看起来还有余量的情况，扩容时机被显著推迟。
节点指标要按实例打标并与数据角色关联，否则监控面板上分不清哪个是主节点、哪个是从节点，判读容易错位。