一眼识别内存爆破节点需执行INFO memory，重点观察used_memory_human和mem_fragmentation_ratio；若某节点内存为其他节点2–3倍且mem_fragmentation_ratio远超1.5，大概率存在大Key或热Key。
怎么一眼看出哪个节点内存爆了
直接连上每个主节点执行 INFO memory，重点看 used_memory_human 和 mem_fragmentation_ratio。如果某节点内存是其他节点的 2–3 倍，而 mem_fragmentation_ratio 又远高于 1.5，基本就是它在扛大Key或热Key。别只看集群总内存——Redis 集群不自动均摊内存，节点之间完全独立。
- 线上慎用
redis-cli --bigkeys：它会阻塞主线程扫描，QPS 高时可能触发超时熔断 - 更安全的做法是用阿里云 CloudDBA 的「离线全量 Key 分析」，或本地解析 RDB 备份（
redis-rdb-tools） - 如果发现某个节点
used_memory飙升但db0:keys数量正常，大概率是单个Hash或Sorted Set膨胀到了几十 MB 以上
怎么确认槽位真的分歪了
运行 CLUSTER SLOTS 查每段 16384 个槽谁在管，再对每个节点执行 CLUSTER NODES 看分配是否“表面平均”。常见陷阱是：节点显示都分了 5461–5462 个槽，但实际键数量天差地别——因为 CRC16 对前缀敏感，user:{1000}:order:1 和 user:{1000}:order:2 全被算进同一个槽。
- 用
cluster countkeysinslot <slot_id></slot_id>扫描槽内键数，找出 >10k 键/槽的异常槽位 - 再用
cluster getkeysinslot <slot_id> 100</slot_id>抽样查键名，看是否集中出现相同{tag}或固定前缀 - 注意：
redis-trib.rb rebalance在 Redis 7+ 已弃用，改用redis-cli --cluster rebalance，但前提是所有节点 slot 覆盖完整（CLUSTER INFO中cluster_state:ok）
为什么 --hotkeys 有时查不到真热点
redis-cli --hotkeys 依赖 Redis 内置的 LFU 计数器，但必须满足两个条件才生效：① maxmemory-policy 设为 allkeys-lfu 或 volatile-lfu；② 实例已运行足够长时间让计数器积累。否则返回空或只有冷数据。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 临时补救：用客户端埋点（如 Java 的 AOP 拦截
redisTemplate.opsForValue().get()），统计key访问频次 - 生产环境推荐部署
redis-exporter + Prometheus + Grafana，配置redis_connected_clients和redis_keyspace_hits按实例维度聚合，比命令行更稳定 - 警惕伪热点：比如定时任务每分钟刷一次
cache:health:check，QPS 看似高，但业务无感，这类 key 不需要拆解
查到倾斜后，千万别直接迁移大Key
用 MIGRATE 迁移一个 200MB 的 Hash，极大概率超时失败，还会卡住源节点事件循环。真正可行的是“拆+切+替”三步走：先拆结构，再切流量，最后清理旧 key。
- 例如把
user:1000:profile（含 50 万字段）拆成user:1000:profile:base、user:1000:profile:addr、user:1000:profile:pref - 写操作加双写逻辑（新老 key 同时 set），读操作先查新 key，miss 再回源并异步补新
- 清理阶段用
SCAN+HSCAN分批删，避免单次操作阻塞；别用HDEL user:1000:profile *，它不是原子命令且可能 OOM
最容易被忽略的一点：槽位和内存倾斜往往共存，但根因不同。一个节点内存高，未必是它槽多；可能是它刚好撞上了所有带 {user_1000} 的 key。所以必须把 CLUSTER SLOTS、MEMORY USAGE、--hotkeys 三组数据交叉比对，不能只盯一个指标。
