8 Redis 高可用进阶（主从容灾→选举机制→哨兵机制）

8 Redis 高可用进阶（主从容灾→选举机制→哨兵机制）

8.1 主从复制的容灾机制

8.1.1 概述

1. 背景
   主从复制的核心是「数据多副本」，主节点数据实时同步到从节点，这是容灾的基础（避免单节点硬盘损坏 / 宕机导致数据丢失）。
2. 主从复制容灾核心缺点
   主从复制无自动故障处理能力，主节点故障后，从节点默认只读，无法自动接管业务，需「手动干预」恢复，这是主从的致命缺陷 ------ 生产环境中，手动恢复效率低，会导致业务长时间阻塞，因此需要「自动选主 + 自动恢复」的机制（选举 + 哨兵）。
3. 手动容灾核心逻辑
   主节点故障 → 确认故障 → 挑选同步完整的从节点 → 提升该从节点为新主 → 其他从节点同步新主 → 业务切换连接地址 → 旧主恢复后改为从节点（避免脑裂，即脑裂就是集群中出现两个能正常写数据的主节点，相当于一个集群分裂成两个独立大脑，各自接收业务写）。

8.1.2 示例

以下演示为命令行临时配置，仅写入 Redis 运行内存，立即生效无需重启，Redis 重启后所有配置失效（旧进程销毁，内存配置丢失，重启后读取redis.conf初始化）。
下面演示的命令，比如：
REPLICAOF NO ONE、REPLICAOF 新主IP 新主端口、CONFIG SET masterauth 密码，都是临时生效。
若需将当前临时配置持久化到redis.conf（重启不失效，需 Redis 进程有配置文件写入权限），执行：

CONFIG REWRITE

注：Redis 重启时，会根据节点当前身份（主 / 从），自动清理redis.conf中与身份不符的无效配置（如主节点会删除replicaof项）。

1. 前提
   确保部署 1 主 2 从 Redis 实例，且主从同步正常。
   

2. 确认主节点故障
   关闭主节点
   
   确认主节点不可用
   

3. 挑选合适的从节点（选同步最完整的，避免数据丢失）
   查看同步状态，重点看 master_repl_offset（值越大，同步越完整）。
   
   
   把offset 最大的，作为目标提主节点。一样就随便选一个。

4. 将目标从节点提升为新主节点
   role 字段，显示「master」，说明已成功提主。
   

5. 配置剩余从节点同步新主节点
   
   注：如果新的主节点有密码，还需要执行下面这个命令，让当前从节点连接主节点时，自动用这个密码进行认证，解决同步时的权限问题。

   CONFIG SET masterauth 新主节点的密码（比如123456）

查看新主节点的密码配置（requirepass 就是节点登录 / 自身密码）
CONFIG GET requirepass

1. 恢复旧主节点，并配置为新主的从节点（避免脑裂）
   启动并连接旧主节点
   
   配置为新主的从节点
   
   
2. 验证手动容灾成功
   新主节点执行写操作
   
   两个从节点执行读操作
   
   

8.2 选举机制

8.2.1 概述

1. 选举触发条件
   主节点被哨兵集群标记为「客观下线」（超过半数哨兵确认主节点故障），立即触发选举。
2. 选举核心原则
   ① 剔除不合格节点：过滤已下线、同步延迟过高、slave-priority=0（redis.conf中设置，0为特殊情况，永不参与选举）的从节点；
   ② 优先级优先：选择 slave-priority 值最小的节点（默认 100，值越小优先级越高）。slave-priority取值范围为1 ~ 65535。
   ③ 同步进度优先：优先级相同时，选择 master_repl_offset 最大的节点（与旧主数据同步最完整，数据丢失最少）；
   ④ 运行 ID 优先：前两者相同时，选择 runid 字典序最小的节点，保证选举结果唯一，避免投票死锁。
3. 选举结果
   最终选出 1 个最优从节点，作为新主节点，哨兵自动完成「提主 + 重配置」，全程无需人工干预。
4. 与手动容灾的区别
   手动容灾是「人工选主」，选举机制是「哨兵自动选主」，规则固定，更高效、更可靠。

8.3 哨兵机制

8.3.1 概述

1. 核心定义
   Redis Sentinel（哨兵）是官方提供的「Redis 高可用解决方案」，本质是一个「分布式监控投票集群」，独立于主从节点，专门解决主从复制的手动容灾缺陷。
