【Redis】Cluster集群Day11（2026年）

写在前面

在之前的文章中，我们学习了Redis的主从复制和哨兵模式，它们解决了数据备份和故障转移的问题。但当数据量越来越大，单机内存无法满足需求时，我们就需要Redis Cluster集群方案了。今天我们就来深入理解Redis Cluster的原理与实践。

一、为什么需要Redis Cluster

1.1 单机Redis的瓶颈

实际场景：某电商平台的商品数据达到500GB，单机Redis内存只有64GB，无法存储全部数据，怎么办？

单机Redis面临的问题：

1.2 传统方案的局限性

主从复制：只能做数据备份，无法扩展存储容量

哨兵模式：实现高可用，但仍然是单机存储，数据量受限于单机内存

客户端分片：在客户端做数据分片，但需要客户端维护分片逻辑，迁移困难

1.3 Redis Cluster的优势

Redis Cluster是Redis官方提供的分布式解决方案，具有以下特点：

• 数据分片：自动将数据分散到多个节点
• 高可用：每个分片都有主从复制
• 去中心化：无中心节点，所有节点平等
• 自动故障转移：节点故障时自动切换
• 在线扩缩容：支持动态添加删除节点

二、Cluster原理详解

2.1 哈希槽（Hash Slot）机制

核心原理：Redis Cluster采用虚拟槽分区，将键空间划分为16384个槽，每个节点负责一部分槽。

# 计算key属于哪个槽 CLUSTER KEYSLOT mykey # 返回槽号，如：12546

槽位计算公式：

slot = CRC16(key) % 16384

2.2 为什么是16384个槽？

面试高频考点：为什么Redis Cluster使用16384个槽，而不是65536或其他数值？

经验之谈：在实际生产环境中，Redis Cluster建议主节点数量不超过1000个，16384个槽完全够用。

2.3 集群架构图

┌─────────────────────────────────────────────────────────┐ │ Redis Cluster │ ├─────────────────────────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Master A │ │ Master B │ │ Master C │ │ │ │ 槽0-5461 │ │槽5462-10922│ │槽10923-16383│ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ │ │Slave A' │ │Slave B' │ │Slave C' │ │ │ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────────────────────┘

2.4 节点通信机制

Redis Cluster采用Gossip协议进行节点间通信：

三、Cluster配置实战

3.1 集群规划

实际场景：搭建一个3主3从的Redis Cluster集群，6个节点分别部署在不同服务器上。

节点规划：

3.2 配置文件

每个节点的redis.conf配置：

# 开启集群模式 cluster-enabled yes # 集群配置文件（自动生成） cluster-config-file nodes-6379.conf # 节点超时时间（毫秒） cluster-node-timeout 15000 # 开启AOF持久化 appendonly yes # 绑定IP bind 0.0.0.0 # 保护模式关闭 protected-mode no # 端口 port 6379 # 后台运行 daemonize yes

3.3 创建集群

使用redis-cli创建集群：

# Redis 5.0+ 使用以下命令redis-cli--clustercreate\192.168.1.101:6379\192.168.1.102:6379\192.168.1.103:6379\192.168.1.104:6379\192.168.1.105:6379\192.168.1.106:6379\--cluster-replicas1

参数说明：

• --cluster-replicas 1：每个主节点有1个从节点

3.4 集群常用命令

# 查看集群信息 CLUSTER INFO # 查看集群节点 CLUSTER NODES # 查看key所在的槽 CLUSTER KEYSLOT mykey # 查看槽所在节点 CLUSTER GETKEYSINSLOT 12546 10

四、数据迁移

4.1 槽位迁移

实际场景：需要向集群添加一个新节点，需要重新分配槽位。

添加新节点：

# 添加新主节点redis-cli--clusteradd-node192.168.1.107:6379192.168.1.101:6379# 重新分配槽位redis-cli--clusterreshard192.168.1.101:6379

迁移过程：

1. 目标节点导入槽位
2. 源节点逐个迁移key
3. 更新集群元数据
4. 迁移完成

