Redis集群在长期使用后，经常会出现部分节点内存占用远高于其他节点的情况，这种现象被称为数据倾斜。数据倾斜不仅会造成集群整体内存利用率下降，还会让高负载节点成为性能瓶颈，甚至触发频繁的内存淘汰或OOM。要解决这一问题，不能只靠盲目扩容，而需要先理清倾斜产生的技术根源，再针对性地采用均衡策略。
数据倾斜的常见成因与诊断方法
在Redis Cluster模式下，数据通过CRC16算法计算哈希值并映射到16384个槽（slot），再由槽分配到不同节点。理论上槽均匀分布就能实现数据均衡，但实际中常因几个因素被破坏。其一是大key或热key集中，例如某个用户粉丝列表被存为一个超长list，或秒杀商品信息成为高频访问的string，这类数据虽只占少数槽位却带来极高负载。其二是客户端使用了不恰当的hash tag，把大量本应分散的数据强制绑定到同一个槽。其三是早期建集群时槽分配脚本失误，导致某些节点承担了明显更多的槽数。
诊断时首先应通过cluster nodes命令查看各节点负责的槽数量和内存指标。若槽数均匀但内存差异大，基本可判定为大key或热key问题，此时用redis-cli --bigkeys或基于MEMORY USAGE的扫描脚本定位具体key。如果发现某些槽对应的key数量极少但访问量极高，就需要结合监控系统的命中率曲线来确认热点。只有明确成因，后续的均衡策略才不会南辕北辙。
另外，网络与持久化层面的偏差也会放大感知到的倾斜。例如某节点所在的物理机磁盘IO较差，AOF重写慢，导致该节点响应变慢、客户端重试增多，进一步拉高其CPU与连接数。这类问题容易被误认为数据倾斜，因此在下结论前应排除基础设施层面的干扰，确保对比的是同构主机上的纯数据分布指标。
基于槽迁移的集群再平衡实践
当确认是槽分配不均引起的倾斜时，最正统的做法是使用Redis官方提供的槽迁移机制重新平衡。Redis Cluster支持在線迁移槽，通过将源节点的若干slot及对应key逐步移动到目标节点，实现负载再分布。迁移过程由CLUSTER SETSLOT、MIGRATE等命令驱动，社区工具如redis-trib.rb或后来的redis-cli --cluster rebalance可自动计算并分批执行。
下面是一个使用redis-cli进行再平衡的示例命令，它会根据节点内存和槽数自动调配：
# 对已有集群执行自动再平衡，权重按节点内存 redis-cli --cluster rebalance 192.168.0.1:6379 --cluster-use-empty-masters --cluster-threshold 2
该命令会让集群在阈值超过2%偏差时开始迁移，过程中业务无需停写，因为Redis采用ASK重定向机制保证迁移中key的可见性。但需注意，大key迁移会造成源和目标节点瞬时阻塞，因此建议在低峰期操作，并配合cluster slots观察进度。若业务对延迟极度敏感，可编写脚本将大key先拆分为多个小key，再触发迁移，从而降低单次MIGRATE的卡顿。
槽迁移的缺点在于，当倾斜根因是热key而非槽不均时，迁移并不能降低单点负载，反而可能因迁移流量加重节点负担。因此该策略应仅用于解决分布不均，而非访问不均。此外，频繁再平衡会带来集群状态震荡，应在确认倾斜持续存在后再执行，而不是作为日常手段。
应用层热点分散与读写分离策略
对于热key引起的逻辑倾斜，单纯靠集群内部均衡无济于事，必须从访问模式上拆解。一种常见方案是在key命名中引入随机后缀，将单热key打散为多个子key。例如原始key为product:1001:stock，可改写为product:1001:stock:{1..10}，写时按随机或轮询选中一个，读时聚合或取首个非空值。这样原本落在单槽的极高QPS被均摊到不同节点，避免了单点CPU打满。
另一种有效手段是引入本地缓存或代理层缓存。在客户端或Twemproxy、Codis等代理中，对识别出的热key做短时效的本地副本，使得大部分读请求不再穿透到Redis节点。下面的Java代码片段展示了如何用Caffeine做热key本地缓存：
// 构建本地缓存，最大1万条，写入后5秒过期
Cache<String, String> localCache = Caffeine.newBuilder()
.maximumSize(10000)
.expireAfterWrite(5, TimeUnit.SECONDS)
.build();
public String getHotValue(String key) {
String v = localCache.getIfPresent(key);
if (v != null) {
return v;
}
v = redisTemplate.opsForValue().get(key);
if (v != null) {
localCache.put(key, v);
}
return v;
}
读写分离同样能缓解倾斜带来的压力。Redis Cluster虽主节点负责读写，但可开启从节点只读，将部分读流量导向副本。通过客户端配置readonly模式，将非强一致要求的查询发往slave，主节点便只需处理写与关键读。此方式不改变数据分布，但能显著降低热点主节点的负载，为彻底重构key结构争取时间。
综合来看，应用层策略对业务代码有一定侵入性，但换来了立竿见影的均衡效果。团队应在监控中标记出Top 100热key，按上述方案逐步改造，而不是一次性全量调整，以便随时回滚和评估收益。
长期治理与容量规划建议
数据倾斜本质上是架构与运维欠账的显现，因此除了应急策略，还需建立长期治理机制。首先在集群搭建阶段就应使用自动化工具均匀分配槽，并禁止业务方随意使用hash tag。其次将大key检测纳入每日巡检，一旦扫描到超过阈值（如10MB或5000字段）的key，自动告警并推动拆分。最后在容量规划时，不以节点数衡量集群能力，而以峰值热keyQPS和单节点内存水位为准，预留30%以上缓冲。
下表对比了三种均衡策略的适用场景与成本：
| 策略 | 解决类型 | 业务侵入 | 迁移风险 |
|---|---|---|---|
| 槽迁移再平衡 | 分布不均 | 低 | 中 |
| 热key打散 | 访问不均 | 高 | 低 |
| 本地缓存与读写分离 | 访问不均 | 中 | 低 |
通过组合运用这些策略，并在开发规范中前置约束，才能让Redis集群在业务增长中保持平稳。运维与开发应定期回顾倾斜指标，把均衡动作变成例行性工作，而非故障后的救火行为。