十二、复制(Redis)

发布于:2021-12-03 08:18:29

在Redis中,用户可以通过执行SLAVEOF命令或者设置slaveof选项,让一个服务 器去复制(replicate)另一个服务器,我们称呼被复制 的服务器为主服务器(master),而对主服务器进行复制 的服务器则被称为从服务器(slave)。



一、旧版复制功能的实现

Redis的复制功能分为同步(sync )和命令传播(command propagate )两个操作:


同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态。


命令传播操作则用于在主服务器的数据库状态被修改,导致主从服务器的数据库状 态出现不一致时,让主从服务器的数据库重新回到一致状态。


1.1 同步

? ? 将从服务器的数据库状态更新至主服务器当前所处的数据库 状态
?? ?步骤 :
? ? 1.从服务器向主服务器发送SYNC命令


? ? 2.收到命令的主服务器执行命令,在后台生成一个RDB文件,并使 用一个缓冲区记录从现在开始执行的所有写命令


? ? 3.当主服务器的BGSAVE命令执行完毕时,主服务器会将命令生成的RDB 文件发送给从服务器,从服务器接收并载人这个RDB文件,将自己的数据库状态更新至主 服务器执行叹命令时的数据库状态。


? ? 4.主服务器将记录在缓冲区里面的所有写命令发送给从服务器,从服务器执行这些写 命令,将自己的数据库状态更新至主服务器数据库当前所处的状态



1.2 命令传播

在同步操作执行完毕之后,主从服务器两者的数据库将达到一致状态,但这种一致并不是一成不变的,每当主服务器执行客户端发送的写命令时,主服务器的数据库就有可能会被 修改,并导致主从服务器状态不再一致



为了让主从服务器再次回到一致状态,主服务器需要对从服务器执行命令传播操作: 服务器会将自己执行的写命令,也即是造成主从 服务器不一致的那条写命令,发送给从服务器执 行,当从服务器执行了相同的写命令之后,主从 服务器将再次回到一致状态。



?


二、旧版复制功能的缺陷

在Redis中,从服务器对主服务器的复制可以分为以下两种情况:


初次复制:
?? ?从服务器以前没有复制过任何主服务器,或者从服务器当前要复制的主 服务器和上一次复制的主服务器不同


断线后重复制:
?? ?处于命令传播阶段的主从服务器因为网络原因而中断了复制,但从 服务器通过自动重连接重新连上了主服务器,并继续复制主服务器


对于初次复制来说,旧版复制功能能够很好地完成任务,但对于断线后重复制来说,旧 版复制功能虽然也能让主从服务器重新回到一致状态,但效率却非常低,因为断线重连后,从服务器会发送sync命令给主服务器,重新进行同步操作,这样会给主服务器和从服务器造成巨大的资源浪费



每次执行SYNC命令,主从服务器需要执行以下动作:
?? ?主服务器需要执行BEGSAVE命令进行RDB生成RDB文件,但这会耗费服务器大量的CPU、内存和磁盘I/O资源
?? ?主服务器需要将自己生成的RDB文件发送给从服务器,这个发送操作会耗费主 从服务器大量的网络资源(带宽和流量),并对主服务器响应命令请求的时间产生影响
?? ?接收到RDB文件的从服务器需要载入主服务器发来的RDB文件,并且在栽入 期间,从服务器会因为阻塞而没办法处理命令请求


?


三、新版复制功能的实现

为了解决旧版复制功能在处理断线重复制情况时的低效问题,Redis从2.8版本开始, 使用PSYNC命令代替SYNC命令来执行复制时的同步操作


PSYNC命令具有完整重同步(full resynchronization)和部分重同步(partial resynchronization) 两种模式:


完整重同步:
?? ??? ?完整重同步用于处理初次复制情况:完整重同步的执行步骤和命令的执 行步骤基本一样,它们都是通过让主服务器创建并发送RDB文件,以及向从服务器 发送保存在缓冲区里面的写命令来进行同步


部分重同步:
?? ??? ?部分重同步则用于处理断线后重复制情况:当从服务器在断线后重新连接主服务 器时,如果条件允许,主服务器可以将主从服务器连接断开期间执行的写命令发送 给从服务器,从服务器只要接收并执行这些写命令,就可以将数据库更新至主服务 器当前所处的状态



?


四、部分重同步的实现

部分重同步功能由以下三个部分构成:


主服务器的复制偏移量(replication offset)和从服务器的复制偏移量。


