Redis主从复制

March 29, 2020

redis主从复制是高可用方案中的一部分，那主从复制是如何进行的？又是如何实现的？怎么支撑了redis的高可用性？在主从模式下Master和Slave节点分别做了哪些事情？

redis高可用方案是什么？ #

我理解的redis高可用的特点有：

1. 高QPS，主从 => 读写分离
2. 高容量，集群分片 => 高容量
3. 故障转移，sentinel => 故障转移
4. 故障恢复，数据持久 => 故障恢复 ～ 这里我简单的理解（RDB + AOF）= 故障恢复

主从复制 #

redis 主从复制有两个版本：旧版（Ver2.8-），新版（Ver2.8+，增加PSYNC命令来解决旧版中的问题）

讨论复制时都需要考虑两种场景：

• 场景1：从节点刚刚上线，需要去同步主节点时，这部分可以理解为 全量复制。
• 场景2：从节点掉线，恢复上线后需要同步数据，使自己和主节点达到一致状态。这部分在旧版复制里等价于全量复制，在新版里可以理解为增量复制。

当然你肯定会想到如果主节点掉线，这时候会怎么样？这个场景当然也在redis高可用方案中，之时不是本文的重点，属于Sentinel机制的内容了。

旧版主从复制 #

前文说过了，旧版主从复制只有全量复制用于应付上述两个场景，因此下面的流程也只有一份：

1. 从服务器向主服务器发送sync命令。
2. 主服务器在收到sync命令之后，调用bgsave命令生成最新的rdb文件，将这个文件同步给从服务器，这样从服务器载入这个rdb文件之后，状态就会和主服务器执行bgsave命令时候的一致。
3. 主服务器将保存在命令缓冲区中的写命令同步给从服务器，从服务器执行这些命令，这样从服务器的状态就跟主服务器当前状态一致了。

如果你不知道redis中还有个缓冲区的话，建议系统的了解下redis中缓冲区的设计。这里缓冲区特指命令缓冲区，后面还会讲到复制缓冲区。

但是这样的实现在 场景2 下的缺点很明显：如果说从节点断线后迅速上线，这段时间内的产生的写命令很少，却要全量复制主库的数据，传输了大量重复数据。

SYNC命令产生的消耗：
1. 主节点生成RDB，需要消耗大量的CPU，内存和磁盘IO
2. 网络传输大量字节数据，需要消耗主从服务器的网络资源
3. 从节点需要从RDB文件恢复，会造成阻塞无法接受客户端请求

优点就是：简单暴力。个人看来在redis架构中不合适的用法，不代表说实际场景中也一定不合适，简单暴力也是一个很大的优点。

新版主从复制 #

新版的主从复制跟旧版的区别就在于：对场景2的优化。

场景2的缺点上文已经提到过了，那么优化的方向就是**“尽量不使用全量复制；增加增量复制(PSYNC)的功能”**。为此还要解决下列问题：

1. 如果某个从节点断线了，重新上线该从节点如何知道自己是否应该全量还是增量复制呢？
2. 该从节点断线恢复后，又怎么知道自己缺失了哪些数据呢？
3. 主节点又如何补偿该从节点在断线期间丢失的那部分数据呢？旧版的复制除了RDB，还有从命令缓冲区中的写命令来保持数据一致。

为此新版中使用了以下概念：

运行ID - runid #

每个redis服务器都有其runid，runid由服务器在启动时自动生成，主服务器会将自己的runid发送给从服务器，而从服务器会将主服务器的runid保存起来。从服务器redis断线重连之后进行同步时，就是根据runid来判断同步的进度：

1. 如果前后两次主服务器runid一致，则认为这一次断线重连还是之前复制的主服务器，主服务器可以继续尝试部分同步操作。
2. 如果前后两次主服务器runid不相同，则全同步流程。

复制偏移量 - offset #

主从节点，分别会维护一个复制偏移量： 主服务器每次向从服务器同步了N字节数据之后，将修改自己的复制偏移量+N。从服务器每次从主服务器同步了N字节数据之后，将修改自己的复制偏移量+N。通过对比主从节点的偏移量很容易就可以发现，主从节点是否处于一致状态。