当前集群存在qps倾斜可直接查info commandstats中cmdstat_get等calls字段，若某节点值超其他节点3倍即判定倾斜；更稳妥需结合prometheus+redis exporter看redis_commands_processed_total速率。
怎么看当前集群是否存在QPS倾斜
直接查每个节点的实时 INFO commandstats 输出，重点关注 cmdstat_get、cmdstat_hget 这类高频命令的 calls 字段。如果某节点的 calls 值是其他节点的 3 倍以上，基本可判定 QPS 倾斜已发生。
更稳妥的方式是结合监控系统（如 Prometheus + Redis Exporter）拉取各节点 redis_commands_processed_total 的 1 分钟速率，排除瞬时抖动干扰。注意：不能只看 used_memory_rss，内存高 ≠ QPS 高，大 key 可能占内存但访问极少。
CLUSTER SLOTS 能看出什么、不能看出什么
CLUSTER SLOTS 返回的是 slot 到节点的静态映射关系，它只反映“理论上数据该分到哪”，不反映“实际访问打到了哪”。即使 slot 分配均匀，只要业务用了 {user_id} 这类 hash tag，所有 user:profile:{123} 都会落到同一个 slot，进而压垮对应节点。
常见误判点：
- 看到 CLUSTER SLOTS 中每个节点负责的 slot 数量差不多，就认为没问题 → 错，hash tag 或 bigkey 会让实际负载严重偏移
- 发现某节点负责 slot 更多，就认定是分配不均 → 错，slot 数量本身不是瓶颈，关键在 key 访问频次和体积
monitor 命令真能定位热点 key 吗
能，但代价高，仅限临时排查。执行 MONITOR 会让 Redis 把每条命令都写入输出缓冲区，瞬间推高 client_longest_output_list 和 used_memory_rss，高流量下极易触发 OOM 或阻塞主线程。
更安全的做法：
- 用 redis-cli --hotkeys（Redis 4.0+），它基于 LFU 淘汰策略反向采样，开销低
- 在 proxy 层（如 Codis、Twemproxy）开启命令统计，避免侵入 Redis 实例
- 对关键业务 key 加前缀并埋点，比如 hot:order:1001，通过日志聚合分析访问频次
为什么加随机前缀能缓解读热点，却不敢用于写热点
读热点加随机前缀（如 cache:user:123:abc、cache:user:123:def）本质是把一个 key 拆成多个，让 CRC16 计算后落到不同 slot，分散请求。但写操作必须保证一致性：如果用户资料更新要同时改 5 个副本，就得发 5 次写，网络失败或部分成功会导致状态不一致。
所以：
- 只读热点：可用多副本 + 随机前缀 + 客户端路由
- 读写热点：优先升配该节点硬件，或从业务侧做二级缓存降级（如本地 Caffeine 缓存 + 设置短 TTL）
- 绝对不要在客户端做“写多副本 + 读任意副本”的设计，Redis 集群不提供跨 slot 的原子性保障
真实线上环境里，QPS 倾斜往往不是单一原因。你看到的“某个节点 CPU 100%”，背后可能是 hash tag 导致 slot 集中 + 该 slot 下又恰好有个 50MB 的 hgetall 大 key + 这个 key 还被前端轮询调用。得一层层剥开看，不能只盯着监控图表上的峰值数字。