主服务器的复制积压缓冲区(replication backlog)。


服务器的运行ID ( run ID )。


4.1 复制偏移量

执行复制的双方??主服务器和从服务器会分别维护一个复制偏移量:
?? ?主服务器每次向从服务器传播N个字节的数据时,就将自己的复制偏移量的值加上N
?? ?从服务器每次收到主服务器传播来的N 个字节的数据时,就将自己的复制偏移量 的值加上N




通过对比主从服务器的复制偏移量,程序可以很容易地知道主从服务器是否处于一致状态



4.2 复制积压缓冲区

复制积压缓冲区是由主服务器维护的一个固定长度(fixed-size)先进先出(FIFO)队 列,默认大小为1MB。



当主服务器进行命令传播时,它不仅会将写命令发送给所有从服务器,还会将命令写入队到复制积压缓冲区里面



当从服务器重新连上主服务器时,从服务器会通过命令将自己的复制偏移量 offset发送给主服务器,主服务器会根据这个复制偏移量来决定对从服务器执行何种同步 操作:


部分重同步:
?? ??? ?如果offset偏移量之后的数据(也即是偏移量offset+1开始的数据)仍然存在 于复制积压缓冲区里面,那么主服务器将对从服务器执行部分重同步操作


完整重同步:
?? ??? ?如果offset偏移量之后的数据已经不存在于复制积压缓冲区,那么主服务 器将对从服务器执行完整重同步操作


缓冲区大小设置
?? ??? ?主服务器*均每秒产生的写命令数据量 (协议格式的写命令的长度总和)*2



4.3 服务器运行ID

除了复制偏移量和复制积压缓冲区之外,实现部分重同步还需要用到服务器运行ID (run ID ):


? ? ? ? 每个Redis服务器,不论主服务器还是从服务,都会有自己的运行ID


? ? ? ? 运行ID在服务器启动时自动生成,由40个随机的十六进制字符组成,例如53b9b 28df8042fdc9ab5e3fcbbbabffld5dce2b3


?


当从服务器对主服务器进行初次复制时,主服务器会将自己的运行ID传送给从服务器, 而从服务器则会将这个运行ID保存起来。


当从服务器断线并重新连上一个主服务器时,从服务器将向当前连接的主服务器发送之 前保存的运行ID:


? ? ? ? 如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同,那么说明从服 务器断线之前复制的就是当前连接的这个主服务器,主服务器可以继续尝试执行部 分重同步操作


? ? ? ? 如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同, 那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器,主服 务器将对从服务器执行完整重同步操作


?


五、PSYNC命令的实现


?


六、复制的实现

6.1 设置主服务器的地址和端口


6.2 建立套接字连接


6.3 发送PING命令


6.4 身份验证


6.5 发送端口信息


6.6 同步


6.7 命令传播


?


七、心跳检测

在命令传播阶段,从服务器默认会以每秒一次的频率,向主服务器发送命令:


? ? REPLCONF ACK


其中replication_of fset是从服务器当前的复制偏移量。


发送命令对于主从服务器有三个作用:


? ? 1.检测主从服务器的网络连接状态。


? ? 2.辅助实现min-slaves选项。


? ? 3.检测命令丢失。


?


7.1 检测主从服务器的网络连接状态

主从服务器可以通过发送和接收命令来检查两者之间的网络连接是否 正常:如果主服务器超过一秒钟没有收到从服务器发来的命令,那么主服 务器就知道主从服务器之间的连接出现问题了。



7.2 辅助实现min-slaves配置选项

Redis 的 min-slaves-to-write 和 min-slaves-max-lag 两个选项可以防止主服 务器在不安全的情况下执行写命令。


min-slaves-to-write 3


min-slaves-max-lag 10


那么在从服务器的数量少于3个,或者三个从服务器的延迟(lag )值都大于或等于10 秒时,主服务器将拒绝执行写命令,这里的延迟值就是上面提到的命令的 lag 值。


?


7.3 检测命令?失

? ? 如果因为网络故障,主服务器传播给从服务器的写命令在半路丢失,那么当从服务器向 主服务器发送命令时,主服务器将发觉从服务器当前的复制偏移量少于自 己的复制偏移量,然后主服务器就会根据从服务器提交的复制偏移量,在复制积压缓冲区里 面找到从服务器缺少的数据,并将这些数据重新发送给从服务器。


?

相关推荐

最新更新

猜你喜欢