10.全网最容易理解的Redis主从复制原理(高频面试题)

主从复制

如果 Redis 的读写请求量很大，那么单个 Redis 实例很有可能承担不了这么大的请求量，如何提高Redis的性能呢？我们可以部署多个副本节点，业务采用读写分离的方式，把读请求分担到多个副本节点上，提高访问性能。要实现读写分离，就必须部署多个副本，每个副本需要实时同步主节点的数据。

单可用区（节点全部在一个可用区）：无法应对机房级别的故障

1541628331324_.pic.jpg

如果上海可用区机房出现故障，整个Redis服务全部瘫痪，所以我们在平时部署时，需要把节点分散在不同的可用区，如果有小伙伴公司对可用性要求极高，可以研究下异地多活方案，在这里我就不展开了。

主从复制的三种方式：

①全量复制

②增量复制

③无盘复制

1.全量复制

假设我们有两个节点，A节点是 Master 节点，B节点是 Slave 节点。

当我们在节点B上执行slaveof命令后，节点B会与节点A建立一个TCP连接，然后发送psync ${runid} ${offset}命令，告知节点A需要开始同步数据。

参数介绍：

• runid：每个 Redis 实例启动时都会自动生成的一个随机 ID，用来唯一标记这个实例
• offset：偏移量，slave需要从哪个位置开始同步数据

1241627715863_.pic.jpg

由于是第一次同步，Slave 节点不知道 Master节点的runid，所以 Slave 节点会发送psync ? -1，表示需要全量同步数据。

Master 节点在收到 Slave 节点发来的psync后，会给slave回复+fullresync ${runid} ${offset}，这个runid就是master的唯一标识，slave会记录这个runid，用于后续断线重连同步请求。

Master 执行 bgsave 命令，生成 RDB 文件，接着将文件发给 Slave。Slave 接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。这是因为Slave在通过 replicaof 命令开始和 Master 同步前，可能保存了其他数据。为了避免之前数据的影响，Slave 需要先把当前数据库清空。

在 Master 将数据同步给 Slave 的过程中，Master 不会被阻塞，仍然可以正常接收请求。否则，Redis 的服务就被中断了。但是，这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主 Slave 的数据一致性，Master 会在内存中用 repl_backlog_buffer 记录 RDB 文件生成后收到的所有写操作。

最后，Master 会把 repl_backlog_buffer数据再发送给从库。这样一来，主从库就实现同步了。

全量复制的开销：

主节点：生成RDB文件会占用内存、硬盘资源，网络传输RDB的时候会占用一定的网络带宽资源

从节点：清空数据，若数据量大，需要消耗一定的时间，加载RDB也需要一定的时间

2.增量同步

在 Redis 2.8 之前，如果主从库在命令传播时出现了网络闪断，从库就会和主库重新进行一次全量复制，开销非常大。

在Redis在这方面进行了改进，在2.8版本之后，Redis支持增量同步。

1251627715877_.pic.jpg

主从因为故障断开，故障恢复后，他们重新建立连接，Slave 节点向 Master 节点发送数据 同步请求：psync ${runid} ${offset}，Master 收到psync命令之后，检查slave发来的runid与自身的runid一致，如果一致，说明之前已经同步过数据，这次只需要同步部分数据即可。

这里分为两种情况：
①如果offset在repl_backlog_buffer范围内，那么 Master 节点给 Slave 节点回复+continue，表示这次只同步部分数据。之后 Master 节点把复制缓冲区offset之后的数据给 Slave 节点，接下来 Slave 节点执行这些命令后就与 Master 数据一致了。

②如果offset不在repl_backlog_buffer范围内，说明断开连接很久了，如果offset在repl_backlog_buffer的内容已经被新的内容覆盖了，此时只能触发全量数据同步。

3.无盘复制

通常，全量复制需要在磁盘上创建RDB文件，然后加载到内存中，Redis支持无盘复制，生成的RDB文件不保存到磁盘而是直接通过网络发送给从节点。无盘复制适用于主节点所在机器磁盘性能较差但网络宽带较充裕的场景。需要注意的是，无盘复制目前依然处于实验阶段。