4.2 数据迁移注意事项

五、故障转移

5.1 故障检测

Redis Cluster故障检测流程：

节点A发送PING → 节点B无响应 → 标记PFAIL(疑似下线) ↓ 多数节点确认PFAIL → 标记FAIL(真正下线) ↓ 从节点发起选举 → 选举成功 → 升级为主节点

5.2 故障转移过程

踩坑提醒：故障转移期间，部分请求可能返回MOVED错误，客户端需要正确处理重定向。

故障转移步骤：

1. 从节点检测到主节点下线
2. 从节点发起选举请求
3. 获得多数主节点投票
4. 从节点升级为主节点
5. 更新集群槽位映射
6. 通知其他节点

5.3 手动故障转移

# 在从节点上执行，手动升级为主节点 CLUSTER FAILOVER # 强制故障转移（不等待主节点确认） CLUSTER FAILOVER FORCE # 接管故障主节点（主节点已下线） CLUSTER FAILOVER TAKEOVER

六、踩坑提醒

6.1 跨槽查询问题

踩坑提醒：Redis Cluster中，多key操作（如MGET、MSET）要求所有key在同一个槽，否则报错！

错误示例：

# 这两个key可能在不同槽 MGET user:1:name user:2:name # 报错：CROSSSLOT Keys in request don't hash to the same slot

解决方案：使用Hash Tags

# 使用{}指定hash tag，大括号内的内容参与槽计算 MGET {user}:1:name {user}:2:name # 这样两个key会落在同一个槽

6.2 批量操作限制

6.3 客户端连接

经验之谈：建议使用支持集群模式的客户端，如Jedis、Lettuce、redis-py-cluster等，它们会自动处理MOVED和ASK重定向。

6.4 集群配置常见错误

七、Cluster与哨兵对比

7.1 功能对比

7.2 适用场景

选择Cluster：

• 数据量大，需要分片存储
• 需要横向扩展
• 单机内存无法满足需求

选择哨兵：

• 数据量不大
• 主要需要高可用
• 部署运维简单

八、面试高频考点

8.1 Redis Cluster和哨兵的区别？

答案：

Redis Cluster和哨兵的主要区别在于：

1. 功能定位：哨兵主要解决高可用问题，Cluster既解决高可用又解决数据分片问题

2. 数据存储：哨兵模式下所有数据在单机，Cluster数据分散在多个节点

3. 扩展性：Cluster支持在线扩缩容，哨兵不支持

4. 最小部署：Cluster至少需要6个节点，哨兵需要3个节点（1主2从+3哨兵）

5. 客户端：Cluster需要支持集群协议的客户端，哨兵使用普通客户端即可

8.2 为什么Redis Cluster使用16384个槽？

答案：

1. 心跳包大小：16384个槽只需要2KB位图表示，65536需要8KB，节省网络带宽

2. 节点数量限制：实际生产中主节点不超过1000个，16384个槽足够分配

3. 数据迁移粒度：槽位太多会导致迁移粒度过细，增加迁移复杂度

4. 历史原因：设计时的权衡结果，兼顾了效率和实用性

8.3 Redis Cluster如何保证数据一致性？

答案：

1. 异步复制：主节点写入后异步同步到从节点，存在短暂不一致

2. 最终一致性：网络正常情况下，数据最终会一致

3. 读写分离：默认读写都在主节点，保证强一致性

4. WAIT命令：可以使用WAIT命令等待复制完成

九、参考资料

Redis官方文档 - Redis Cluster

十、互动话题

1. 你的项目中是否使用过Redis Cluster？遇到了哪些问题？
2. 在数据迁移过程中，如何保证业务的平滑过渡？
3. 对于小规模数据，你会选择Cluster还是哨兵模式？为什么？

欢迎在评论区分享你的经验和看法！

下期预告：Day12我们将学习Redis缓存应用实战，深入理解缓存穿透、击穿、雪崩的解决方案。