redis sentinel和redis cluster的主从切换选举过程

news2025/5/12 16:09:21

引言

redis sentinel和redis cluster的主从切换选举过程不同，本文将从选举机制、核心差异对比两者的不同。

一、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配置控制分区容忍度
数据一致性挑战
- 异步复制丢失：切换期间未同步的写入可能丢失
- 解决方案：启用WAIT命令强制同步复制（性能折损）
混合云场景适配
在多云环境中需特别注意：
- 调整cluster-announce-ip避免私有IP暴露
- 使用TLS加密Gossip通信（Redis 6.0+支持）