2. 核心功能
   ① 故障检测（监控）：哨兵定期向主从节点发送 PING 命令（心跳检测），单个哨兵发现节点超时无响应，标记为「主观下线」；
   ② 故障确认（客观下线）：标记主观下线后，该哨兵向其他哨兵发起投票，超过半数哨兵确认故障，标记为「客观下线」（避免单哨兵误判）；
   ③ 自动故障转移（核心）：主节点客观下线后，按「选举机制」选出新主，自动执行「提主 + 重配置 + 旧主恢复后从节点化」，全程无人工干预；
   ④ 故障通知：故障发生 / 转移完成后，通过配置脚本（邮件、钉钉）通知运维人员，告知故障节点、新主节点信息。
3. 核心架构设计
   ① 奇数节点部署：哨兵集群必须部署 3 个 / 5 个奇数节点（生产最少 3 个），配合「半数选举原则」，避免投票死锁；
   ② 去中心化：所有哨兵节点地位平等，无主从之分，投票决策基于「少数服从多数」，避免哨兵自身单点故障；
   ③ 与主从解耦：哨兵不存储任何业务数据，仅做「监控 + 控制」，对主从节点性能影响极小。
4. 核心配置（sentinel.conf）
   sentinel monitor：监控主节点（别名、IP、端口、投票数）；
   sentinel auth-pass：主节点密码（与主从节点一致）；
   sentinel down-after-milliseconds：故障超时时间（默认 30s）。
5. 结论
   哨兵机制 + 主从复制，是 Redis 生产环境中「高可用的标准方案」，解决了主从复制的「无自动容灾、恢复效率低、易脑裂」等缺陷。

8.3.2 示例

1. 前提
   检查主从节点配置文件，确保主从节点配置都正常。

2. 准备哨兵
   新建文件夹
   
   进入redis安装目录把redis-sentinel复制到bin目录下
   cp /usr/local/redis/bin/redis-sentinel /usr/local/redis-sentinel/bin/redis-sentinel
   进入redis源码目录，复制三分sentinel.conf文件到conf目录下。（因为哨兵不保存数据，所以没有必要每一个哨兵一个文件夹）

   #复制并命名3份
   cp sentinel.conf /usr/local/redis-sentinel/conf/sentinel-26379.conf
   cp sentinel.conf /usr/local/redis-sentinel/conf/sentinel-26378.conf
   cp sentinel.conf /usr/local/redis-sentinel/conf/sentinel-26377.conf

3.修改哨兵配置文件

#1. 修改哨兵端口（3个哨兵分别设26379、26378、26377）
port 26379
#2. 监控主节点（当前主节点是6379，别名mymaster，投票数2，3个哨兵需半数以上）
sentinel monitor mymaster 127.0.0.1 6379 2
#3. 主节点密码（与主从节点密码一致）
sentinel auth-pass mymaster 你的Redis密码
#4. 故障超时时间（默认30000ms=30s，超时标记为主观下线）
sentinel down-after-milliseconds mymaster 30000
#5. 强制哨兵绑定 127.0.0.1（仅监听本机通信，避免获取内网IP）
bind 127.0.0.1
#6.后台启动
daemonize yes
#7.日志位置
logfile "/usr/local/redis-sentinel/log/sentinel-26379.log"
#8.强制哨兵向其他哨兵节点上报的地址为 127.0.0.1
sentinel announce-ip 127.0.0.1

4.修改节点配置

修改6377节点的replica-priority，把100改为77。

为所有节点添加下面配置

#1. （关键）向哨兵/其他从节点上报的IP，强制指定为 127.0.0.1（解决哨兵IP混乱）
replica-announce-ip 127.0.0.1

5.启动节点

依次启动主节点，从节点。

6.启动哨兵

进入redis-sentinel，启动哨兵

./bin/redis-sentinel ./conf/sentinel-26379.conf
./bin/redis-sentinel ./conf/sentinel-26378.conf
./bin/redis-sentinel ./conf/sentinel-26377.conf

1. 查看哨兵日志
   

