接上篇,《redis的主从同步（一）2.8版本以前的方式》,在最后，讲了到了2.8版本之前的方式有缺陷，大家还记得吧，今天来讲讲从2.8版本开始redis主从同步方式的改进

先来回顾下2.8版本之前redis主从同步方式的缺陷

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

总结下来就是，老版的主从同步方式对于断线重连情况下很低率，所以2.8版本开始通过PSYNC命令代替了SYNC命令来执行同步操作

PSYNC命令

• PSYNC命令有两种模式：完整同步模式（full resynchronization）和部分同步模式（partial resynchronization）两种模式

完整同步模式（full resynchronization）

• 完整同步模式用于处理初次复制情况
• 完整同步模式的执行过程和SYNC命令一致，我们顺便回顾下，过程如下：
  
  同步（sync）操作的流程
• 1.从服务器向主服务器发送slaveof命令
• 2.主服务器接受到slaveof命令后
• 3.开始执行BGSAVE命令
• 4.在后台生成一个RDB文件
• 5.并使用一个缓冲区记录从开始执行的所有命令
• 6.主服务器BGSAVE命令执行完毕
• 7.主服务器将BGSAVE命令生成的RDB文件发送至从服务器
• 8.从服务器接受RDB文件并且载入
• 9.将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态
• 10.主服务器将记录在缓冲区中里所有的写命令发送给从服务器
• 11.从服务器执行这些命令完成整个同步过程

部分同步模式（partial resynchronization）

• 部分同步模式主要来处理断线重连后的复制场景
• 别的和SYNC命令一致，只有在断线重连后，主节点会把断线断线期间的命令同步过从节点，不会在重新同步所有的命令了

来看下断线重连情况下的PSYNC命令执行过程

• 而这个过程，主要依赖于三个部分

主从服务器的复制偏移量

• 主从服务双方都会维护一个复制偏移量
• 主服务器每次给从服务器传播n个字节，就将自己维护的偏移量加n
• 从服务每次接收到主服务器传播过来的数据时，就将自己维护的偏移量加上数据大小的字节数
• 主从偏移量栗子：

主服务器偏移量：offset=100
从服务器A偏移量：offset=100
从服务器B偏移量：offset=100

• 此时说明主服务和从服务器A、从服务器B都处于同步一致的状态
• 当主服务向从服务同步100字节数据后

主服务器偏移量：offset=100
从服务器A偏移量：offset=200
(从服务器B和主服务器断开链接)从服务器B偏移量：offset=100

• 此时说明主服务和从服务器A处于同步一致的状态
• 而从服务B因为断线原因导致从服务器B的偏移量 offset=100，可以判断出来他们不处于数据同步状态

主服务器的复制积压缓存区

• 复制积压缓存区是由主服务器维护的一个队列，默认大小为1MB

• 该队列是固定长度和先进先出的

• 当主服务器对从服务器执行命令传播时，不光会发送所有命令给所有从服务

• 还会把所有命令写入复制积压缓存区中，如图：
  

  复制积压缓存区

• 因为复制积压缓存区是队列，是把主服务的每一个命令的字节写入到队列中，包含两部分，偏移量和命令字节值

• 队列结构如下:

Node1:
offset=1
val=s
Node2:
offset=2
val=e
Node3:
offset=3
val=t
Node4:
offset=4
val=k
Node5:
offset=5
val=1
Node6:
offset=6
val=v
Node7:
offset=7
val=1

• 看到队列结构，就是把主服务的命令set k1 v1的每一个字节和字节对应的偏移量存放到复制积压缓存区中
• 当从服务器重连上主服务器上时，从服务器会通过PSYNC将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量来判断是使用完整同步 还是 部分同步，具体操作如下：

redis服务的运行id

• 每一个redis服务启动时候，都会有自己的运行id
• 每个id都不会重复，具体怎么实现的不看了
• 当从服务和主服务器进行初次复制时，从服务会保存主服务的运行id
• 在断线重连后，执行PSYNC命令是，会比较该id，如果前后id一致，主服务在通过判断复制偏移量判断是需要完整同步还是部分同步，如果前后id不一致，那么说明前后的主服务不一样，所以选用完整同步

PSYNC命令执行的详细过程

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