3. 主从复制原理：Redis主从复制流程、全量复制与部分复制、复制偏移量
Redis 主从复制是哨兵模式高可用的数据基石。主节点（Master）将数据变更实时同步到从节点（Slave），实现数据冗余、读写分离和故障恢复的基础能力。理解复制流程、全量与部分复制的触发条件以及复制偏移量的作用，是掌握哨兵模式的前提。
3.1 主从复制核心流程
Redis 主从复制采用异步复制模式，整体流程分为三个阶段：连接建立、数据同步、命令传播。以下流程图展示了从节点发起连接请求到最终保持实时同步的完整链路。
关键点：主从复制是异步的，主节点不等待从节点确认即返回客户端。这意味着主节点故障时，未同步到从节点的数据可能丢失，哨兵模式通过选举机制尽量选择数据最新的从节点来减少损失。
3.2 全量复制与部分复制
Redis 根据从节点的状态和复制积压缓冲区（Replication Backlog）的内容，决定采用全量复制还是部分复制。两种方式的触发条件和执行过程差异显著。
| 对比维度 | 全量复制 | 部分复制 |
|---|---|---|
| 触发条件 | 从节点首次连接；主从复制断开时间过长，偏移量不在积压缓冲区范围内 | 从节点断线重连后，偏移量仍在主节点积压缓冲区范围内 |
| 数据量 | 主节点完整 RDB 快照 + 后续增量命令 | 仅缺失的增量命令（积压缓冲区内的数据） |
| 资源消耗 | 高：CPU（生成 RDB）、网络（传输 RDB）、磁盘 I/O（写入 RDB） | 低：仅传输少量命令，几乎无额外开销 |
| 执行时间 | 秒级到分钟级（取决于数据量） | 毫秒级 |
| 对主节点影响 | fork 子进程生成 RDB 可能造成短暂阻塞；传输 RDB 占用带宽 | 几乎无影响 |
3.2.1 全量复制详细流程
全量复制是 Redis 主从复制的基线流程，当从节点无法通过部分复制恢复同步时触发。具体步骤如下：
- 从节点发起连接：从节点向主节点发送
PSYNC ? -1命令（表示未知偏移量，请求全量同步）。 - 主节点生成 RDB：主节点 fork 子进程执行
BGSAVE生成 RDB 快照文件。在此期间，主节点继续处理写命令，并将新写入的命令缓存到复制积压缓冲区。 - 传输 RDB：主节点将 RDB 文件发送给从节点。从节点清空自身数据，加载 RDB 文件。
- 发送积压缓冲区数据：RDB 传输完成后，主节点将生成 RDB 期间缓存的写命令发送给从节点。
- 进入命令传播：从节点加载完 RDB 并执行完积压命令后，与主节点保持实时命令同步。
注意：全量复制期间，如果数据量较大（例如几十 GB），RDB 传输会占用大量网络带宽，可能导致主节点响应变慢。建议在业务低峰期进行全量复制，或通过
repl-diskless-sync 配置启用无盘复制以减轻磁盘 I/O 压力。
3.2.2 部分复制详细流程
部分复制是 Redis 4.0 引入的优化机制，大幅减少了断线重连后的同步开销。其核心依赖复制积压缓冲区（Replication Backlog）和复制偏移量。
- 从节点重连：从节点重新连接主节点，发送
PSYNC <runid> <offset>命令，携带之前同步的复制偏移量。 - 主节点校验：主节点检查从节点提供的偏移量是否仍在自己的复制积压缓冲区范围内。
- 执行部分复制：如果偏移量有效，主节点将缓冲区中从该偏移量之后的所有命令发送给从节点。
- 恢复同步：从节点执行接收到的增量命令，与主节点数据保持一致，继续命令传播。
最佳实践：合理设置
repl-backlog-size（默认 1MB）。如果从节点频繁断线重连且偏移量超出缓冲区范围，会退化为全量复制。建议根据网络稳定性和写流量估算，将 backlog 大小设置为 峰值写速率 × 最大容忍断线时间 的 1.5~2 倍。
3.3 复制偏移量（Replication Offset）
复制偏移量是 Redis 主从复制中用于精确追踪同步进度的核心指标。主节点和每个从节点各自维护一个单调递增的偏移量，表示已处理的字节数。
3.3.1 偏移量的作用
- 同步进度追踪：主节点每向从节点发送 N 字节数据，主从双方的偏移量同步增加 N。通过对比主从偏移量，可以判断数据同步的滞后程度。
- 部分复制判断依据：从节点重连时，将自身偏移量发送给主节点。主节点检查该偏移量是否在复制积压缓冲区中，决定采用全量复制还是部分复制。
- 监控与告警：通过
INFO replication命令查看master_repl_offset和slave_repl_offset，计算偏移量差值作为复制延迟指标。
3.3.2 偏移量相关配置与命令
| 配置/命令 | 说明 | 示例 |
|---|---|---|
repl-backlog-size |
复制积压缓冲区大小，决定部分复制能容忍的最大断线时间 | repl-backlog-size 100mb |
repl-backlog-ttl |
主节点没有从节点连接时，积压缓冲区保留的时间（秒） | repl-backlog-ttl 3600 |
INFO replication |
查看主从复制状态、偏移量、连接信息 | redis-cli INFO replication |
PSYNC |
从节点发起同步请求，携带 runid 和偏移量 | PSYNC 3c4a... 123456 |
3.3.3 偏移量监控示例
通过 INFO replication 输出可以直观看到主从偏移量状态：
# 主节点输出示例
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.101,port=6379,state=online,offset=1024000,lag=0
slave1:ip=192.168.1.102,port=6379,state=online,offset=1024000,lag=0
master_repl_offset:1024000
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1024000
# 从节点输出示例
# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up
slave_repl_offset:1024000
slave_read_repl_offset:1024000
监控建议：当
master_repl_offset - slave_repl_offset 持续增长且超过阈值（例如 10MB），说明从节点同步延迟严重。可能原因包括：网络带宽不足、从节点性能瓶颈、主节点写流量突增。哨兵模式下，过大的复制延迟会影响故障切换时的数据完整性。
3.4 主从复制与哨兵模式的关系
主从复制为哨兵模式提供了两个关键能力：
- 数据冗余：主节点故障时，哨兵可以从多个从节点中选举一个数据最新的节点晋升为新主节点，保证数据不丢失或仅丢失少量数据。
- 复制偏移量作为选举依据：哨兵在选举新主节点时，会优先选择复制偏移量最大的从节点（即数据最接近原主节点的节点），减少数据丢失风险。
理解主从复制的全量/部分复制机制和偏移量原理，是后续学习哨兵故障检测、选举算法和自动故障转移的基础。