• 哨兵启动监控：26379 启动加载配置，监控主节点127.0.0.1:6379（+monitor master mymaster 127.0.0.1 6379 quorum 2）
• 标记主观下线：检测到 6378 从节点、26377/26378 哨兵异常，依次标记sdown
• 主节点客观下线：原主 6379 被标记sdown，集群 2 票共识升级为odown（+odown master mymaster 127.0.0.1 6379 #quorum 2/2）
• 选举领头哨兵：进入新纪元（+new-epoch 162），投票选出领头哨兵执行故障转移（+vote-for-leader）
• 切换新主节点：高优先级 6377 成为新主，执行+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6377
• 重建主从链路：原主 6379、从节点 6378 自动转为 6377 的从节点（+slave slave）
• 清理残留异常：公网 IP 的 6378 节点再次被标记sdown，不影响新集群运行
  注：6379旧主节点并没有手动故障（手动停止运行），但却被哨兵判定为故障，可能是因为6379 的连接 / 状态不稳定。进过投票后，选择优先级更高的 6377 作为新主节点。
  

1. 停止命令

停止所有 Redis 节点（主从都停）

ps -ef | grep redis-server | grep -v grep | awk '{print $2}' | xargs kill

停止所有哨兵节点

ps -ef | grep redis-sentinel | grep -v grep | awk '{print $2}' | xargs kill

8.3.3 Redis 哨兵法定票数（quorum）

核心配置与基础概念

1. sentinel monitor mymaster 127.0.0.1 6379 2 中最后一位2是手动配置的法定票数 quorum，无默认值，是哨兵监控主节点的必选参数，缺失则哨兵无法启动。
2. quorum 是哨兵集群的核心共识阈值，一参管三件事：主节点客观下线判定、哨兵主节点选举、故障转移执行，三者共用同一阈值。
3. 哨兵内部会基于 Raft 算法简化版进行主哨兵选举，仅当选的主哨兵执行故障转移，避免多哨兵同时操作引发混乱。

3 哨兵 + 1 主 2 从场景：quorum=1 vs quorum=2

1. quorum=1（可运行但不规范，仅测试用）

• 功能：能正常完成主节点故障判定、哨兵选举和故障转移，剩余 1 个哨兵也能独立执行所有操作，容错性看似更高。
• 核心问题：牺牲分布式一致性换过度容错，丢失集群全局共识：
  • 状态判断：单个哨兵检测到主节点失联，直接判定客观下线，无其他哨兵核对，易误判（如单哨兵网络闪断）。
  • 操作执行：单个哨兵给自己投票即可成为主哨兵，可能出现多哨兵同时发起故障转移，导致集群多主节点。
• 致命风险：极易引发主从脑裂（原主正常、新主被提升，双主同时提供服务），造成数据不一致。

1. quorum=2（3 哨兵集群唯一规范配置，生产必用）

• 功能：满足过半数共识（3/2+1=2），剩余 2 个哨兵即可正常完成所有高可用操作，容错 1 个哨兵故障。
• 核心优势：兼顾一致性与可控容错，实现集群全局共识：
  • 状态判断：至少 2 个哨兵检测到主节点失联，才判定客观下线，杜绝单哨兵 / 单网络故障的误判。
  • 操作执行：哨兵需获得至少 2 票才能当选主哨兵，确保唯一节点执行故障转移，避免多主问题。
  • 高可用保障：在一致性前提下容错 1 个哨兵故障，符合 Redis 分布式高可用设计核心。

一致性的核心定义

Redis 哨兵中的一致性，指集群对「主节点状态」和「故障转移操作」的全局统一共识，核心防 2 个分布式问题：

• 防网络分区（脑裂）：避免单哨兵与主节点的局部网络问题，被判定为主节点全局故障。
• 防操作混乱：保证故障转移操作的原子性，避免多哨兵同时执行切换，导致集群多主节点。

核心配置原则

quorum 值必须遵循哨兵总数过半数原则：

quorum = 哨兵总数 / 2 + 1（向下取整）

这是 Redis 官方推荐，也是分布式系统实现共识一致性的通用方案：

• 3 哨兵→quorum=2（容错 1 个）
• 5 哨兵→quorum=3（容错 2 个）
• 7 哨兵→quorum=4（容错 3 个）
  核心结论：高可用≠无限容错，而是一致性前提下的可控容错，生产环境 3 哨兵集群必须配置 quorum=2。

注

1. 哨兵内部会自动进行主哨兵选举，为避免多哨兵同时操作，仅主哨兵执行故障转移；
2. 3 哨兵故障 1 个剩余 2 个，能正常选举和故障转移（满足 quorum=2 的票数要求）；
3. quorum=1 可正常运行，但丢失分布式一致性，易脑裂，仅测试用；quorum=2 是规范配置，生产必用。