微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】

微服务框架

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】

分布式缓存

文章目录

      • 微服务框架
      • 分布式缓存
      • 42 Redis 主从
        • 42.2 数据同步原理【全量同步】
          • 42.2.1 数据同步原理
          • 42.2.2 总结

42 Redis 主从

42.2 数据同步原理【全量同步】

42.2.1 数据同步原理

【数据同步原理】

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

解释:

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第1张图片

左边是主,右边是从

首先第一步上来的时候,slave 需要执行replicaof 命令,与主节点建立连接

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第2张图片

连接一旦建立,从节点就可以向主master 发起请求了

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第3张图片

这个时候master 会问slave : “ 你… 是第一次来嘛?”【即做一次判断】

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第4张图片

如果不是第一次,那从缺多少,主就给多少

如果是第一次,先给数据版本信息

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第5张图片

接着slave 就会保存这个版本信息

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第6张图片

OK,到这里第一阶段就算完成了,即master 与 slave 之间完成了一次初步的沟通

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第7张图片

接着master 会去执行 bgsave , 生成RDB

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第8张图片

生成完成后,将RDB 文件发送给slave 从节点

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第9张图片

从节点拿到 RDB 后

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第10张图片

这样就完成 了主从节点数据之间的基本 一致

其实在master 生成RDB 的过程中,它还会去接收处理很多新的请求,即会有新的数据写入

新的数据并没有发给slave ,那咋办??

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第11张图片

master 会把这些 命令记下来【repl_baklog 是一个内存的缓冲区】

到这里第二阶段也就完成 了

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第12张图片

OK,进入第三阶段

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第13张图片

master 把缓冲区中的命令发送给从节点,slave 就去跑跑跑,当然这期间,master 又会产生新的, 从节点就会不断的跑跑跑‘【确保两者之间永远一致】

妙啊!!

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第14张图片

这就是第三阶段,这样就完成了 数据的同步

master如何判断slave是不是第一次来同步数据?这里会用到两个很重要的概念:

  • Replication Id:简称replid,是数据集的标记,id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replid
  • offset:偏移量,随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset,说明slave数据落后于master,需要更新。

因此slave做数据同步,必须向master声明自己的replication id 和offset,master才可以判断到底需要同步哪些数据

【思考】master如何判断slave节点是不是第一次来做数据同步?

这样一来,过程就可以完善一下了

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第15张图片

在slave 向 master 发起数据同步请求时,就需要带上

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第16张图片

这两个东西,所以就可以判断id 是否一致【id 只要不一致,就一定是第一次】

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第17张图片

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第18张图片

如果确定是第一次,那master 就要返回自己的信息给从节点了

接着slave 就会赶紧把这信息记录下来 作为自己的id ,以后再来 就可以很容易的判断是不是第一次了,且可以根据offset 来判断同步进度

看看日志

微服务框架 SpringCloud微服务架构 分布式缓存 42 Redis 主从 42.2 数据同步原理【全量同步】_第19张图片

牛逼!!!!!!

佩服Redis 设计师,真的大佬

42.2.2 总结

简述全量同步的流程?

  • slave节点请求增量同步
  • master节点判断replid,发现不一致,拒绝增量同步
  • master将完整内存数据生成RDB,发送RDB到slave
  • slave清空本地数据,加载master的RDB
  • master将RDB期间的命令记录在repl_baklog,并持续将log中的命令发送给slave
  • slave执行接收到的命令,保持与master之间的同步

你可能感兴趣的:(微服务,分布式,redis,缓存)