接上篇,《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命令执行过程
| 时间 | 主服务器 | 从服务器 |
|---|---|---|
| T0 | 主从服务器完成同步 | 主从服务器完成同步 |
| T1 | 执行传播命令，传播 set k1 v1 命令 | 执行主服务器传播过来的 set k1 v1 命令 |
| T2 | 执行传播命令，传播 set k2 v2 命令 | 执行主服务器传播过来的 set k2 v2 命令 |
| T3 | 此时发生故障，主从服务器断开链接 | 此时发生故障，主从服务器断开链接 |
| T4 | set k3 v3 | 此时已经和主服务器断开连接，set k3 v3 没有传播过来 |
| T5 | set k4 v4 | 此时已经和主服务器断开连接，set k4 v4 没有传播过来 |
| T6 | 此时故障恢复，主从服务器重新链接 | 此时故障恢复，主从服务器重新链接 |
| T7 | 向主服务器发送 PSYNC命令 | |
| T8 | 向从服务器发送确认回复，执行部分同步 | 接受到主服务器的确认回复，执行部分同步 |
| T9 | 向从服务器发送set k3 v3、set k4 v4两个命令 | |
| T10 | 接收到主服务器发送过来的set k3 v3、set k4 v4两个命令，并执行 | |
| T11 | 此时主从服务器完成部分同步 | 此时主从服务器完成部分同步 |
- 而这个过程，主要依赖于三个部分
主从服务器的复制偏移量
- 主从服务双方都会维护一个复制偏移量
- 主服务器每次给从服务器传播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发送给主服务器，主服务器会根据这个复制偏移量来判断是使用完整同步还是部分同步，具体操作如下：
| 时间 | 主服务器 | 从服务器 |
|---|---|---|
| T0 | 此时发生故障，主从服务器断开链接 | 此时发生故障，主从服务器断开链接 |
| T1 | 此时故障恢复，主从服务器重新链接 | 此时故障恢复，主从服务器重新链接 |
| T2 | 向服务器发送 PSYNC命令，命令中会将自己的复制偏移量发送过去 | |
| T3 | 接受到从服务器传过来的复制偏移量进行判断 | |
| T4 | 如果该复制偏移量以后的数据还存在复制缓存区里面，就执行部分同步，数据从复制缓存区取 | |
| T5 | 若果该复制偏移量以后的数据不存在了（因为队列先进先出），所以要执行完整同步 |
redis服务的运行id
- 每一个redis服务启动时候，都会有自己的运行id
- 每个id都不会重复，具体怎么实现的不看了
- 当从服务和主服务器进行初次复制时，从服务会保存主服务的运行id
- 在断线重连后，执行
PSYNC命令是，会比较该id，如果前后id一致，主服务在通过判断复制偏移量判断是需要完整同步还是部分同步，如果前后id不一致，那么说明前后的主服务不一样，所以选用完整同步
PSYNC命令执行的详细过程
| 时间 | 主服务器 | 从服务器 |
|---|---|---|
| T0 | 主服务器启动，生成唯一运行id（假装模拟一个)=1 | 从服务器启动，生成唯一运行id（假装模拟一个)=2 |
| T1 | 此时，主从初次复制完成（假设没有命令），主偏移量offset=0，复制积压缓存区中间没有数据 | 此时，主从初次复制完成（假设没有命令），从偏移量offset=0 |
| T2 | 执行传播命令，传播 set k1 v1 命令，把该命令写入复制积压缓存区，主偏移量offset=9 | 执行主服务器传播过来的 set k1 v1 命令,从偏移量offset=9 |
| T3 | 执行传播命令，传播 set k2 v2 命令，把该命令写入复制积压缓存区，主偏移量offset=18 | 执行主服务器传播过来的 set k2 v2 命令，从偏移量offset=18 |
| T4 | 此时发生故障，主从服务器断开链接 | 此时发生故障，主从服务器断开链接 |
| T5 | 执行set k3 v3命令，把该命令写入复制积压缓存区，主偏移量offset=27 | 此时已经和主服务器断开连接，set k3 v3 没有传播过来 |
| T6 | 执行set k4 v4命令，把该命令写入复制积压缓存区，主偏移量offset=36 | 此时已经和主服务器断开连接，set k4 v4 没有传播过来 |
| T7 | 此时故障恢复，主从服务器重新链接 | 此时故障恢复，主从服务器重新链接 |
| T8 | 向主服务器发送 PSYNC命令，带了上次同步的主服务运行id=1，从服务器的偏移量offset=18 | |
| T9 | 主服务器接受到PSYNC命令，通过对于运行id，发现是断线之前的两个服务器 | |
| T10 | 主服务器在判断从服务器发送过来从服务偏移量，从服务器发送过来的偏移量offset=18，主服务判断复制积压缓存区中offset=18以后的数据是否存在，发现数据存在，主服务器判断使用部分同步 | |
| T11 | 向从服务器发送确认回复，执行部分同步 | 接受到主服务器的确认回复，执行部分同步 |
| T12 | 主服务从复制积压缓存区中偏移量offset=18以后的舒服，向从服务器发送set k3 v3、set k4 v4两个命令 | |
| T13 | 接收到主服务器发送过来的set k3 v3、set k4 v4两个命令，并执行，并更新从服务器的偏移量offset=36 | |
| T14 | 此时主从服务器完成部分同步,他们的偏移量都为offset=36 | 此时主从服务器完成部分同步,他们的偏移量都为offset=36 |
今天讲了redis的主从同步中的2.8版本以后的方式，欢迎大家来交流，指出文中一些说错的地方，让我加深认识，愿大家没有bug，谢谢！
网友评论