Redis Cluster集群详解

数据分片（Sharding）

• 哈希槽（Hash Slot）机制：

• • 集群将数据划分为 16384 个哈希槽，每个键通过 CRC16(key) % 16384 计算归属的槽。
  • 槽分配给多个主节点，每个节点负责一部分槽（例如：3节点集群中，每个节点可能管理约 5461 个槽）。

• 动态槽分配：

• • 节点增减时，槽可动态迁移，支持在线扩容/缩容（如 CLUSTER ADDSLOTS 命令）。

• 跨槽操作限制：

• • 事务、Lua 脚本需确保所有键在同一槽（可通过 哈希标签 {} 强制相同槽，如 user:{123}）。

去中心化节点

Gossip 协议通信：

• 节点间通过 PING/PONG 消息交换集群状态（节点存活、槽分配等），无需中心节点；
• 每个节点维护全量集群元数据（节点列表、槽分布等）。

自管理能力：

• 新节点通过已知节点加入集群，自动传播信息；故障节点由多数节点共识判定失效。

故障转移：

• 每个主节点有一个 配置纪元（Configuration Epoch），表示该节点当前的配置版本号（整数，单调递增）；
• 当集群状态变更（如槽迁移、主从切换）时，相关节点的纪元值会更新，确保新配置的优先级高于旧配置。

高可用

主从复制：

• 每个主节点（Master）有 1 或多个从节点（Slave），数据异步复制；
• 从节点在主节点故障时，通过 Raft 算法选举 晋升为主节点（需多数主节点确认）。

故障转移

集群中的主节点故障转移由故障检测、选举新主节点、集群状态更新三个阶段组成。

故障检测阶段

• 节点间心跳超时则标记其为疑似下线（PFAIL）；
• 集群中超过半数主节点确认后标记为下线（FAIL），触发故障转移;

从节点发起选举

• 从节点向集群所有主节点发送 CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST 请求投票；
• 主节点收到请求后，检查以下条件：

1. 1. 发起投票的从节点的主节点确实已客观下线
   2. 主节点在当前配置纪元（Epoch）内尚未投过票
   3. 发起投票的从节点的数据复制偏移量是最新的

• 满足条件则投票：主节点回复 CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK；
• 从节点获取超过半数投票后，晋升为主节点，接管圆主节点的哈希槽，生成新的配置纪元。

集群状态更新

• 新主节点通过 PONG 消息向集群广播，包括自身成为主节点、负责的哈希槽、新的配置纪元；
• 其他节点收到消息后，更新哈希槽映射表，记录新的配置纪元。

数据一致性

集群中的数据同步是异步进行的，所以不可避免的会出现数据不一致问题，下面是一些不同场景的解决办法

故障转移

• 场景：故障转移前，主节点故障，未同步到从节点的数据会丢失；
• 解决方案：配置 min-replicas-to-write，要求主节点必须至少有n个从节点确认写入，才返回写操作成功；
• 缺点：会牺牲高可用性。

写后读不一致

• 场景：客户端写入数据后，立刻读取，从节点数据尚未同步到最新数据，会返回旧值；
• 解决方案：除了要求写操作等待从节点同步后再返回外，还可以在客户端限制同一个session的读请求命中主节点。
• 缺点：牺牲高可用性。

脑裂

• 场景：集群被分裂为多个孤立的子网络，每个子网络中的节点都认为其他节点已下线，表现为同一个哈希槽在不同子网络中被多个主节点同时写入，导致数据冲突；
• 解决方案：配置 min-slaves策略，主节点仅在至少有N个从节点存活时才接受写入，降低脑裂概率；
• 缺点：无法解决双主写入（还没有完全理解～）。

限制与适用场景

• 最大节点数：建议不超过 1000 个节点（Gossip 通信开销限制）。
• 适用场景：适合高吞吐、低延迟的键值访问，不适用于需强一致性或跨节点事务的场景。