参考资料：

《Redis 复制》

《redis：主从复制缓冲区》

《Redis进阶 - 高可用：主从复制详解》

        写在开头：本文为学习后的总结，可能有不到位的地方，错误的地方，欢迎各位指正。

目录

一、主从复制简介

        1、主从复制是什么

        2、主从复制有哪些作用

二、主从复制详解

        1、复制方式

        2、全量复制

        （1）确立主从关系

        （2）全量复制的流程

        3、增量复制

        （1）复制偏移量（replication offset）

        （2）复制积压缓冲区（replication backlog）

一、主从复制简介

        1、主从复制是什么

        主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。

        2、主从复制有哪些作用

• 数据备份：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。
• 读写分离：由主节点提供写服务，由从节点提供读服务，提高Redis服务器的并发量。

        主从库之间采用的是读写分离的方式。

• 读操作：主库、从库都可以接收；
• 写操作：首先到主库执行，然后，主库将写操作同步给从库。

二、主从复制详解

        1、复制方式

• 全量复制：比如第一次同步时
• 增量复制：只会把主从库网络断连期间主库收到的命令，同步给从库

        Redis在2.8版本之前只有全量复制，而2.8版本后有全量和增量复制。

        2、全量复制

        （1）确立主从关系

                Redis 通过 replicaof host port （5.0前使用slaveof）命令来让一个Redis服务成为另一个Redis服务的从库。

                例如，现在有实例 1（ip：172.16.19.3）和实例 2（ip：172.16.19.5），我们在实例 2 上执行以下这个命令后，实例 2 就变成了实例 1 的从库，并从实例 1 上复制数据：

replicaof 172.16.19.3 6379

        （2）全量复制的流程

        完整复制流程如下：

• 第一步，从库向主库发送PSYNC ? -1 命令，主动请求进行完整重同步

        这一步是主从库间建立连接、协商同步的过程，主要是为全量复制做准备。在这一步，从库和主库建立起连接，并告诉主库即将进行同步，主库确认回复后，主从库间就可以开始同步了。 

        从库给主库发送 psync 命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。psync 命令包含了主库的 runID 和复制进度 offset 两个参数。

        runID是Redis启动时给每个实例创建的唯一ID，用以标识不同的Redis实例，当从库和主库第一次复制时，因为不知道主库的 runID，所以将 runID 设为“？”。offset则表示复制进度（也叫复制偏移量），主要为增量复制服务，这里因为是全量复制，所以使用-1表示。

• 第二步，主库向从库发送FULLRESYNC响应命令并带上两个参数：主库 runID 和主库目前的复制进度 offset
• 第三步，主库执行 bgsave 命令，生成 RDB 文件，并发给从库。

        此时，主库为了响应从库的复制请求，会调用bgsave 命令，生成 RDB 文件，接着将文件发给从库。（RDB在此前的持久化内容中已做过介绍，这里不再赘述，不了解的可以看这里《Redis：持久化RDB与AOF》）

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

• 第四步，将发送过程中收到的指令存储到replication buffer中，并发送给从库

        就像RDB文件生成过程中Redis不停止提供服务一样，从库在接收并载入RDB文件的过程中，主库仍然可以写入数据，那怎么将这部分数据传给从库呢？

        为了处理这部分数据，主库为每个连接进来的从库准备了一个replication buffer缓冲区，这段时间内写入的数据都会被存入这个replication buffer中，等从库载入完RDB文件后，就将replication buffer中的数据推送过去。

        如上，全量复制的完成流程就完成了，后续主库接收到的写命令都会被主库传递给所有从库，以保证数据的一致性。

        3、增量复制

        在2.8以前只有全量复制，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。因此 从Redis 2.8 开始提供了增量复制的功能，在网络断了之后，主从库会采用增量复制的方式继续同步。

        （1）复制偏移量（replication offset）

        主服务器和从服务器会分别维护一个复制偏移量。如果主从服务器的复制偏移量相同，则说明二者的数据库状态一致；反之，则说明二者的数据库状态不一致。

        （2）复制积压缓冲区（replication backlog）

        主库的写命令，除了传给从库后，还会写入replication backlog（全局唯一），这是一个固定长度的先进先出（FIFO）队列，默认大小为 1MB。其在内存中是一个环形结构。       

         如上图，主库按照顺时针方向写命令，主库最新写入的位置即为上文提到的主库的偏移量，这里叫master offset。假设从库在set key2 2后断开连接，也就是上图中slave offset的位置，当它重连时，再次给主库发送psync指令时，会带上自己的offset（注意和全量复制的区别，全量复制时offset设置为-1），那么主库会计算出master offset与slave offset之间的指令，并发送给该为从库准备的replication buffer中，发送给从库。

        需要注意的是，整个replication backlog是个环形结构，也就是说最新的写命令会将最老的写命令覆盖。换句话说，如果从库断开时间太久，环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量复制，所以replication backlog配置要尽量大一些，可以降低主从断开后全量复制的概率。

        整个增量复制流程如下：