Redis Cluster实战复盘：分片倾斜、槽位迁移失败、热点副本、集群雪崩彻底解决

前言

随着业务规模增长，单个 Redis 实例往往无法满足高并发、大容量和高可用需求。

Redis Cluster 常被用于解决：

数据分片
水平扩展
故障转移
读写分离
高可用部署
大容量缓存
跨节点数据分布

但 Redis Cluster 并不是简单地把多个 Redis 节点拼起来。

如果分片设计、槽位迁移、副本配置或热点处理不合理，也会出现严重线上故障：

16384 个槽位分布不均
某个节点承担过多 Key
主节点内存持续上涨
从节点复制延迟
槽位迁移失败
热点 Key 集中在少数分片
故障转移后雪崩扩散

本文基于真实 Redis Cluster 集群故障，完整分析分片倾斜、槽位迁移失败、热点副本和集群雪崩问题。

一、真实线上故障场景还原

1.1 业务背景

某电商平台使用 Redis Cluster 承载商品缓存、活动配置、库存扣减、用户会话等核心数据。

集群规模：

6 个主节点
每个主节点 1 个从节点
共 12 个 Redis 实例
负责多个业务缓存 Key

上线初期运行稳定，但随着活动数据增加，集群开始出现异常。

1.2 故障现象

某天大促活动开始后，Redis Cluster 出现以下问题：

某个主节点内存持续升高
该节点 CPU 升高
部分接口响应变慢
缓存查询超时增加
数据库查询压力上升
集群槽位分布不均匀
手动迁移槽位失败
高峰期出现服务雪崩

1.3 初步排查

排查发现：

某个主节点占用内存远高于其他节点
大量商品缓存 Key 集中在该节点
活动配置 Key 数量快速增长
该节点从节点复制延迟增加
槽位迁移命令执行失败
客户端报错 MOVED 或 ASK

二、Redis Cluster 分片倾斜为什么会导致雪崩

2.1 16384 个槽位分布不均

Redis Cluster 使用 16384 个哈希槽。

Key 通过 CRC16 计算后映射到某个槽位：

text
HASH_SLOT = CRC16(key) % 16384

如果集群中某个主节点负责的槽位或 Key 数量明显过多，就会出现分片倾斜。

2.2 单个节点内存被打爆

分片倾斜后，某个主节点可能存储大量 Key。

例如：

text
主节点 A：负责 8000 个槽位
主节点 B：负责 4000 个槽位
主节点 C：负责 4384 个槽位

实际业务中，如果大量 Key 集中到同一个节点，该节点会出现：

内存持续增长
RDB 文件变大
持久化变慢
主从复制延迟
重启恢复时间变长
快照生成占用资源

2.3 单节点 CPU 压力集中

即使内存没有完全打爆，如果大量读写请求集中到少数节点，也会导致：

该节点 CPU 升高
查询延迟增加
命令排队
超时重试增加
服务层线程等待
数据库压力上升

2.4 槽位迁移失败影响扩容

当发现分片倾斜后，通常会尝试迁移槽位。

但迁移过程中可能遇到：

槽位中 Key 数量过多
迁移时间过长
客户端重定向异常
源节点压力升高
目标节点接收失败
迁移中途中断
集群状态不一致

2.5 热点副本风险

如果某个主节点故障，从节点会升级为主节点。

但如果该从节点本身复制延迟高、内存压力大、Key 数量多，故障转移后可能继续成为瓶颈。

三、Redis Cluster 常见故障场景

3.1 分片不均衡

现象：

text
节点 A：8000 个槽位
节点 B：4000 个槽位
节点 C：4384 个槽位

原因：

初始分配不合理
扩容时没有重新分布槽位
大量 Key 集中到固定标签
Key 哈希分布异常

3.2 大 Key 集中

现象：

text
product:detail:10001
activity:config:20250602
stock:seckill:10001

某个大 Key 或热点 Key 占用大量内存和 CPU。

3.3 槽位迁移失败

现象：

text
CLUSTER FAILOVER
CLUSTER ADDSLOTS
CLUSTER DELSLOTS
CLUSTER SETSLOT

执行失败或卡住。

原因：

槽位中 Key 数量太多
源节点压力过高
目标节点资源不足
集群状态异常
客户端持续请求影响迁移

3.4 主从复制延迟

现象：

text
replicaof
master_link_down_since_seconds

从节点复制延迟增加。

原因：

主节点写入压力大
网络带宽不足
从节点资源不足
RDB 生成时间长
磁盘 IO 慢

3.5 故障转移后雪崩

现象：

主节点故障
从节点升级
升级后仍然压力大
新主节点继续延迟
集群整体性能下降

四、Redis Cluster 核心排查命令

4.1 查看集群节点

bash
redis-cli cluster nodes

4.2 查看集群信息

bash
redis-cli cluster info

4.3 查看槽位分布

bash
redis-cli cluster slots

4.4 查看 Key 数量

bash
redis-cli dbsize

4.5 查看内存信息

bash
redis-cli info memory

4.6 查看复制信息

bash
redis-cli info replication

4.7 查看统计信息

bash
redis-cli info stats

4.8 查看慢日志

bash
redis-cli slowlog get 10

4.9 扫描大 Key

bash
redis-cli --bigkeys

4.10 扫描热点 Key

bash
redis-cli --hotkeys

五、分片倾斜解决方案

方案一：均衡分配槽位

在创建集群时，尽量让每个主节点负责的槽位数量接近。

例如：

text
3 主节点：每个节点约 5461 个槽位
6 主节点：每个节点约 2730 个槽位

避免出现某个节点负责过多槽位。

方案二：合理选择分片键

业务 Key 设计会直接影响分布。

不推荐：

text
product:detail:10001

如果某些商品热度极高，仍然可能集中。

可考虑增加业务前缀或哈希后缀：

text
product:detail:{10001}:{tag}
product:detail:{10001}:{shard}

但需要根据业务复杂度权衡。

方案三：拆分大 Key

如果某个 Key 特别大，应考虑拆分。

例如：

text
activity:config:20250602

拆成：

text
activity:config:20250602:banner
activity:config:20250602:rule
activity:config:20250602:stock

方案四：热点 Key 副本

对于热点 Key，可以设置多个副本 Key。

例如：

text
product:detail:10001:0
product:detail:10001:1
product:detail:10001:2
product:detail:10001:3

读取时随机选择一个副本 Key。

方案五：本地缓存保护

对于超高热点数据，服务层使用本地缓存。

例如：

text
Caffeine Cache
Guava Cache
Ehcache

减少 Redis Cluster 访问压力。

方案六：分批迁移槽位

如果槽位分布不均，不要一次性迁移大量槽位。

应分批迁移：

text
先迁移 100 个槽位
观察节点压力
再迁移 200 个槽位
观察延迟
继续迁移剩余槽位

方案七：扩容后重新平衡

当集群容量不足时，应及时扩容。

扩容后需要重新平衡槽位分布。

六、生产级 Redis Cluster 配置建议

6.1 主从节点比例

建议：

text
每个主节点配置 1 个从节点

如果对读扩展要求高，可以配置多个从节点。

但从节点过多也会增加复制压力。

6.2 节点规格统一

尽量保证：

CPU 规格接近
内存规格接近
磁盘规格接近
网络带宽接近
部署环境接近

避免出现“弱节点”拖垮整个集群。

6.3 分片键设计

Redis Cluster实战复盘：分片倾斜、槽位迁移失败、热点副本、集群雪崩彻底解决

添加新评论

最新文章

最近回复

分类

归档

其它