详解Redis 集群的核心原理与架构

Redis 集群是 Redis 官方提供的分布式解决方案，通过 数据分片、高可用性 和 去中心化架构，解决了单机 Redis 在容量、吞吐量和可用性方面的瓶颈。以下是 Redis 集群的核心原理与架构详解：

一、核心原理

1. 数据分片（Sharding）

• 哈希槽（Hash Slot）：
  • Redis 集群将整个数据集划分为 16384 个哈希槽（0~16383）。
  • 每个键通过公式 CRC16(key) % 16384 计算所属的槽位。
  • 槽位分配：集群启动时，管理员或工具（如 redis-cli --cluster）将 16384 个槽位分配给主节点。例如，3 个主节点各分约 5461 个槽。
  • 槽位映射表：集群维护一个槽位映射表，记录每个槽位由哪个主节点负责。

2. 节点角色

• 主节点（Master）：
  • 负责存储数据（处理分配给它的槽位的数据），处理读写请求。
  • 参与故障转移投票（选举新主节点）。
• 从节点（Replica/Slave）：
  • 异步复制主节点的数据（用于故障转移和读写分离）。
  • 当主节点宕机时，符合条件的从节点可晋升为新主节点，接管原主节点的槽位。

3. 节点间通信（Gossip 协议）

• Cluster Bus：
  • 每个节点通过一个额外的 TCP 端口（默认端口号 + 10000，如 16379）进行通信，称为 集群总线（Cluster Bus）。
• Gossip 协议：
  • 节点间通过定期发送 Ping/Pong 消息 维护集群状态（节点信息、槽位分配、故障检测等）。
  • 消息类型：
    • MEET：节点间初次握手。
    • PING/PONG：定期交换状态信息。
    • FAIL：通知其他节点某个节点已下线。

4. 故障检测与转移

• 故障检测：
  • 节点通过 Gossip 协议检测其他节点的存活状态。如果某个节点在 cluster-node-timeout 时间内未响应，会被标记为 主观下线（PFail）。
  • 当大多数主节点同意某节点已下线时，标记为 客观下线（Fail）。
• 故障转移：
  • 故障主节点的从节点发起选举（基于 Raft 算法变种），选出新主节点。
  • 新主节点接管原主节点的槽位，并同步数据（全量同步或增量同步）。

5. 客户端路由

• Smart 客户端：
  • 客户端缓存槽位→节点的映射关系，直接访问目标节点。
  • 如果访问的键不在当前节点，节点返回 MOVED 或 ASK 重定向：
    • MOVED：槽位已永久迁移到其他节点，客户端更新本地缓存。
    • ASK：槽位正在迁移，客户端临时重定向到目标节点（不更新缓存）。

二、架构组成

1. 最小集群规模

• 推荐配置：至少 3 个主节点 + 3 个从节点（每个主节点一个从节点）。
• 去中心化设计：所有节点地位平等，无中心节点（Master of Masters）。

2. 节点通信拓扑

• Gossip 协议：节点间通过 Cluster Bus 通信，逐步传播集群状态变化（如槽位迁移、故障转移）。
• 心跳机制：节点定期发送 Ping/Pong 消息，维护集群视图一致性。

3. 数据复制与高可用

• 主从复制：从节点异步复制主节点数据，提供读写分离和故障恢复能力。
• 数据一致性：故障转移后，新主节点通过 RDB/AOF 持久化文件恢复数据，确保服务连续性。

4. 扩展与缩容

• 扩容：添加新节点后，通过迁移槽位（CLUSTER SLOTS 命令）将数据分布到新节点。
• 缩容：下线节点前需迁移其负责的槽位到其他节点，再通过 CLUSTER FORGET 命令移除。

三、关键特性

特性	说明
数据分片	通过哈希槽实现数据水平拆分，支持横向扩展。
高可用性	主从复制 + 自动故障转移，保障服务持续可用。
去中心化	无中心节点，节点间通过 Gossip 协议协作，避免单点故障。
客户端智能路由	Smart 客户端缓存槽位映射，减少重定向开销，提升性能。
动态扩展	支持在线扩容/缩容，通过迁移槽位实现无缝扩展。

四、对比哨兵模式与集群模式

特性	哨兵模式（Sentinel）	集群模式（Cluster）
数据分片	不支持，所有数据存储在主节点。	支持，数据分片到多个主节点。
高可用性	自动故障转移，需手动配置主从关系。	自动故障转移 + 数据分片，无需人工干预。
扩展性	不支持横向扩展，仅能增加从节点。	支持横向扩展，通过添加主节点增加容量。
客户端支持	需要客户端连接哨兵获取主节点地址。	Smart 客户端直接与集群交互，无需哨兵。
适用场景	小规模部署，需读写分离和故障转移。	大规模分布式系统，需高可用和水平扩展。

五、典型应用场景

1. 大规模数据存储：单机内存不足时，通过分片提升存储容量。
2. 高并发读写：通过多主节点分担请求压力，提升吞吐量。
3. 高可用服务：主从复制 + 故障自动转移，保障业务连续性。
4. 分布式缓存：结合客户端路由，实现缓存数据的分布式管理。

六、最佳实践

1. 合理规划槽位分配：确保每个主节点负责的槽位数量均衡。
2. 监控与告警：使用工具（如 Redis 自带的 CLUSTER 命令、Prometheus）监控节点状态和槽位分布。
3. 备份策略：定期备份 RDB/AOF 文件，防止数据丢失。
4. 网络优化：确保节点间网络稳定，避免 Gossip 消息延迟导致的故障误判。
5. 客户端选择：使用支持 Smart 客户端的库（如 Redisson、Lettuce），优化路由效率。

七、示例操作

1. 创建集群

# 使用 redis-cli 工具创建集群（假设有 3 个主节点和 3 个从节点）
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

2. 查看集群信息

redis-cli -c -h 127.0.0.1 -p 7000 CLUSTER NODES
redis-cli -c -h 127.0.0.1 -p 7000 CLUSTER SLOTS

3. 手动故障转移

# 触发从节点晋升为主节点
redis-cli -c -h 127.0.0.1 -p 7003 CLUSTER FAILOVER

八、总结

Redis 集群通过 哈希槽分片、Gossip 协议通信 和 主从复制，实现了数据的分布式存储与高可用性。其去中心化架构和动态扩展能力，使其成为大规模分布式系统的核心组件。结合 Smart 客户端和合理的运维策略，可以构建高性能、高可用的 Redis 集群服务。