Redis Cluster 详解

Redis Cluster 详解

1. 为什么需要 Redis Cluster？

Redis 作为一个高性能的内存数据库，在单机模式下可能会遇到以下问题：

1. 单机容量受限：Redis 是基于内存存储的，单机的内存资源有限，单实例的 Redis 只能存储有限的数据。
2. 单点故障（SPOF）：单机 Redis 宕机后，所有缓存数据都无法访问，影响业务可用性。
3. 性能瓶颈：单机 Redis 受 CPU 和 I/O 限制，无法支撑高并发的访问需求。
4. 扩展性差：单机模式不支持水平扩展，无法通过增加机器来提高存储和计算能力。

Redis Cluster（集群模式） 是 Redis 官方提供的分布式解决方案，主要用于解决以上问题。

2. Redis Cluster 解决了什么问题？有什么优势？

Redis Cluster 解决了以下问题：

1. 数据分片存储，突破单机限制
   • 通过 哈希槽（hash slot）+ 多节点 的方式，将数据存储到多个 Redis 实例中，实现水平扩展。
   • 解决了单机存储受限的问题。
2. 无中心化架构，避免单点故障
   • 传统的 Redis Sentinel 模式存在 主从架构 + 哨兵管理，但仍然有中心节点。
   • Redis Cluster 去中心化，所有节点都存储集群信息，任何节点都可以提供集群状态。
   • 解决了单点故障的问题。
3. 主从复制 + 自动故障转移
   • Redis Cluster 采用主从架构，每个 Master 可以有多个 Slave 备份。
   • 如果某个 Master 宕机，Redis Cluster 会自动提升 Slave 为新的 Master，保证集群可用性。
4. 动态扩展，支持水平扩容
   • Redis Cluster 允许 动态添加 / 删除节点，可以在运行时扩展 Redis 集群，而不会影响业务。
   • 解决了 Redis 单机模式扩展性差的问题。

Redis Cluster 的核心优势

3. Redis Cluster 是如何分片的？

Redis Cluster 采用 哈希槽（hash slot）+ 数据分片 机制进行数据分片：

1. 整个集群有 16384 个哈希槽（slot）。

2. 每个 Key 通过哈希算法分配到某个哈希槽：

   • slot = CRC16(key) % 16384
   • CRC16 是一种高效的哈希计算方法。

3. 哈希槽分布到不同的 Redis 节点：

   • 例如：3 个 Redis 节点，每个节点存储部分哈希槽：

     节点 A：0 - 5460
     节点 B：5461 - 10922
     节点 C：10923 - 16383
     

   • 如果有新的节点加入，Redis Cluster 会重新分配哈希槽。

4. 为什么 Redis Cluster 的哈希槽是 16384 个？

Redis Cluster 选择 16384 作为固定的哈希槽数量，主要基于以下考虑：

1. 兼容 CRC16 计算
   • Redis 使用 CRC16 算法计算 Key 的哈希值，并使用 模运算（% 16384） 确定哈希槽。
   • 16384（2¹⁴）是 2 的幂，计算高效。
2. 负载均衡
   • 16384 个槽足够均匀地分配到多个节点，避免热点数据集中在某个节点。
3. 迁移成本低
   • 槽的数量适中，在节点增加/删除时，可以快速迁移哈希槽，减少数据重新分布的影响。
4. 适用于大规模集群
   • 16384 个槽能支持数百个 Redis 节点，适用于不同规模的集群扩展。

5. 如何确定给定 key 应该分布到哪个哈希槽中？

Redis Cluster 通过 CRC16 哈希算法 计算 key 的哈希槽：

slot = CRC16(key) % 16384

示例：

import crcmod

crc16 = crcmod.predefined.Crc('crc-16')
crc16.update(b'mykey')
slot = crc16.crcValue % 16384
print(slot)  # 输出哈希槽号

Redis 客户端会计算 Key 的哈希槽，并直接请求对应的 Redis 节点。

6. Redis Cluster 支持重新分配哈希槽吗？

是的，Redis Cluster 允许动态调整哈希槽分配，以支持扩容或缩容：

• 增加新节点：
  • 新增节点后，部分哈希槽会从已有 Master 迁移到新节点。
  • 使用 redis-cli --cluster reshard 进行槽位重新分配。
• 删除节点：
  • 删除节点时，节点上的哈希槽会迁移到其他节点。

哈希槽迁移过程：

1. CLUSTER SETSLOT IMPORTING
2. CLUSTER SETSLOT MIGRATING
3. 数据同步
4. 更新哈希槽信息

7. Redis Cluster 扩容/缩容期间可以提供服务吗？

可以！Redis Cluster 支持在线扩容/缩容，在数据迁移过程中仍然可以提供服务：

1. 客户端访问时，可能会遇到 MOVED 重定向
   • 例如：客户端请求 Key 时，如果 Key 的哈希槽迁移到了新的节点，返回 MOVED <slot> <new-node-ip>，客户端会重新请求正确的节点。
2. 数据在后台迁移，不影响正常读写
   • Redis Cluster 采用 渐进式迁移，不会一次性移动所有数据，而是逐步将哈希槽数据转移到新节点。

8. Redis Cluster 中的节点是如何通信的？

Redis Cluster 采用 Gossip 协议 进行节点间通信，保证集群状态一致：

