Redis集群节点QPS为何不均衡？数据分布倾斜与热点Key访问频率

Redis集群QPS倾斜：排查方法与常见误区

在实际排查Redis集群性能问题时，QPS倾斜是一个容易被低估但又极为致命的隐患。以下从核心判断逻辑入手，帮助绕开常见的误区。

1. 如何判断集群是否存在QPS倾斜

最直接的方法是查看每个节点的实时INFO commandstats输出，重点关注高频命令如cmdstat_get、cmdstat_hget的calls字段。如果某个节点的calls值比其他节点高出3倍以上，基本可以判定倾斜已经发生。

但直接查看输出存在瞬时抖动的问题。更稳妥的做法是结合监控系统，例如使用Prometheus搭配Redis Exporter，拉取各节点redis_commands_processed_total的1分钟速率数据，过滤波动后才能看到真实趋势。需要特别提醒：不能只看内存占用指标（如used_memory_rss）。内存高并不等于QPS高，大Key可能占用大量内存但访问频率极低，这与QPS倾斜完全是两码事。

2. CLUSTER SLOTS的误判陷阱

该命令返回的是slot到节点的静态映射关系，只说明“理论上数据应该分配到哪”，完全不反映“实际访问量打到哪”。即使每个节点负责的slot数量完全相同，只要业务中使用了{user_id}这类hash tag，所有user:profile:{123}都会落到同一个slot，该slot所在的节点就很可能被压垮。

常见的误判有两种：一种是一看到每个节点分配的slot数量差不多就认为没问题，但实际上hash tag或bigkey会使负载严重偏移；另一种是发现某个节点负责的slot更多，就马上断定是分配不均，但slot数量本身从来不是瓶颈，真正的关键在于Key的访问频次和体积。

3. MONITOR命令能否用于定位热点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，然后通过日志聚合分析访问频次。

4. 加随机前缀：读热点有效，写热点慎用

加随机前缀（例如cache:user:123:abc、cache:user:123:def）的本质是把一个Key拆成多个，让CRC16计算后落到不同slot，从而分散请求。这个思路对读操作完全可行。但对写操作却不可行：如果用户资料更新，需要同时修改5个副本，就需要发送5次写请求，网络失败或部分成功都会导致状态不一致，而Redis集群本身不提供跨slot的原子性保障。

结论清晰：对于只读热点，可以采用多副本加随机前缀加客户端路由的方案；对于读写热点，优先考虑升配该节点硬件，或者从业务侧做二级缓存降级，例如使用本地Caffeine缓存加短TTL。绝对不要在客户端做“写多副本加读任意副本”的设计，否则会引入难以排查的数据一致性问题。

5. 真实线上环境的综合因素

在实际线上环境中，QPS倾斜从来不是单一原因。例如，看到某个节点CPU飙到100%，背后往往是hash tag导致slot集中，加上该slot下恰好有一个50MB的hgetall大Key，而该Key又被前端轮询疯狂调用。遇到这种情况，需要一层层剥开分析，不能只盯着监控图表上的峰值数字。