Redis的主从结构与哨兵机制详解

redis 主从结构

前面的博客介绍了 redis的持久化方式，，redis 的持久化机制能够保障服务重启后数据不丢失，redis 重启时会自动加载硬盘上的持久化文件，将数据恢复到内存中。但持久化只能规避服务重启的数据丢失问题，无法应对服务器硬盘损坏、机器宕机等硬件故障，单节点 redis 存在严重单点故障风险，一旦节点故障会直接造成数据丢失、服务不可用。
同时，redis 本身具备高性能高并发的特性，单台 redis 服务器可以承载大量并发请求。但在电商、社交等超高并发业务场景下，海量的读写请求会集中施压单节点，即便 redis 读写性能优异，也会出现请求阻塞、服务器 cpu 和内存负载过高、性能瓶颈凸显的问题。

为了解决单点数据故障和单节点读写压力过大两大问题，redis 提供了主从复制（主从架构） 机制。主从架构采用一主多从的部署模式：主节点（master） 同时支持读、写操作，负责处理业务新增、修改、删除等写请求；从节点（slave） 仅提供只读服务，不参与写业务。所有从节点会自动异步同步主节点的数据，保持与主节点数据最终一致性。
借助主从结构，一方面实现了读写分离，海量读请求分流到从节点，极大分担主节点压力，提升整体并发承载能力；另一方面从节点作为主节点的数据副本，实现了数据异地备份，主节点硬件故障或宕机时，可快速依托从节点恢复服务，彻底解决单节点的单点故障问题。
需要注意的是主从复制过程默认非阻塞，主节点在进行数据同步时，仍可正常处理客户端请求，不影响业务可用性。

如下图：

主从复制的原理
redis 主从复制分为建立连接、全量同步、增量同步三个核心阶段，整体采用异步复制机制：
5. 从节点启动后，主动与主节点建立网络通信连接，成功握手后，向主节点发起数据同步请求。
6. 主节点接收到从节点的同步请求后，触发bgsave后台持久化，生成 rdb 快照文件；同时将生成 rdb 期间新产生的写命令暂存到缓冲区。随后主节点把完整的 rdb 文件传输给从节点。
7. 从节点接收 rdb 文件后，清空自身原有数据，加载 rdb 文件完成全量数据同步，复刻主节点当前全量数据。
8. 全量同步完成后进入增量同步阶段：主节点每执行一次写操作（增、删、改），都会将对应的命令异步复制发送给所有从节点；从节点持续执行同步过来的命令，始终保持与主节点数据一致。

补充：redis 2.8 及以上版本采用psync替代旧版sync，支持部分重同步，网络短暂断开重连后无需重新全量同步，仅同步断开期间缺失的数据，效率更高。

主从复制的核心作用

1. 数据冗余备份
   主从复制实现了跨节点热数据备份，属于持久化之外的另一种数据冗余方案。持久化仅做本地磁盘数据保存，无法应对服务器硬盘损坏、整机宕机；而主从节点分布在不同服务器，可有效规避单节点硬件故障导致的数据丢失。
2. 故障快速
   恢复当主节点发生宕机、硬件故障等异常时，从节点具备完整数据，可临时接管对外提供服务，快速恢复业务访问，实现服务级别的容灾恢复，降低业务停机时长。
3. 读写分离，负载均衡
   基于主从架构天然支持读写分离：主节点负责处理所有写请求，从节点专门承载读请求。在互联网多读少写的业务场景下，可部署多个从节点分摊读压力，有效降低单节点负载，大幅提升系统整体并发访问能力。
4. 高可用架构的基石
   主从复制是 redis哨兵机制和redis 集群的底层基础。哨兵实现自动故障转移、集群实现数据分片与横向扩容，都依赖主从复制的数据同步能力，无主从复制则无法搭建高可用、分布式架构。

主从配置

主节点默认无需特殊配置，从节点修改配置文件，如下：

指定主节点地址和端口，redis5.0+用replicaof，5.0前用slaveof

启动各节点
需要注意的是先启动主节点生效再启动从节点生效

