Redis主从数据同步原理的详解、以及优化方案

数据同步原理

1、全量同步的讲解:

主从第一次同步是全量同步

  • 第一阶段:

第一次连接的时候,slave需要执行一次replicaof命令来建立连接,连接一旦建立slave就可以向master发送请求,master会判断是不是第一次来,如果是第一次来,master向slave数据的版本信息。

  • 第二阶段:

master执行bgsave,生成RDB文件。然后发送RDB文件·1发送给slave。slave清空本地的数据,加载RDB文件(此时slave中的内容和master中的内容并不完全一致,因为在执行bgsave的时候,master还会执行本该执行的命令)。然后master记录RDB期间的所有命令,存在master的缓冲区中(repl_baklog)。

  • 第三阶段:

master发送repl_baklog中的命令。slave执行接收到的命令。

全量同步其实是比较消耗性能的,因为生成RDB的文件比较慢。

2、master是怎样知道这是第一次同步的?

这里会用到两个重要的概念

第一个概念:Replication Id:简称replid,是数据集的标记,id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replid

第二个概念:offset:偏移量,随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset,说明slave数据落后于master,需要更新。

知道这两个概念以后就可以将上面的第一阶段换个表达方式:

slave发送请求的时候就需要带上replid offset ,slave在成为slave之前是master,所以他就有自己的psyncid,然后来以判断肯定就不一致,然后master就会返回master的replid和offest给slave,然后slave进行替换。

3、简述全量同步的流程:

  1. slave节点请求增量同步
  2. master节点判断replid,发现不一致,拒绝增量同步
  3. master将完整的内存数据生成RDB,发送RDB到slave
  4. slave清空本地的数据,加载master的RDB
  5. master将RDB期间的命令记录在repl_baklog,并持续将log中的命令发送给slave。

4、增量同步的讲解:

主从第一次同步时全量同步,但如果slave重启后同步,则执行增量同步

这里的offest是记录在repl_baklog中的哪个部分呢?

repl_baklog的本质是一个数组,(是一个环形数组)数组在记录慢之后会从零开始进行覆盖的记录,master记录的最新的位置在哪里 那个位置就是master的offest,同时slave也会做数据同步 它同步到哪个位置,那个位置就是slave的offest。它们之间的距离就是将要做同步的数据。

只要他们两个的差距别超过这个数组的上限,就可以将其中的数据进行同步做增量同步。

5、repl_backlog原理:

master怎么知道slave与自己的数据差异在哪里呢?

这就要说到全量同步时的repl_baklog文件了。

这个文件是一个固定大小的数组,只不过数组是环形,也就是说角标到达数组末尾后,会再次从0开始读写,这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset,包括master当前的offset,和slave已经拷贝到的offset:

slave与master的offset之间的差异,就是salve需要增量拷贝的数据了。

随着不断有数据写入,master的offset逐渐变大,slave也不断的拷贝,追赶master的offset:

直到数组被填满:

此时,如果有新的数据写入,就会覆盖数组中的旧数据。不过,旧的数据只要是绿色的,说明是已经被同步到slave的数据,即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

但是,如果slave出现网络阻塞,导致master的offset远远超过了slave的offset:

如果master继续写入新数据,其offset就会覆盖旧的数据,直到将slave现在的offset也覆盖:

棕色框中的红色部分,就是尚未同步,但是却已经被覆盖的数据。此时如果slave恢复,需要同步,却发现自己的offset都没有了,无法完成增量同步了。只能做全量同步。

repl_baklog大小有上限,写满后会覆盖最早的数据。如果slave断开的时间过长,导致无法实现增量同步,只能再次全量同步。(这个问题不能完全解决)

6、优化Redis主从集群:

  • (提高全量同步的性能):在master中启用repl-diskless-sync yes 启用无磁盘复制,避免全量同步时候的磁盘IO。
  • (提高全量同步的性能):Redis
  • (减少全量同步次数):适当提高repl_baklog的大小,发现slave宕机时尽快实现
  • 限制一个master上的slave节点数量,如果实在太多slave,则可以采用主-从-从链式结构,减少master压力。

7、总结:

简述全量同步和增量同步区别?

  • 全量同步:master将完整的内存数据生成RDB,发送RDB到slave。后续命令则记录在repl_baklog逐个发送给slave
  • 增量同步:slave提交自己的offest到master,master获取repl_baklog中从offest之后的命令给slave

什么时候执行全量同步?

  • slave节点第一次连接master节点时
  • slave节点断开时间太久,repl_baklog中的offset已经被覆盖时

什么时候执行增量同步?

  • slave几点断开又恢复,并且在repl_baklog中找到offset时。
相关推荐
红肤色6 分钟前
【网络安全基础】CentOS 7超详细安装教程(含镜像)
linux·运维·服务器·安全·网络安全·centos
程序猿(雷霆之王)28 分钟前
Linux——冯 • 诺依曼体系结构&操作系统初识
linux·运维·服务器
数据智能老司机2 小时前
CockroachDB权威指南——SQL调优
数据库·分布式·架构
数据智能老司机2 小时前
CockroachDB权威指南——应用设计与实现
数据库·分布式·架构
数据智能老司机2 小时前
CockroachDB权威指南——CockroachDB 模式设计
数据库·分布式·架构
数据智能老司机21 小时前
CockroachDB权威指南——CockroachDB SQL
数据库·分布式·架构
数据智能老司机1 天前
CockroachDB权威指南——开始使用
数据库·分布式·架构
松果猿1 天前
空间数据库学习(二)—— PostgreSQL数据库的备份转储和导入恢复
数据库
Kagol1 天前
macOS 和 Windows 操作系统下如何安装和启动 MySQL / Redis 数据库
redis·后端·mysql
无名之逆1 天前
Rust 开发提效神器:lombok-macros 宏库
服务器·开发语言·前端·数据库·后端·python·rust