redis的主从同步（一）2.8版本以前的方式

最近我们的一个服务要解决一个主节点向从节点同步数据的问题，就来翻了翻书，研究了下redis是怎么实现主从同步的，来总结一下

今天先来说一下2.8版本之前是如何实现的

redis中，实现主从复制的方式主要有两种

1.配置文件中设置slaveof选项

配置文件地方

• 在从服务器的配置文件配置slaveof选项
• 配置如下：

slaveof  

• masterip 为redis主服务器的ip
• masterport 为redis主服务的redis服务端口

2.从服务器上使用客户端发送slaveof命令

从服务上发送命令

• 使用客户端，连接到从服务器上
• 在从服务器上发送slaveof命令
• 命令如下：

slaveof masterip masterport

• masterip 为redis主服务器的ip
• masterport 为redis主服务的redis服务端口

redis主从同步功能的原理

• redis的主从同步功能主要分为两个操作
• 同步（sync）操作
• 命令传播（command propagate）两个操作
• 同步（sync）操作主要作用是将当前从服务器的状态更新至主服务器的状态，也就是把当前主服务器中的所有数据同步至从服务中
• 命令传播（command propagate) 使用同步（sync）操作完成后，主服务器会把所有执行的命令传递到从服务器，让主从保持一致

先说说同步（sync）操作

• 当从服务器向主服务器发送slaveof命令时，要求同步主服务事，会先执行同步（sync）操作，主要作用是将当前从服务器的状态更新至主服务器的状态，也就是把当前主服务器中的所有数据同步至从服务中
• 同步（sync）操作的流程如下

同步（sync）操作的流程

同步（sync）操作的流程

• 1.从服务器向主服务器发送slaveof命令
• 2.主服务器接受到slaveof命令后
• 3.开始执行BGSAVE命令
• 4.在后台生成一个RDB文件
• 5.并使用一个缓冲区记录从开始执行的所有命令
• 6.主服务器BGSAVE命令执行完毕
• 7.主服务器将BGSAVE命令生成的RDB文件发送至从服务器
• 8.从服务器接受RDB文件并且载入
• 9.将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态
• 10.主服务器将记录在缓冲区中里所有的写命令发送给从服务器
• 11.从服务器执行这些命令完成整个同步过程

再说说命令传播（command propagate) 操作

• 当同步（sync）操作执行完毕后，此时，主从服务器的数据库状态达到了一致状态
• 然后主服务器会将自己执行的写命令发送给从服务器，从服务器会执行主服务器发过来的命令，来实现同步，就是传播（command propagate) 操作

借用书上图举个整体流程的例子

时间	主服务器	从服务器
T0	执行 SET K1 V1 命令
T1	执行 SET K2 V2 命令
T2		向主服务器发送slaveof命令
T3	1.主服务器接受到slaveof命令后 2.开始执行BGSAVE命令 3.在后台生成一个RDB文件，包含K1、K2 4.并使用一个缓冲区记录从开始执行的所有命令
T4	SET K3 V3,并把命令写入缓冲区
T5	SET K4 V4,并把命令写入缓冲区
T6	BGSAVE命令执行完毕，向从服务器发送RDB文件
T7		接收并载入主服务器发来的RDB文件， 获得K1、K2数据
T8	向从服务器发送缓冲区中的SET K3 V3、 SET K4 V4
T9		接收并执行主服务器发来的两个命令， 执行了SET K3 V3、SET K4 V4命令
T10	同步（sync操作完成），此时主服务器中有K1、K2、K3、K4 四个key	同步（sync操作完成），此时主服务器中有K1、 K2、K3、K4 四个key,数据库状态同步一致
T11	执行 SET K5 V5 命令，并且命令传播（command propagate) 把命令传递给从服务	执行主服务器传递过来的 SET K5 V5 命令
T12	执行 SET K6 V6 命令，并且命令传播 （command propagate) 把命令传递给从服务	执行主服务器传递过来的 SET K6 V6 命令
T13	主从服务器断开连接，并重连成功	主从服务器断开连接，并重连成功
T14	重新开始同步（sync）操作，重复上述流程

2.8版本之前主从同步的缺陷

• 2.8版本之前主从同步存在一些缺陷
• 按照上面的表格
• 如果是初次主从同步，是没有问题的
• 如果同步（sync）操作完成后，同步了K1、K2数据，此时，主从服务器之间处于命令传播 （command propagate) 阶段，传递了K3、K4命令，然后主从服务器之间断开连接
• 当主从服务器重新建立连接后，主从服务器之间又开始执行同步（sync）操作
• 此时的同步（sync）操作，主服务器生成RDB文件，RDB文件包含的key是从第一次同步中的K1开始，包含K1、K2、K3、K4
• 虽然还是可以完成同步（sync）操作，但是其实有很多key是没有必要再次同步的
• 因为同步（sync）操作中，需要主服务器生成RDB文件，这个操作会占用服务器的大量的资源：CPU、内存、IO
• 而主从服务器之间传递RDB文件会占用服务器带宽
• 从服务器加载RDB文件时，同样会占用服务器的大量的资源：CPU、内存、IO
• 所以没有没有必要的同步（sync）操作会损耗服务器资源，降低服务的性能

今天讲了redis的主从同步中的2.8版本以前的方式，最后说了2.8版本以前的方式中的一些缺陷，下次再来讲讲2.8版本以后的方式，欢迎大家来交流，指出文中一些说错的地方，让我加深认识，愿大家没有bug，谢谢！