演示：主节点写，从节点同步主节点数据

演示：从节点只能读不能写

redis 哨兵机制

redis 哨兵是 redis 官方提供的高可用监控与自动故障转移组件，专门解决主从架构中主节点故障后需手动切换的问题。它本质是一个独立的 redis 进程（非主从节点），通常以集群形式部署，实现主节点故障的自动化恢复。

哨兵的核心工作原理

• 阶段 1：故障监测
  所有哨兵节点会持续向 redis 主从节点发送 ping 心跳检测。若某个主节点在配置时间内未正常响应，当前哨兵会先将其标记为主观下线（sdown），即单个哨兵的局部判断，用于避免网络抖动造成的误判。
• 阶段 2：集群共识
  当前哨兵发现主节点主观下线后，会向其他哨兵节点发送 “是否认为该主节点故障” 的询问请求。当判定故障的哨兵数量达到配置的法定票数（quorum）时，哨兵集群会将该主节点标记为客观下线（odown），这是集群层面的全局共识，标志着主节点真正失效。
• 阶段 3：领导者选举
  主节点客观下线后，哨兵集群会通过选举算法选出一个领导者哨兵，由其统一执行后续故障转移，避免多个哨兵同时操作引发冲突。领导者会按照节点优先级、数据同步进度、运行 id 的策略，在健康的从节点中选出数据最完整、最合适的节点作为新主节点。
• 阶段 5：故障转移
  领导者哨兵将选中的从节点升级为新主节点，并让其他从节点重新复制新主节点的数据，同时更新整个集群的拓扑信息。若旧主节点后续重新上线，会被自动配置为新主节点的从节点，保证架构最终一致。

哨兵的部署与配置

创建哨兵节点

mkdir -p /usr/local/src/redis/sentinel-demo/data/{26379,26380,26381}

编写各个哨兵的核心配置文件（sentinel.conf）

vi sentinel_26379.conf
cp sentinel_26379.conf sentinel_26380.conf
cp sentinel_26379.conf sentinel_26381.conf

修改各个配置文件中的数据目录和日志文件位置

daemonize yes
port 26379
bind 0.0.0.0
protected-mode no
dir "/usr/local/src/redis/sentinel-demo/data/26379"
logfile "/usr/local/src/redis/sentinel-demo/data/26379/sentinel.log"
sentinel monitor mymaster 127.0.0.1 6380 2
sentinel down-after-milliseconds mymaster 30000
sentinel deny-scripts-reconfig yes

daemonize yes：哨兵以守护进程方式运行（后台运行）；
port 26379：哨兵进程监听的端口；
bind 0.0.0.0：哨兵绑定所有网卡的 ip，允许任意地址访问；
protected-mode no：关闭保护模式，保护模式下哨兵仅允许本地连接，需要注意的是若哨兵部署在不同服务器必须设为no，否则无法跨机器哨兵通信；
dir “/usr/local/src/redis/sentinel-demo/data/26379” 存储哨兵的状态文件，哨兵本身几不持久化数据，主要用于临时文件；
logfile “/usr/local/src/redis/sentinel-demo/data/26379/sentinel.log”：哨兵的日志文件路径；
sentinel monitor mymaster 127.0.0.1 6380 2：哨兵核心监控规则，其中 mymaster 为监控的主节点名称，127.0.0.1 6380 为主节点的 ip 和端口，2 为 quorum（法定票数）；
sentinel deny-scripts-reconfig yes：禁止通过脚本修改哨兵的配置，防止恶意篡改。

启动各个哨兵，需要先启动主哨兵，再启动各个从哨兵

../redis-5.0.4/src/redis-sentinel sentinel_26379.conf

展示哨兵对主节点 mymaster（127.0.0.1:6379）的监控状态

../redis-5.0.4/src/redis-cli -p 26379
127.0.0.1:26379> sentinel masters

演示：主节点关闭后开启降为从节点

到此这篇关于redis的主从结构与哨兵机制详解的文章就介绍到这了,更多相关redis主从结构与哨兵机制内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！