深度解析 Redis 主从复制

文章目录

- [一、核心概念](#一、核心概念)
- - 基本图解
- [二、主从复制的核心作用](#二、主从复制的核心作用)
- [三、拓扑架构与数据一致性](#三、拓扑架构与数据一致性)
- - [1. 常见拓扑结构](#1. 常见拓扑结构)
  - [2. 最终一致性（最终一致 vs 强一致）](#2. 最终一致性（最终一致 vs 强一致）)
  - [3. 主节点宕机问题](#3. 主节点宕机问题)
- [四、补充：主从复制的底层原理](#四、补充：主从复制的底层原理)
- - [1. 全量复制（Resync）](#1. 全量复制（Resync）)
  - [2. 增量复制（Partial Resync）](#2. 增量复制（Partial Resync）)
- [五、技术扩展：负载均衡算法](#五、技术扩展：负载均衡算法)
- - [LB 实现层分类](#LB 实现层分类)
- [六、主从复制的缺点与痛点](#六、主从复制的缺点与痛点)

一、核心概念

主从复制（Master-Slave Replication），是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。

主节点（Master）：负责执行写操作，并将数据同步到从节点。
从节点（Slave/Follower）：通常只读，接收来自主节点的数据流。
单向性 ：数据的复制是单向的，只能由主节点到从节点。

基本图解

注意：默认情况下，每台独立的 Redis 服务器都是主节点。一个主节点可以拥有多个从节点，但一个从节点只能隶属于一个主节点。

二、主从复制的核心作用

数据冗余：实现了数据的热备份，是持久化之外的另一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复（一种服务的冗余）。
负载均衡（读写分离）：主节点负责写，从节点负责读。在"写少读多"的业务场景下，通过增加从节点可以极大地提高 Redis 的并发吞吐量。
高可用的基石 ：主从复制是 Redis Sentinel（哨兵） 和 Redis Cluster（集群） 能够实施的基础。

三、拓扑架构与数据一致性

1. 常见拓扑结构

除了常见的一主多从结构外，Redis 还支持星形拓扑 和线性链式拓扑（Slave-of-Slave）：

一主多从（星形）：多个从节点直接连接主节点。缺点是如果从节点过多，主节点同步 PING 包和复制流的带宽压力会很大。
链式拓扑：Master -> Slave1 -> Slave2。Slave1 既是 Master 的从节点，又是 Slave2 的主节点。这可以有效减轻 Master 的同步带宽压力。

2. 最终一致性（最终一致 vs 强一致）

Redis 主从同步是异步的。Master 收到写命令并成功响应客户端后，才会异步地将命令传播给 Slave。

有延迟：由于网络传输和命令执行需要时间，主从之间存在短暂的数据不一致。
权衡（CAP 定理） ：Redis 优先保证了 AP（可用性与分区容错性），允许短暂的不一致，从而换取极高的性能。

3. 主节点宕机问题

原生主从模式下 ：如果 Master 宕机，Slave 不会自动提升为 Master。此时系统处于"可读不可写"的状态，需要人工介入（手动执行 REPLICAOF no one）来提升新主节点。
高可用演进（哨兵/集群） ：为了解决人工干预问题，Redis 引入了哨兵（Sentinel）。哨兵通过过半原则（Quorum）自动选举出新的 Master，并让原来的 Master（重启后）变成新 Master 的 Slave 。

四、补充：主从复制的底层原理

主从复制的完整生命周期主要分为三个阶段：连接建立、全量/增量同步、命令传播。

1. 全量复制（Resync）

当一个从节点第一次连接主节点，或者无法进行增量同步时，会触发全量复制：

Slave 向 Master 发送 PSYNC ? -1 命令。
Master 收到后，在后台执行 BGSAVE 生成 RDB 文件，同时用一个复制缓冲区（Replication Buffer）记录从现在开始的所有写命令。
Master 将 RDB 文件发送给 Slave。
Slave 收到 RDB 后，清空自身旧数据，并载入 RDB。
Master 将复制缓冲区内的写命令发给 Slave，Slave 执行这些写命令，达到一致。

在 Redis 中，RDB（Redis DataBase） 是 Redis 的快照（Snapshot）持久化机制，也是 Redis 默认的持久化方式。简单来说，RDB 文件就像是给 Redis 内存中的数据"拍了一张全景照片"，然后把这张照片保存到硬盘上。如果 Redis 宕机或重启，它可以通过读取这个 RDB 文件，把数据直接恢复到内存中。

2. 增量复制（Partial Resync）

如果主从节点因为网络抖动短暂断开，重连后如果触发全量复制，开销会非常大。Redis 2.8+ 引入了增量复制：

复制积压缓冲区（Replica Backlog Rbuf）：Master 内部维护的一个固定长度的循环队列（FIFO），用于暂存最近的写命令。
运行 ID（runID）：每个 Redis 节点启动时生成的唯一标识。
复制偏移量（Offset）：主从节点各自维护一个 offset。
机制：断线重连后，Slave 发送自己的 runID 和 offset。如果 runID 匹配且 offset 仍在 Master 的复制积压缓冲区内，Master 仅将断开期间的命令增量发送给 Slave。

五、技术扩展：负载均衡算法

客户端在进行读写分离时，需要通过负载均衡器（LB）来选择访问哪一台从机。常见的负载均衡算法有：

算法名称	原理	优缺点 / 适用场景
轮询（Round-Robin）	按顺序将请求依次分配给每台从机。	简单均衡；但无法感知机器性能差异。
随机（Random）	随机选择一台从机。	简单高效；在请求量大时趋于平均分配。
一致性 Hash	根据请求的 Key 或客户端 IP 计算 Hash，映射到环形哈希空间，路由到固定机器。	极力推荐。对于同一个客户端或同一批 Key，总是访问同一台机器，能最大化利用从机的本地缓存。

LB 实现层分类

硬件负载均衡：
- 代表：F5、A10，性能强悍、可靠性高，多用于核心入口，采购及运维成本高。
服务端软件负载均衡：
- Nginx：主打七层 HTTP/HTTPS，也可通过 Stream 模块实现四层 TCP 转发；
- HAProxy：四层、七层能力均衡，TCP 四层转发场景使用广泛。
客户端负载均衡：
- 由客户端代码自行实现路由：客户端对接注册中心（ZooKeeper、Consul、Nacos 等）拉取节点列表，本地完成负载转发，例如 Redis 客户端 Jedis/Lettuce、RPC 框架等均采用该方案。

六、主从复制的缺点与痛点

复制延时与信号衰减：所有的写操作都在 Master 上进行，然后异步同步到 Slave。网络繁忙或 Slave 数量增多时，同步延迟会增大，可能导致客户端读到过期/脏数据。
没有自动故障转移：默认情况下，Master 挂了，Slave 无法自动选举为新 Master，需要人工干预，可用性（HA）较低。
写扩展瓶颈：由于只有一个 Master 节点负责写，当业务写并发极高时，单机 Master 会遇到内存和 CPU 的硬件瓶颈。
内存浪费：所有从节点都保存了一份全量数据的副本，无法实现分布式存储（该问题需通过 Redis Cluster 解决）。