3. Redis Cluster 故障转移：集群分片、主从切换、Gossip 协议
在模板引擎缓存场景中，Redis Cluster 提供了无中心化的分布式缓存能力。当集群中某个主节点宕机时，其对应的从节点会自动提升为新的主节点，整个过程对业务层透明。本章深入剖析集群分片、主从切换机制以及 Gossip 协议的核心原理。
3.1 集群分片：16384 个槽位
Redis Cluster 采用虚拟哈希槽（Hash Slot）进行数据分片，整个集群固定划分为 16384 个槽位。每个键通过 CRC16 算法计算后对 16384 取模，决定其归属槽位。槽位均匀分布在集群中的各个主节点上。
| 概念 | 说明 | 模板引擎缓存场景示例 |
|---|---|---|
| 哈希槽总数 | 16384（固定值） | 所有模板缓存键均匀映射到槽位 |
| 槽位分配 | 每个主节点负责一段连续的槽位区间 | 3 主节点集群：0-5460、5461-10922、10923-16383 |
| 键定位 | CRC16(key) % 16384 | template:home:header 定位到槽位 1024 |
| 槽位迁移 | 动态调整节点负责的槽位范围 | 扩容时平滑迁移缓存数据 |
关键设计：16384 个槽位在集群内部通过
CLUSTER ADDSLOTS 命令分配给各主节点。客户端通过 CLUSTER NODES 或 CLUSTER SLOTS 获取槽位分布映射表，实现请求直连目标节点。
3.2 主从切换：故障检测与自动提升
当主节点发生故障（如宕机、网络分区）时，集群中的从节点会自动发起选举，成为新的主节点。整个过程分为故障检测和故障转移两个阶段。
3.2.1 故障检测流程
- PING/PONG 超时：集群中每个节点定期向其他节点发送 PING 消息，若在
cluster-node-timeout内未收到 PONG，则标记该节点为PFAIL（疑似下线）。 - Gossip 传播：节点通过 Gossip 消息将 PFAIL 状态传播给集群中的其他节点。
- 故障确认：当超过半数的主节点（含发起节点）都认为某节点为 PFAIL 时，该节点被标记为
FAIL（正式下线）。
模板引擎缓存影响：故障检测期间（默认 15 秒），客户端可能收到
MOVED 或 ASK 重定向。建议在客户端侧实现自动重试和槽位缓存刷新，避免缓存穿透。
3.2.2 从节点选举与提升
当主节点被标记为 FAIL 后，其从节点发起选举，竞选新的主节点：
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 从节点发起选举 | 从节点自增 currentEpoch，向集群广播 FAILOVER_AUTH_REQUEST |
| 2 | 主节点投票 | 每个主节点在每个 epoch 内只能投一票，投票给数据最新的从节点 |
| 3 | 获得多数票 | 从节点获得超过半数主节点的投票（N/2 + 1） |
| 4 | 角色切换 | 从节点执行 SLAVEOF NO ONE，成为新主节点，接管所有槽位 |
| 5 | 广播更新 | 新主节点通过 Gossip 广播自身状态，集群更新拓扑 |
3.3 Gossip 协议：集群状态传播
Gossip 协议是 Redis Cluster 无中心化通信的基石。每个节点定期与其他节点交换状态信息，实现最终一致性的集群视图。
3.3.1 消息类型
| 消息类型 | 方向 | 内容 | 触发条件 |
|---|---|---|---|
| PING | 节点 → 节点 | 自身状态 + 随机其他节点状态 | 每 1 秒随机选择一个节点发送 |
| PONG | 节点 → 节点 | 回复 PING，携带自身完整状态 | 收到 PING 后立即回复 |
| MEET | 节点 → 节点 | 邀请新节点加入集群 | 新节点加入时发送 |
| FAIL | 节点 → 节点 | 广播某节点已下线 | 故障确认后广播 |
| PUBLISH | 节点 → 节点 | 广播消息到集群 | 客户端 PUBLISH 命令触发 |
3.3.2 传播机制
- 周期性推送：每个节点每秒向随机一个节点发送 PING，携带自身
epoch、槽位信息、节点状态。 - 反熵修复：当节点发现对方状态落后时，主动推送缺失信息，保证集群状态收敛。
- 故障传播：PFAIL/FAIL 状态通过 Gossip 在几秒内扩散到整个集群，触发从节点选举。
模板引擎缓存注意事项：Gossip 协议是最终一致性模型，故障传播存在延迟（通常 3-5 秒）。在故障转移期间，客户端可能短暂访问到已下线的节点。建议在客户端侧实现 MOVE 重定向缓存 和 连接池快速失效 机制。
3.4 模板引擎缓存容错配置建议
生产环境推荐配置：
# 集群节点配置
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 15000 # 故障检测超时
cluster-slave-validity-factor 10 # 从节点数据有效性因子
cluster-migration-barrier 1 # 主节点至少保留的从节点数
cluster-require-full-coverage no # 部分槽位不可用时仍提供服务
# 客户端侧配置
# 启用集群模式，自动处理 MOVED/ASK 重定向
# 设置连接池最大等待时间 < cluster-node-timeout
# 开启自动刷新槽位缓存（如 JedisCluster 的 maxAttempts）通过合理配置集群参数和客户端容错策略，模板引擎缓存可以在节点故障时实现秒级自动恢复，保障业务层缓存命中率和响应速度。