Redis之主从复制
在Redis中，用户可以通过执行SLAVEOF命令或者设置slaveof选项，让一个服务去复制另外一个服务器。
image.png
旧版复制功能的实现
-
同步(sync)
-
命令传播(command propagate)
同步
-
从服务器向主服务器发送SYNC命令。
-
收到SYNC命令的主服务器执行BGSAVE命令，在后台生成-一个RDB文件，并使 用一个缓冲区记录从现在开始执行的所有写命令。
-
当主服务器的BGSAVE命令执行完毕时，主服务器会将BGSAVE命令生成的RDB 文件发送给从服务器，从服务器接收并载人这个RDB文件，将自己的数据库状态更新至主 服务器执行BGSAVE命令时的数据库状态。
-
主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写. 命令，将自己的数据库状态更新至主服务器数据库当前所处的状态。
image.png
命令传播
在同步操作执行完毕之后，主从服务器两者的数据库将达到- -致状态，但这种一致并不 是一成不变的，每当主服务器执行客户端发送的写命令时，主服务器的数据库就有可能会被 修改，并导致主从服务器状态不再一致。
image.png
旧版复制功能的缺陷
在Redis中，从服务器对主服务器的复制可以分为以下两种情况:
-
初次复制:从服务器以前没有复制过任何主服务器，或者从服务器当前要复制的主 服务器和上一次复制的主服务器不同。
-
断线后重复制:处于命令传播阶段的主从服务器因为网络原因而中断了复制，但从 服务器通过自动重连接重新连上了主服务器，并继续复制主服务器。
对于初次复制来说，旧版复制功能能够很好地完成任务，但对于断线后重复制来说，旧 版复制功能虽然也能让主从服务器重新回到-致状态，但效率却非常低。
SYNC命令是一个非常耗费资源的操作 每次执行SYNC命令，主从服务器需要执行以下动作:
-
主服务器需要执行BGSAVE命令来生成RDB文件，这个生成操作会耗费主服务 器大量的CPU、内存和磁盘I/O资源。
-
主服务器需要将自己生成的RDB文件发送给从服务器，这个发送操作会耗费主 从服务器大量的网络资源(带宽和流量)，并对主服务器响应命令请求的时间产生影响。
-
接收到RDB文件的从服务器需要载入主服务器发来的RDB文件，并且在载入. 期间，从服务器会因为阻塞而没办法处理命令请求。 因为SYNC命令是一个如此耗费资源的操作，所以Redis有必要保证在真正有需要 时才执行SYNC命令。
新版复制功能的实现
为了解决旧版复制功能在处理断线重复制情况时的低效问题，Redis从2.8版本开始, 使用PSYNC命令代替SYNC命令来执行复制时的同步操作。
PSYNC命令具有完整重同步( full resynchronization)和部分重同步( partial resynchronization)
-
其中完整重同步用于处理初次复制情况:完整重同步的执行步骤和SYNC命令的执 行步骤基本- -样，它们都是通过让主服务器创建并发送RDB文件，以及向从服务器 发送保存在缓冲区里面的写命令来进行同步。
-
而部分重同步则用于处理断线后重复制情况:当从服务器在断线后重新连接主服务 器时，如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送 给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务 器当前所处的状态。
PSYNC命令的部分重同步模式解决了旧版复制功能在处理断线后重复制时出现的低效
情况。
主从服务器执行部分重同步的过程
image.png
部分重同步的实现
部分重同步功能由一下的三个部分构成
-
主服务器的复制偏移量( replication offset )和从服务器的复制偏移量。
-
主服务器的复制积压缓冲区( replication backlog )。
-
服务器的运行ID(runID)。
复制偏移量
执行复制的双方 -- 主服务器和从服务器会分别维护一个复制偏移量：
-
主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量加上N.
-
从服务器每次收到主服务器传播来的N个字节的数据的时候，就将自己的复制偏移量的值加上N.
复制积压缓冲区
复制积压缓冲区是由主服务器维护的--个固定长度(fixed-size)先进先出(FIFO)队列，默认大小为1MB。
当主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命写入到复制积压缓冲区中。
image.png
主服务器的复制积压缓冲区里面会保存着一部分 最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。
主服务器向从服务器发送丢失的数据
根据需求调整复制积压缓冲区的大小
服务器的运行ID
除了复制偏移量和复制积压缓冲区之外，实现部分重同步还需要用到服务器运行ID(runID)：
- 每个Redis服务器，不论主服务器还是从服务，都会有自己的运行ID。
- 运行ID在服务器启动时自动生成，由40个随机的十六进制字符组成，例如53b9b28df8042fdc9ab5e3f cbbbabf f1d5dce2b3。
- 当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID传送给从服务器，而从服务器则会将这个运行ID保存起来。
- 当从服务器断线并重新连上-一个主服务器时，从服务器将向当前连接的服务器发送之前保存的运行ID:
- 如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同，那么说明从服务器断线之前复制的就是当前连接的这个主服务器，主服务器可以继续尝试执行部分重同步操作。
- 相反地，如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同，那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器，主服务器将对从服务器执行完整重同步操作。
PSYNC命令实现
PSYNC执行完整重同步和部分重同步时可能遇上的情况
复制的实现
通过向从服务器发送SLAVEOF命令，我们可以让-一个从服务器去复制- -个主服务器:SLAVEOF <master_ ip> <master_ _port>
1.设置主机的地址和端口
2.建立套字节连接
3.发送PING命令
- 虽然主从服务器成功建立起了套接字连接，但双方并未使用该套接字进行过任何通信，通过发送PING命令可以检查套接字的读写状态是否正常。
-
因为复制工作接下来的几个步骤都必须在主服务器可以正常处理命令请求的状态下才能进行，通过发送PING命令可以检查主服务器能否正常处理命令请求。
4.身份验证
5.发送端口信息
- 在身份验证步骤之后，从服务器将执行命令REPLCONE listening-port <port-number>,向主服务器发送从服务器的监听端口号。
6.同步
7.命令传播
心跳检测
在命令传播阶段,从服务器默认会以每秒- - 次的频率，向主服务器发送命令:
REPLCONF ACK <rep1 ication_ offset>
其中replication_ offset 是从服务器当前的复制偏移量。
发送REPLCONP ACK命令对于主从服务器有三个作用: .
- 检测主从服务器的网络连接状态。
- 辅助实现min-slaves选项。
Redis的min-slaves-to-write和min-slaves-max- lag两个选项可以防止主服
务器在不安全的情况下执行写命令。
举个例子，如果我们向主服务器提供以下设置:
min-slaves-to-write 3
min-slaves-max-lag 10
那么在从服务器的数量少于3个，或者三个从服务器的延迟(lag) 值都大于或等于10秒时，主服务器将拒绝执行写命令，这里的延迟值就是上面提到的INFOreplication命令的lag值。
- 检测命令丢失。
如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送REPLCONF ACK命令时，主服务器将发觉从服务器当前的复制偏移量少于自已的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。
参考书籍:《Redis设计与实现》
8S1SQ1.png
