Redis——主从复制

一、为什么需要主从复制？

在互联网应用的早期，我们可能只部署了一个 Redis 实例。这个实例既是"保姆"又是"管家"，既要处理写请求，又要应对读请求。

这种单机模式看似简单，实则暗藏两大"致命"风险：

单点故障（Single Point of Failure） ：
如果这台 Redis 服务器突然宕机，所有请求都会直接打到后端数据库（如 MySQL）上。由于数据库通常无法承受如此巨大的并发量，极大概率也会随之"崩塌"，导致整个服务不可用。
读写压力过大 ：
在真实的业务场景中，读请求通常是写请求的几倍甚至几十倍（比如商品详情页的浏览 vs 下单）。单个 Redis 实例既要写又要读，CPU 和 I/O 往往不堪重负。

既然"一个人扛不住"，那我们就请"帮手"。这就是 Redis 主从复制（Master-Slave Replication） 的由来。

我们不再只依赖一台服务器，而是搭建一个 "主从架构" 团队：

主节点（Master） ：它是团队的"大脑"，拥有最终决策权。只负责处理写操作（如 SET, DEL）。
从节点（Slave） ：它是主节点的"影子"或"跟班"。它们只负责处理读操作（如 GET），并且时刻盯着主节点，一旦主节点数据有变，立刻同步更新自己。

这种架构最经典的模式就是 "一主多从" ：

通过这种读写分离的策略，我们将原本压在一台机器上的重担，合理地分摊给了整个团队。既解决了单点故障风险，又极大地提升了系统的读吞吐能力。

Redis主从复制的核心是PSYNC命令。当从节点（Slave）连接主节点（Master）时，会发送这个命令来申请同步数据。

主节点收到命令后，会根据从节点的状态，决定是进行"全量复制"还是"增量复制"。

场景：从节点第一次连接主节点，或者从节点的数据太旧，无法进行增量同步时。

全量复制就像是把整栋楼的图纸复印一份交给新来的同事。过程虽然重，但能保证数据绝对一致。

具体流程如下：

发送请求 ：从节点发送PSYNC ? -1，表示"我要全量同步"。
生成快照 ：主节点执行BGSAVE，在后台生成RDB快照文件。
传输数据：RDB文件生成后，主节点将其发送给从节点。
加载数据：从节点接收RDB文件，清空自己的旧数据，然后加载这份快照。
补发增量：在生成和传输RDB期间，主节点还在不断接收新写入。这些新命令会被缓存在**复制积压缓冲区（Replication Backlog）**中。RDB传输完成后，主节点会把缓冲区里的命令发给从节点，确保数据完全追平。

全量复制会非常消耗资源（CPU、内存、网络），如果频繁触发，会导致Redis卡顿。

场景：网络抖动导致连接断开，从节点重新连上后，只需要补上断开期间丢失的数据。

增量复制就像是看视频时断网了几秒，恢复后只需要下载那几秒的内容，而不需要重新看整部电影。

核心原理：

偏移量（Offset）：主从节点各自维护一个复制偏移量。主节点每发送N个字节，偏移量+N；从节点每接收N个字节，偏移量+N。
心跳机制：从节点会每秒上报自己的偏移量给主节点。
补发数据 ：从节点重连时，会带上自己的runid（主节点ID）和offset。主节点检查自己的复制积压缓冲区，如果从节点缺失的数据还在缓冲区里，就只发送这部分数据；如果数据已经被覆盖（缓冲区满了），那就只能退化成全量复制。

增量复制依赖于复制积压缓冲区的大小。如果缓冲区太小，网络抖动一下就可能导致全量复制。

Q1：全量复制和增量复制的区别是什么？

A：全量复制是"推倒重来"，传输整个RDB文件，开销大；增量复制是"查漏补缺"，只传输差异命令，开销小。全量通常发生在首次连接，增量发生在网络闪断恢复后。

Q2：什么是复制积压缓冲区？

A：它是一个固定大小的FIFO队列，默认大小1MB。主节点会把最近写入的命令缓存在这里。它的作用就是为从节点的增量复制提供数据源。

Q3：如何配置复制积压缓冲区的大小？

A：通过配置repl-backlog-size。在写入量大的场景下，建议调大这个值（比如100MB），防止从节点因为缓冲区溢出而频繁触发全量复制。

Q4：主从复制是同步的还是异步的？

A：是异步的。主节点写入后立即返回客户端，然后异步地将数据推送给从节点。所以从节点会有毫秒级的数据延迟。