【Redis】Redis高可用：主从复制与哨兵机制详解 - 实践
【Redis】Redis高可用：主从复制与哨兵机制详解
一、主从复制：解决“单点故障”与“读写分离”
如果只部署一台Redis（单机版），一旦机器宕机，整个依赖Redis的业务都会受影响；而且所有读写请求都压在一台机器上，也容易触发性能瓶颈。主从复制的思路很简单：部署多台Redis，分为“主节点（Master）”和“从节点（Slave）”，通过数据同步实现高可用。
1. 主从复制的核心逻辑
- 角色分工：
- 主节点（Master）：只能写，负责接收所有写请求（比如set、incr），并把资料同步给从节点；
- 从节点（Slave）：只能读，负责接收主节点同步的数据，所有读请求（比如get、hget）都走从节点。
- 核心价值：
- 读写分离：主节点扛写，从节点扛读，减轻单节点压力；
- 数据备份：从节点是主节点的“备份”，主节点宕机后，从节点能作为“备用节点”顶上；
- 高可用基础：主从复制是哨兵机制的前提，没有主从，哨兵无法实现故障自动转移。
2. 材料同步的两种方式：全量复制 vs 增量复制
（1）全量复制：从节点“第一次”同步数据
当从节点刚启动、或断开连接后重新连主节点（断开时间较长，数据差异大）时，会触发全量复制，流程如下：
- 从节点向主节点发送“同步请求”；
- 主节点执行
bgsave命令，生成RDB文件（Redis的快照文件，压缩的二进制格式）； - 主节点把RDB文件发送给从节点；
- 从节点收到RDB后，先清空自己的旧素材，再加载RDB资料到内存，完成“全量数据同步”；
- 注意：主节点生成RDB的过程中，可能会收到新的写请求——这些请求会被暂存到“缓冲区”，等RDB发送完，主节点再把缓冲区的请求同步给从节点，确保数据不丢失。
（2）增量复制：主从正常连接后的“实时同步”
全量复制完成后，主节点和从节点会建立一条TCP长连接，后续主节点收到的所有写请求，都会通过这条长连接“异步”发送给所有从节点，这就是增量复制。
- 特点：不用每次都传全量数据，只传“新增的写命令”，效率极高；
- 注意：异步同步意味着“主从内容可能有极短的延迟”（比如毫秒级），但对绝大多数业务来说，这个延迟完全可接受。
3. 为什么全量复制用RDB，不用AOF？
很多人会疑惑：Redis的持久化有RDB和AOF两种，为什么全量复制选RDB？核心原因是“效率更高”：
- 体积更小：RDB是压缩的二进制文件，同样的数据，RDB体积比AOF小得多，传输速度更快；
- 加载更快：从节点收到RDB后，直接解析二进制资料加载到内存即可；而AOF是“一条条写命令”，从节点需要逐个执行命令才能恢复材料，速度远慢于RDB。
AOF的优势是“数据完整性更高”（默认每秒刷盘），但全量复制追求的是“快速同步”，所以RDB更合适。
4. 主从复制的痛点：主节点宕机后需“手动切换”
主从复制解决了“读写分离”和“数据备份”，但有个致命问题：一旦主节点宕机，所有写请求都会失败，此时需要人工从多个从节点中选一个“升级为主节点”，再修改其他从节点的同步目标（指向新主节点），最终通知业务端切换写请求地址——整个过程耗时且容易出错，无法满足“高可用”的实时性要求。
这时候，就需要“哨兵机制”来解除“自动故障转移”的问题。
二、哨兵机制：实现“故障自动检测与转移”
哨兵（Sentinel）是Redis官方提供的“高可用组件”，本质是一个独立运行的进程，它的核心作用是：监控主从节点状态，主节点宕机后自动完成“选主→切主→通知”的全流程，无需人工干预。
1. 哨兵的核心功能
哨兵集群（注意：哨兵不能只部署1个，至少3个）主要做三件事：
- 监控（Monitoring）：实时检测主节点、从节点是否存活；
- 通知（Notification）：主节点宕机后，通过API或设置通知业务端、运维人员；
- 自动故障转移（Automatic Failover）：主节点确认宕机后，自动选一个从节点升级为主节点，并调整其他节点的角色，完成全量切换。
2. 如何判断主节点“真的宕机”？
哨兵判断主节点宕机，不是“一个哨兵说了算”，而是分两步走，避免“误判”（比如网络波动导致哨兵没收到主节点响应）。
（1）主观下线（Subjective Down，SDOWN）：
每个哨兵会定期（默认1秒）向主节点、从节点发送PING命令，如果主节点在“指定时间内”（默认30秒，可配置）没返回PONG响应，这个哨兵就会把主节点标记为“主观下线”——意思是“我认为主节点宕机了，但不确定别人怎么看”。
为什么叫“主观”：哨兵没收到响应，可能是主节点真宕机，也可能是哨兵自己网络故障、或主节点临时网络卡顿，不能仅凭一个哨兵的判断下结论。
（2）客观下线（Objective Down，ODOWN）：
为了避免误判，哨兵会遵循“少数服从多数”的原则：当一个哨兵判断主节点“主观下线”后，会向集群中其他所有哨兵发送“询问请求”，问“你认为主节点是不是宕机了？”。
如果超过半数的哨兵（比如3个哨兵中至少2个）都反馈“我也认为主节点主观下线”，那么主节点就会被标记为“客观下线”——此时所有哨兵一致认为“主节点真的宕机了”，可以启动故障转移流程。
关键前提：哨兵集群至少部署3个节点，才能满足“半数以上”的投票条件（1个哨兵无法投票，2个哨兵容易出现“1:1”平局）；生产环境建议部署3~5个哨兵，兼顾可靠性和资源成本。
3. 故障转移的核心步骤：选哨兵leader→选新主节点→全量切换
主节点被标记为“客观下线”后，哨兵集群会启动故障转移，整个流程分三步：
（1）第一步：选“哨兵leader”——谁来负责执行故障转移？
：就是故障转移需要一个“负责人”（哨兵leader），不能所有哨兵同时管理。哨兵leader的选举逻辑，借鉴了Raft分布式一致性算法的核心思想，简化理解就
- 每个认为主节点“客观下线”的哨兵，都可能竞选“leader”；
- 哨兵之间通过投票，选出得票最多的那个作为leader；
- 一旦选出leader，后续所有故障转移运行（选新主、切主、通知）都由这个leader执行。
（2）第二步：选“新主节点”——从多个从节点中挑最优的
哨兵leader会从所有“存活的从节点”中，按以下优先级选出一个“最优从节点”升级为主节点：
- 优先级最高：从节点的
slave-priority配置（默认100，值越小优先级越高），优先级高的先选； - 复制数据最全：优先级相同的情况下，选“与主节点数据同步最完整”的（即复制偏移量最大的），避免数据丢失；
- 运行最久：前两个条件都相同，选“启动时间最早”的从节点，保证稳定性。
（3）第三步：全量切换——达成主从角色调整与通知
选出新主节点后，哨兵leader会执行以下执行，完成全量切换：
- 向“新主节点”发送命令，让它从“从节点”升级为“主节点”；
- 向其他所有“从节点”发送命令，让它们把“同步目标”改成新主节点，从此向新主节点同步数据；
- 向业务客户端发送“新主节点地址”（比如通过Redis的发布订阅机制），让客户端后续的写请求指向新主节点；
- 持续监控“旧主节点”：如果旧主节点后续重新上线，哨兵会自动把它设置为“从节点”，让它向新主节点同步数据，避免旧主节点成为“孤节点”。
4. 哨兵机制的关键优势
- 全自动：从“检测主节点宕机”到“完成切换”，全程无需人工干预，秒级完成，几乎不影响业务；
- 高可靠：通过“多哨兵投票”避免误判，通过“选最优从节点”保证数据完整性；
- 低侵入：哨兵是独立进程，不用修改Redis主从节点的安装，也不用业务端做过多适配（只需承受“动态获取主节点地址”）。
)
一、主从复制：解决“单点故障”与“读写分离”
假设只部署一台Redis（单机版），一旦机器宕机，整个依赖Redis的业务都会受影响；而且所有读写请求都压在一台机器上，也容易触发性能瓶颈。主从复制的思路很容易：部署多台Redis，分为“主节点（Master）”和“从节点（Slave）”，通过数据同步实现高可用。
1. 主从复制的核心逻辑
- 角色分工：
- 主节点（Master）：只能写，负责接收所有写请求（比如set、incr），并把信息同步给从节点；
- 从节点（Slave）：只能读，负责接收主节点同步的数据，所有读请求（比如get、hget）都走从节点。
- 核心价值：
- 读写分离：主节点扛写，从节点扛读，减轻单节点压力；
- 数据备份：从节点是主节点的“备份”，主节点宕机后，从节点能作为“备用节点”顶上；
- 高可用基础：主从复制是哨兵机制的前提，没有主从，哨兵无法建立故障自动转移。
2. 数据同步的两种方式：全量复制 vs 增量复制
（1）全量复制：从节点“第一次”同步素材
当从节点刚启动、或断开连接后重新连主节点（断开时间较长，信息差异大）时，会触发全量复制，流程如下：
- 从节点向主节点发送“同步请求”；
- 主节点执行
bgsave命令，生成RDB文件（Redis的快照文件，压缩的二进制格式）； - 主节点把RDB文件发送给从节点；
- 从节点收到RDB后，先清空自己的旧数据，再加载RDB文件到内存，搞定“全量数据同步”；
- 注意：主节点生成RDB的过程中，可能会收到新的写请求——这些请求会被暂存到“缓冲区”，等RDB发送完，主节点再把缓冲区的请求同步给从节点，确保数据不丢失。
（2）增量复制：主从正常连接后的“实时同步”
全量复制达成后，主节点和从节点会建立一条TCP长连接，后续主节点收到的所有写请求，都会通过这条长连接“异步”发送给所有从节点，这就是增量复制。
- 特点：不用每次都传全量素材，只传“新增的写命令”，效率极高；
- 注意：异步同步意味着“主从资料可能有极短的延迟”（比如毫秒级），但对绝大多数业务来说，这个延迟完全可接受。
3. 为什么全量复制用RDB，不用AOF？
很多人会疑惑：Redis的持久化有RDB和AOF两种，为什么全量复制选RDB？核心原因是“效率更高”：
- 体积更小：RDB是压缩的二进制文件，同样的资料，RDB体积比AOF小得多，传输速度更快；
- 加载更快“一条条写命令”，从节点要求逐个执行命令才能恢复数据，速度远慢于RDB。就是：从节点收到RDB后，直接解析二进制数据加载到内存即可；而AOF
AOF的优势是“数据完整性更高”（默认每秒刷盘），但全量复制追求的是“快速同步”，所以RDB更合适。
4. 主从复制的痛点：主节点宕机后需“手动切换”
主从复制解决了“读写分离”和“数据备份”，但有个致命问题：一旦主节点宕机，所有写请求都会失败，此时要求人工从多个从节点中选一个“升级为主节点”，再修改其他从节点的同步目标（指向新主节点），最后通知业务端切换写请求地址——整个过程耗时且容易出错，无法满足“高可用”的实时性要求。
这时候，就需要“哨兵机制”来解决“自动故障转移”的问题。
二、哨兵机制：实现“故障自动检测与转移”
哨兵（Sentinel）是Redis官方提供的“高可用组件”，本质是一个独立运行的进程，它的核心作用是：监控主从节点状态，主节点宕机后自动达成“选主→切主→通知”的全流程，无需人工干预。
1. 哨兵的核心功能
哨兵集群（注意：哨兵不能只部署1个，至少3个）主要做三件事：
- 监控（Monitoring）：实时检测主节点、从节点是否存活；
- 通知（Notification）：主节点宕机后，利用API或配置通知业务端、运维人员；
- 自动故障转移（Automatic Failover）：主节点确认宕机后，自动选一个从节点升级为主节点，并调整其他节点的角色，完成全量切换。
2. 如何判断主节点“真的宕机”？
哨兵判断主节点宕机，不是“一个哨兵说了算”，而是分两步走，避免“误判”（比如网络波动导致哨兵没收到主节点响应）。
（1）主观下线（Subjective Down，SDOWN）：
每个哨兵会定期（默认1秒）向主节点、从节点发送PING命令，如果主节点在“指定时间内”（默认30秒，可配置）没返回PONG响应，这个哨兵就会把主节点标记为“主观下线”——意思是“我认为主节点宕机了，但不确定别人怎么看”。
为什么叫“主观”哨兵自己网络故障、或主节点临时网络卡顿，不能仅凭一个哨兵的判断下结论。就是：哨兵没收到响应，可能是主节点真宕机，也可能
（2）客观下线（Objective Down，ODOWN）：
为了避免误判，哨兵会遵循“少数服从多数”的原则：当一个哨兵判断主节点“主观下线”后，会向集群中其他所有哨兵发送“询问请求”，问“你认为主节点是不是宕机了？”。
如果超过半数的哨兵（比如3个哨兵中至少2个）都反馈“我也认为主节点主观下线”，那么主节点就会被标记为“客观下线”——此时所有哨兵一致认为“主节点真的宕机了”，可以启动故障转移流程。
关键前提：哨兵集群至少部署3个节点，才能满足“半数以上”的投票条件（1个哨兵无法投票，2个哨兵容易出现“1:1”平局）；生产环境建议部署3~5个哨兵，兼顾可靠性和资源成本。
3. 故障转移的核心步骤
主节点被标记为“客观下线”后，哨兵集群会启动故障转移，整个流程分三步：
（1）第一步：选“哨兵leader”——谁来负责执行故障转移？
故障转移需要一个“负责人”（哨兵leader），不能所有哨兵同时操作。哨兵leader的选举逻辑，借鉴了Raft分布式一致性算法的核心思想，简化理解就是：
- 每个认为主节点“客观下线”的哨兵，都可以竞选“leader”；
- 哨兵之间通过投票，选出得票最多的那个作为leader；
- 一旦选出leader，后续所有故障转移操作（选新主、切主、通知）都由这个leader执行。
（2）第二步：选“新主节点”——从多个从节点中挑最优的
哨兵leader会从所有“存活的从节点”中，按以下优先级选出一个“最优从节点”升级为主节点：
- 优先级最高：从节点的
slave-priority配置（默认100，值越小优先级越高），优先级高的先选； - 复制数据最全：优先级相同的情况下，选“与主节点数据同步最完整”的（即复制偏移量最大的），避免信息丢失；
- 运行最久：前两个条件都相同，选“启动时间最早”的从节点，保证稳定性。
（3）第三步：全量切换——完成主从角色调整与通知
选出新主节点后，哨兵leader会执行以下管理，结束全量切换：
- 向“新主节点”发送命令，让它从“从节点”升级为“主节点”；
- 向其他所有“从节点”发送命令，让它们把“同步目标”改成新主节点，从此向新主节点同步数据；
- 向业务客户端发送“新主节点地址”（比如通过Redis的发布订阅机制），让客户端后续的写请求指向新主节点；
- 持续监控“旧主节点”：如果旧主节点后续重新上线，哨兵会自动把它设置为“从节点”，让它向新主节点同步数据，避免旧主节点成为“孤节点”。
4. 哨兵机制的关键优势
- 全自动：从“检测主节点宕机”到“完成切换”，全程无需人工干预，秒级完成，几乎不影响业务；
- 高可靠：通过“多哨兵投票”避免误判，通过“选最优从节点”保证数据完整性；
- 低侵入：哨兵是独立进程，不用修改Redis主从节点的配置，也不用业务端做过多适配（只需支持“动态获取主节点地址”）。
浙公网安备 33010602011771号