Redis高可用实现方案解析：主从复制与哨兵监控

Redis高可用实现方案解析：主从复制与哨兵监控

引用

CSDN

1.

https://blog.csdn.net/yangshangwei/article/details/145959238

在高并发实时数据访问场景中，Redis作为主流的缓存数据库，其高可用性是系统稳定运行的关键。本文将深入解析Redis的高可用实现方案，包括主从复制和哨兵监控机制，并提供生产环境实践建议，帮助读者构建更可靠的Redis集群。

概述

为了提升对高并发实时数据访问的性能，数据缓存组件应运而生，其中比较常见的就是Memcache和Redis。

Memcache是经典的内存缓存技术，对相关领域的支持比较丰富，各种框架都支持使用该技术。应用系统中经常用到的会话信息可以非常方便地保存到Memcache中，每个键保存的数据量最大为1 MB，支持的数据类型比较单一，仅支持字符串类型（string），不支持持久化操作。

Redis支持比较多的数据类型（string、list、set、sortset、hash），也支持集合计算（set类型），每个键的最大数据量为1 GB，支持持久化操作。Redis一般配合后端数据库使用，其存放的一般是用户当前频繁使用的数据。

Redis 高可用实现方案

Redis 实现高可用主要依靠两大机制：主从复制与哨兵监控。

一、主从复制机制

Redis通过主从复制实现数据冗余与读写分离，支持全量同步和增量同步两种模式。

1.1 全量同步流程

当从服务器首次连接主服务器或数据差异过大时触发全量同步：

全量同步流程：

1. 从服务器发送 SYNC 命令：从服务器请求与主服务器建立复制关系。
2. 主服务器生成 RDB 快照：接收到 SYNC 命令后，主服务器调用 BGSAVE 命令生成 RDB 文件，同时启动缓冲区记录后续所有的增量命令。
3. 传输 RDB 文件：主服务器将 RDB 快照发送给从服务器。
4. 从服务器加载 RDB 文件：从服务器加载快照文件，完成数据初步同步。
5. 增量命令同步：主服务器从缓冲区读取断线期间的命令，发送给从服务器，从服务器执行后续写入操作。

1.2 增量同步（PSYNC）流程

在理解增量同步之前需要了解下面几个概念

• 复制偏移量：执行复制的主从服务器会以字节为单位维护一个复制的偏移量（offset）。
• 复制缓冲区：一个先进先出（first in first out，FIFO）的队列，用于存储服务器执行过的命令，每次执行命令时主服务器都会将命令记录下来，并存储在复制缓冲区。命令存储的仅仅是数据变更的操作，复制缓冲区的大小是1 MB。
• 服务器运行ID：每个Redis服务器会在启动时生成自己的服务器运行ID（runid），主服务器会将自己的运行ID发送给从服务器，从服务器将其保存起来，当主从服务器断线重连之后就可依据这一ID来判断当前主服务器是否是之前的主服务器，如果是，则启动增量同步，否则启动全量同步。

Redis 2.8+版本引入PSYNC命令优化断线重连场景：

核心逻辑：

• 通过 runid 验证主服务器身份
• 通过 offset 判断数据差异是否超出缓冲区容量（默认1MB）
• 增量同步仅传输丢失的命令，避免全量复制

PSYNC命令的执行流程。

• （1）客户端向服务器发送SLAVEOF命令，让当前服务器成为从服务器。
• （2）从服务器根据自己是否保存主服务器的运行ID来判断是否是第一次复制，如果是第一次复制，则继续执行第3步，否则跳转到第4步。
• （3）从服务器向主服务器发送 PSYNC ? -1 命令进行全量同步。
• （4）从服务器向主服务器发送PSYNC runid offset命令进行增量同步。
• （5）主服务器接收到PSYNC 命令后，先判断runid是否与本机ID一致，如果一致，则会再次判断offset和本机的偏移量差距有没有超过复制缓冲区大小，如果没有，就给从服务器发送CONTINUE命令，此时从服务器只需要等待主服务器传回失去连接期间丢失的命令。
• （6）如果runid和本机ID不一致或者双方偏移量差距超过复制缓冲区大小，就会发送FULLRESYNC runid offset命令，从服务器将runid保存起来，并进行全量同步。

二、哨兵监控机制

主从复制虽然实现了数据同步，但主服务器宕机后写操作将无法进行。为解决此问题，Redis 提供了哨兵（Sentinel）机制，主要功能包括：

• 监控（Monitoring）：持续检查主从服务器的运行状态。
• 通知（Notification）：在检测到故障时，通过 API 向管理员或其他应用程序发送通知。
• 自动故障迁移（Automatic Failover）：当主服务器失效时，从剩余从服务器中选举出一个新主服务器，并指示其他从服务器切换复制目标，同时向客户端返回新主服务器的地址。

2.1 故障转移时序流程

核心功能：

1. 监控：多哨兵节点协同检测主服务器状态
2. 选举：基于Raft算法选举领头哨兵
3. 故障转移：

• 提升从服务器为新主节点
• 修改其他从服务器复制目标
• 更新客户端连接地址

三、方案对比与选型建议

推荐组合：主从复制+哨兵模式，兼顾数据冗余与自动容灾。

四、生产环境实践建议

1. 网络优化：主从节点尽量部署在同机房
2. 内存配置：主节点内存建议为最大数据量的1.5倍
3. 监控指标：

• 主从复制延迟（ master_repl_offset ）
• 哨兵节点的 ping 响应时间

4. 避免使用 KEYS * 等阻塞命令影响同步性能

通过合理配置主从复制与哨兵监控，可构建秒级故障恢复的高可用Redis集群。