• PING：定期发送心跳检测其他节点的状态。
• PONG：响应 PING，并附带本节点的状态信息。
• MEET：新节点加入集群时，使用 MEET 命令。
• FAIL：如果多数节点判定某个 Master 故障，则广播 FAIL 信息，触发故障转移。

每个 Redis Cluster 节点都维护整个集群的拓扑信息，即便某些节点故障，集群仍然可以继续运行。

9. Redis Cluster 缓存的数据量太大怎么办？

当 Redis Cluster 的数据量过大时，可以采取以下措施：

• 水平扩展（增加节点）：增加新的 Redis 节点，并重新分配哈希槽，使新节点分担数据存储压力。
• 数据淘汰策略：使用 maxmemory-policy 进行数据淘汰，如 volatile-lru、allkeys-lru 等。
• 数据压缩：对于字符串、JSON 数据，可以使用 Snappy、Gzip 等方式进行压缩，减少存储占用。
• 冷热数据分层：将热数据存入 Redis，冷数据存入 MySQL、MongoDB 等持久化存储中。
• 使用 BigKey 拆分：避免存储大 key（如超大列表、集合、哈希），可以拆分为多个小 key 存储。

10. Redis Cluster 的基本架构

一个典型的 Redis Cluster 由多个 Redis 实例组成，每个实例可以是主节点（Master）或从节点（Slave）：

• 主节点（Master）：负责存储数据并处理客户端请求，每个 Master 管理一部分哈希槽。
• 从节点（Slave）：作为 Master 的备份，提供高可用性，Master 宕机时从节点可自动提升为 Master。
• 客户端（Client）：连接 Redis Cluster，向不同的 Master 发送请求，并根据哈希槽计算数据存储位置。

Redis Cluster 默认使用 无中心化架构，每个节点既存储数据，又维护整个集群的元数据（比如槽位信息、其他节点状态等）。

总结

Redis Cluster 通过数据分片 + 无中心化架构 + 自动故障恢复，实现了高可用、可扩展的分布式 Redis！ 🚀

扩展阅读

1. Redis Cluster 的哈希槽为什么是 16384？

Redis Cluster 采用 16384 个哈希槽（slot）来进行数据分片和管理，主要基于以下几个原因：

(1) 兼顾性能与灵活性

• 太少的哈希槽：如果哈希槽数量太少，例如 1024，数据分布会很粗糙，负载均衡效果不佳。
• 太多的哈希槽：如果哈希槽数量过多（如 10^6 级别），每次集群管理和迁移操作都会涉及大量计算，增加开销。

16384 是一个合理的折中方案，它既能保证数据分布的均衡性，又能在扩展和迁移时保持较低的计算和存储成本。

(2) CRC16 计算的高效性

Redis Cluster 采用 CRC16（循环冗余校验）算法计算哈希槽：

Slot = CRC16(Key) % 16384

CRC16 是一种高效的哈希计算方式，16384（2¹⁴）是 2 的幂，可以通过位运算高效计算哈希槽。

(3) 分片和迁移的平衡

• 16384 个槽可以被

  多个 Master 节点

  平均分配。例如：

  • 3 个 Master：每个 Master 约管理 5461 个槽（16384 ÷ 3）。
  • 6 个 Master：每个 Master 约 2730 个槽（16384 ÷ 6）。

• 这样，扩容和数据迁移时，不会造成太大的数据重分布，迁移成本较低。

(4) 兼容性

Redis Cluster 设计时考虑到 多个 Redis 实例部署在多个服务器上，16384 适用于不同规模的集群：

• 小规模集群（3~6 个节点）→ 适量的槽可保证均衡分配。
• 大规模集群（数十个节点）→ 16384 个槽依然可以较好地分片。

2. 什么是 Gossip 协议？

(1) Gossip 协议的基本概念

Gossip 协议是一种 去中心化的分布式通信协议，用于 节点之间同步信息，类似于“八卦传播”：

• 每个节点只与部分其他节点通信，而不是全网广播。
• 信息在多个通信轮次后，逐步传播到整个集群。

Redis Cluster 采用 Gossip 协议 来管理节点状态，保持集群的可用性。

(2) Redis Cluster 中的 Gossip 协议

在 Redis Cluster 中，每个节点都会定期向部分节点 发送状态信息，以此来同步集群状态，确保各个节点了解彼此的情况。

Gossip 协议中的几种消息

1. PING：节点定期向其他节点发送 PING 消息，询问对方状态。
2. PONG：收到 PING 后，节点返回 PONG 作为响应，并附带自己的状态信息。
3. MEET：新节点加入集群时，使用 MEET 消息通知集群中的其他节点。
4. FAIL：如果某个 Master 节点被大多数节点判定为不可用，整个集群会广播 FAIL 消息，触发故障转移。

示例

假设 Redis Cluster 有 6 个节点：

A  B  C  D  E  F

• A 发送 PING 给 B 和 C。
• B 发送 PING 给 D 和 E。
• C 发送 PING 给 F 和 A。
• 经过几轮传播后，所有节点都可以获取最新的集群状态。

(3) Gossip 协议的优点

1. 去中心化：无中心服务器，避免单点故障。
2. 高效传播：不像传统的全网广播，Gossip 只向部分节点发送信息，网络开销更小。
3. 容错性强：即使部分节点故障，其他节点仍可继续传播信息，保证集群健康。

总结

Gossip 让 Redis Cluster 实现了 去中心化管理、高效容错，结合 16384 哈希槽的设计，使得 Redis Cluster 既能 高效分片存储，又能 保证集群高可用！