redis sentinel和redis cluster的主从切换选举过程
Redis Cluster与Sentinel集群主从切换选举机制深度解析
一、Redis Sentinel的选举机制
-
监控与故障判定
Sentinel集群通过心跳检测(每秒一次PING)监控主节点状态:- 主观下线:单个Sentinel节点检测到主节点无响应
- 客观下线:超过半数Sentinel确认主节点失效(如3节点集群需2个确认)
-
候选从节点筛选
满足以下条件的从节点进入候选池:- 网络连接正常(排除频繁断连的节点)
- 数据同步延迟在阈值内(
cluster-node-timeout * slave-validity-factor
)
-
三轮选举规则
Sentinel采用多维度优先级排序:- 第一轮:优先级最高(
slave-priority
配置值最小) - 第二轮:复制偏移量最大(数据最新)
- 第三轮:节点ID最小(最终裁决条件)
- 第一轮:优先级最高(
-
领导者选举
采用Raft算法选举Sentinel Leader:- 每个Sentinel节点自荐并收集选票
- 得票过半者成为Leader,负责执行主从切换
-
切换执行
Sentinel Leader向从节点发送SLAVEOF
命令,并通知客户端新主节点信息
二、Redis Cluster的选举机制
-
故障检测
基于Gossip协议实现去中心化检测:- 节点间定期交换状态信息(PING/PONG消息)
- 主节点失联超过
cluster-node-timeout
视为PFail - 多数主节点确认后升级为Fail状态
-
从节点资格验证
满足以下条件才可参选:- 与原主节点断连时间未超过
cluster-node-timeout * 2
- 数据复制偏移量最大(优先保留最新数据)
- 与原主节点断连时间未超过
-
选举投票机制
采用分布式投票协议:- 从节点广播
CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST
- 主节点根据配置纪元(epoch)投票,每个主节点每纪元仅投一票
- 获得
N/2 +1
票数(N为有效主节点数)即当选
- 从节点广播
-
新主节点接管
选举成功后执行关键操作:- 撤销原主节点的哈希槽分配
- 通过Gossip协议广播新主节点信息
- 触发其他从节点同步新主数据
# 伪代码示例:Cluster选举核心逻辑
def handle_failover():if current_node.is_slave:if master.failed and self.offset_max:request_votes()elif current_node.is_master:if received_vote_request and epoch_valid:send_vote()
三、核心差异对比
特性 | Redis Sentinel | Redis Cluster |
---|---|---|
架构定位 | 外部监控系统 | 内置集群协议 |
选举触发者 | Sentinel Leader | 从节点自主发起 |
投票机制 | 需多数Sentinel同意 | 需半数以上主节点投票 |
数据一致性保障 | 切换期间短暂不可写 | 槽迁移完成前阻塞写入 |
网络要求 | 低带宽消耗 | 高带宽(Gossip协议通信) |
适用场景 | 中小规模集群 | 大规模分布式部署 |
四、最佳实践建议
-
Sentinel部署要点
- 至少部署3个Sentinel节点防止脑裂
- 设置合理的
down-after-milliseconds
(建议≥30s)
-
Cluster优化策略
- 控制节点规模(建议≤1000节点)
- 调整
cluster-node-timeout
(推荐10-15秒) - 使用
redis-cli --cluster check
定期检测槽分配
-
通用注意事项
- 避免跨数据中心部署(网络延迟影响选举)
- 监控
master_link_status
和connected_slaves
指标 - 测试故障切换时间(通常Sentinel 10-30秒,Cluster 1-15秒)
五、延伸思考
-
脑裂问题处理
两种架构都可能出现网络分区导致的双主现象:- Sentinel通过
min-slaves-to-write
防止数据丢失 - Cluster通过
require-full-coverage
配置控制分区容忍度
- Sentinel通过
-
数据一致性挑战
- 异步复制丢失:切换期间未同步的写入可能丢失
- 解决方案:启用
WAIT
命令强制同步复制(性能折损)
-
混合云场景适配
在多云环境中需特别注意:- 调整
cluster-announce-ip
避免私有IP暴露 - 使用TLS加密Gossip通信(Redis 6.0+支持)
- 调整
通过深入理解这两种机制,开发者可以根据业务规模、数据量级和可用性要求,选择最适合的Redis高可用方案。实际生产环境中,Sentinel更适用于读写分离场景,而Cluster则是大数据量、高并发场景的首选。