Login
网站首页 > 文章中心 > 其它

Redis|*|#8211;主从复制_Sync,PSYNC)_redis怎么读

作者:小编 更新时间:2023-08-11 23:01:34 浏览量:432人看过

Redis 中,可以通过执行 savleof 命令或者设置 slaveof 选项,让一个服务器去复制另一个服务器,我们称被复制的服务器为主服务器,而对主服务器进行复制的服务器则被称为从服务器.

Redis 2.8 之前复制功能的实现

Redis 中的复制分为同步和命令传播两个操作.

同步操作是将从服务器的数据库状态更新值主服务器当前所处的数据库状态.

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

同步

从服务器对主服务器的同步操作是通过向主服务器发送 sync 命令来完成,执行步骤如下:

从服务器向主服务器发送 sync 命令.

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

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

Redis|*|#8211;主从复制_Sync,PSYNC)_redis怎么读

命令传播

命令传播是指:在同步之后,主服务器会将同步期间缓冲区保存的写命令,发送给从服务器执行,当从服务器执行了相同的写命令之后,主从服务器将再次回到一致状态.

Redis 2.8 之前复制功能的缺陷

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

初次复制:从服务器以前没有复制过主服务器.

断线后重新复制:从服务器因为网络原因中断了复制,但从服务器通过自动重连接重新连接上了主服务器,并继续复制主服务器.

对于初次复制来说,旧版复制功能能够很好的完成任务,但对于断线后重新复制来说,旧版复制功能虽然也能让主从服务器数据一致(重新发起SYNC请求,主服务器重新生成RDB文件进行同步),但效率却非常低(可能主从断开连接过程中主服务器只执行了一条写命令却要重新生成整个RDB文件,耗费CPU,再传输给从服务器,耗费网络带宽).

Redis 2.8 之后复制功能的实现

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

完整重同步用于处理初次复制情况:完整步骤和 sync 命令的步骤基本一样.

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

Redis|*|#8211;主从复制_Sync,PSYNC)_redis怎么读

部分重同步的实现

部分重同步功能包含三个部分:

主服务器的复制偏移量和从服务器的复制偏移量.

主服务器的复制积压缓冲区.

服务器的运行 ID.

复制偏移量

执行复制的双方——主服务器和从服务器会分别维护一个复制偏移量.

主服务器每次向从服务器传播 N 个字节时,就将自己的复制偏移量 + N.

从服务器每次收到主服务器传来的 N 个字节的数据时,就将自己的复制偏移量 + N.

对比主从服务器的复制偏移量可知:

如果主从服务器的复制偏移量相等,则说明主从服务器数据一致;

相反,如果主从服务器两者的偏移量不等,则说明主从服务器中的数据不一致.

复制积压缓冲区

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

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

所以呢,主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令,并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量.

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

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

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

其中 second 为从服务器断线后重新连接上主服务器所需的平均时间(单位秒).

write_size_per_second 是主服务器平均每秒产生的写命令数据量.

对应redis-service.conf的配置项repl-backlog-size

服务器运行 ID

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

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

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

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

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

心跳检测

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

REAPCONF ACK <replication_offset>  

其中 replication_offset 是代表从服务器当前的复制偏移量.

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

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

辅助实现 min-slaves 选项.

检测命令丢失.

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

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

辅助实现 min-slaves 选项

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

比如,如果我们向主服务器提供以下设置:

min-slaves-to-write 3
min-slaves-max-lag 10

检测命令丢失

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

以上就是土嘎嘎小编大虾米为大家整理的相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦!!

版权声明:倡导尊重与保护知识产权。未经许可,任何人不得复制、转载、或以其他方式使用本站《原创》内容,违者将追究其法律责任。本站文章内容,部分图片来源于网络,如有侵权,请联系我们修改或者删除处理。

编辑推荐

热门文章