1. 全栈程序员必看首页

redis主从复制_kafka主从复制

全栈程序员-用户IM • • 未分类

redis主从复制_kafka主从复制一把LOL的时间让你了解Redis的主从复制机制,Redis超详细主从复制解析，值得收藏！

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

⭐️写在前面

在这里插入图片描述

文章目录

在这里插入图片描述

⭐️1 主从复制

⭐️1.1 主从复制简介

了解主从复制之前，你的redis是否高可用？

如果我们的redis是单机的就会存在一定的风险

问题1：机器故障

  • 现象：硬盘故障，系统崩溃
  • 本质：数据丢失，很可能对业务造成灾难性打击

问题2：容量瓶颈

  • 现象：内存不足，从16G升级到64G，从64G升级到128G，无限升级内存
  • 本质：没钱，硬件条件跟不上
  • 结论：硬件的发展速度直接决定软件的技术，内存上不去，redis存储的数据量就很低，这样下去就会放弃redis

因此：

为了避免Redis服务器故障造成重大损失，我们准备多台服务器，互相来南通。将数据复制多个副本保存在不同的服
务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现
Redis的高可用，同时实现数据冗余备份

1.1.1多台服务器连接方案

我们让主服务器专门负责写数据，下面的从属计算机专门负责读数据，数据由主服务器提供给从属服务器，这样的话我们的数据有多个备份，也就实现了高可用

在这里插入图片描述
提供数据方：master

  • 我们可以称之为：主服务器，主节点，主库，主客户端

接收数据方：slave

  • 我们可以称之为：从节点，从库，从客户端

需要解决的问题

  • 数据同步：master的数据复制到slave

这样，我么从主服务器向从服务器复制数据，就是主从复制

⭐️1.2 主从复制

主从复制即：将master中的数据及时，有效的复制到slave中

特征：一个master可以拥有多个slave，一个slave只对应一个master

职责：

  • master
    • 写数据
    • 执行写操作时，将出现变化的数据自动同步到slave
  • slave
    • 读数据
可能会有人说：master的压力过大崩溃了怎么办，不要着急，我们后面会说到的的哨兵模式就是为了解决这一问题的
除此之外，当我们的master压力很大时，我们可以在某一个slave上给其追加从属服务器，例如下图，所以说，
master和slave是一种相对的概念

在这里插入图片描述
在这里插入图片描述

⭐️1.2.1主从复制的作用

  • 读写分离：master写，slave读。提高服务器的读写负载能力

  • 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量

  • 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复

  • 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式

  • 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

⭐️1.3 主从复制工作流程

主从复制过程大体可以分为3个阶段

  1.建立连接阶段（即准备阶段）

  2.数据同步阶段

  3.命令传播阶段

流程图解：
在这里插入图片描述

⭐️1.3.1 建立连接阶段步骤

建立slave到master的连接，使master能够识别slave，并保存slave端口号

在这里插入图片描述

步骤1：设置master的地址和端口，保存master信息

步骤2：建立socket连接

步骤3：发送ping命令（定时器任务）

步骤4：身份验证

步骤5：发送slave端口信息

至此，主从连接成功！

最终状态：

slave:

  • 保存master的地址与端口

master：

  • 保存slave的端口

总体：

  • 之间创建了连接的socket

在这里插入图片描述

⭐️1.3.1.1 主从连接的三种方式（slave连接master）

方式一：客户端发送命令
  • slaveof masterip masterport
方式二：启动服务器参数
  • redis-server -slaveof masterip maxterport
方式三：服务器配置（主流方式，建议使用）
  • slaveof masterip masterport
主从断开连接
  • 客户端发送命令
  • slaveof no one

下面对这三种方式分别进行操作演示

我们以6739端口的服务器为master,以6380端口的服务器为slave进行操作

进入6379服务器关掉守护进程配置与日志

在这里插入图片描述
6380服务器同样
在这里插入图片描述
启动master及slave
在这里插入图片描述
在这里插入图片描述

方式一：在slave端发送连接请求

在这里插入图片描述
我们查看slave的日志信息
在这里插入图片描述

发现连接过程中master与slave的信息已经同步

我们测试一下在master中set一个数据并在slave看能不能获取

在这里插入图片描述

方式一成功

方式二：启动slave时直接与master进行连接

在这里插入图片描述
我们测试一下在master中set一个数据并在slave看能不能获取
在这里插入图片描述
方式二成功

现在上面这样种方式都不是主流方式，主流的是直接在配置文件中进行设置

方式三：设置配置文件

修改slave的配置文件，添加如箭头所指的配置

在这里插入图片描述
添加完毕我们启动slave，并查看信息是否同步
在这里插入图片描述

方式三成功

在这里插入图片描述

⭐️1.3.2 数据同步阶段步骤

在slave初次连接master后，会复制master中的所有数据到slave，数据同步阶段包括全量复制与部分复制

也就是将slave的数据库状态更新成master当前的数据库状态

在这里插入图片描述

步骤1：请求同步数据

步骤2：创建RDB同步数据

步骤3：恢复RDB同步数据（以上阶段为全量复制）

步骤4：请求部分同步数据（同步的是缓冲区中的指令引起的数据）

步骤5：恢复部分同步数据（此过程会执行bgrewriteaof重写操作，恢复数据，步骤4，步骤5阶段为部分复制）

至此数据同步工作完成

全量复制

  • 获取发指令的那一刻开始原来的所有数据

部分复制

  • 恢复进行RDB过程中对应的所有数据

最终状态：

slave：

  • 具有master端全部数据，包含RDB过程接收的数据

master

  • 保存slave当前数据同步的位置

总体

  • 之间完成了数据克隆

⭐️1.3.2.1 数据同步阶段master说明

  • 如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master堵塞，影响业务正常执行

  • 复制缓冲区大小设置不合理，会导致数据溢出，如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态

在这里插入图片描述

我们可以通过配置修改缓冲区的大小
  • repl-backlog-size lmb
master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令
和创建复制缓冲区

⭐️1.3.2.2 数据同步阶段slave说明

- 为避免slave进行全量复制，部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务

  - slave-serve-stale-data yes|no（当主服务器挂掉时是否提供过期数据）

- 数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送命令

- 多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果master带宽
  不足，因此数据同步需要根据业务请求，适量错峰

- slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点是master，也是slave，注意使用
  树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟较大，数据一致性变差，
  应谨慎选择

在这里插入图片描述

⭐️1.3.2.3 命令传播阶段步骤

当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的状态，同步的动作称为命令传播

一句话就是实时保持主从之间的数据同步

命令传播阶段的部分复制

  • 命令传播阶段出现了断网情况
    • 网络闪断闪连 忽略
    • 短时间网络中断 部分复制
    • 长时间网络中断 全量复制
  • 部分复制的三个核心要素
    • 服务器的运行id（run id）
    • 主服务器的复制偏移量积压缓冲区
    • 主从服务器的复制偏移量

下面我们对这三个核心要素分别进行叙述

⭐️1.3.2.4 服务器运行ID（runid）

概念：服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id

组成：运行id由40位字符组成，是一个随机的十六进制字符

作用：运行id被用于在服务器间进行传输，识别身份

  • 如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别

实现方式：

  • 运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发送给slave，slave保存此ID，通过info Server命令可以查看节点的runid

我们输入info server命令查看服务器运行id

在这里插入图片描述

⭐️1.3.2.5 主服务器的复制偏移量积压缓冲区

概念：复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命令，每次传播命令，master都会将传播的命令记录下来毛病存储在复制缓冲区

复制缓冲区默认数据存储空间大小是1M，由于存储空间大小是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列

由来：每台服务器启动时，如果开启有AOF或被连接为master节点，即创建复制缓冲区

作用：用于保存master收到的所有指令（仅影响数据变更的指令，例如set，select）

数据来源：当master收到主用户端的指令时，除了将指令执行，会将该指令存储到缓冲区中

在这里插入图片描述
复制缓冲区内部工作原理

当master接到一个指令，例如set name itheima,它会把指令拆解开放进复制缓冲区，指令在缓冲区的形式为

在这里插入图片描述
为了区分各个字符，每个字符都有自己的编号

在这里插入图片描述
所以复制缓冲区由两部分组成

  • 偏移量
  • 字节值

工作原理

  • 通过offset区分不同的slave当前数据传播的差异

⭐️1.3.2.6 主从服务器的复制偏移量（offset）

概念：一个数字，描述复制缓冲区中的指令字节位置

分类：

  • master复制偏移量：记录发送给所有slave的指令字节对应的位置（多个）
  • slave复制偏移量：记录slave接收master发送过来的指令字节对应的位置（一个）

数据来源

  • master端：发送一次记录一次
  • slave端：接受一次记录一次

作用：同步信息，对比master与slave的差异，当slave断线后，恢复数据使用

在这里插入图片描述

⭐️1.3.3 数据同步+命令传播阶段步骤

这部分比较复杂，大家可以看着流程图和我的叙述进行理解

在这里插入图片描述

现在是数据同步阶段：

首先进行全量复制

slave向master发送指令，请求数据同步，执行psync2  <runid>  <offset>指令，此时slave并不知道master的
runid与offset，故发送的指令形式为psync2    ?    -1

master收到来自slave的指令，执行bgsave生成RDB文件，记录当前的复制偏移量offset，接收的offset值为-1

因为接收到offset=-1，故master采用全量同步，将会把所有信息都发送过去，顺带自己的runid与offset，发送的
指令为+FULLRESYNC runid offset

slave收到+FULLRESYNC，保存master的runid和offset，清空当前全部数据，通过socket接收RDB文件，恢复RDB
数据，至此全量复制结束

接下来进行部分复制

期间master接收客户端命令后（这里的期间指全量复制期间），offset发生了变化，全量复制之后slave会发送指令
请求master将剩余的信息进行发送，发送的命令是psync2 runid offset

接下来进入命令传播阶段：

master接收到psync2 指令后，

  • 先判断runid是否匹配（不匹配证明不是一台机器），然后判定offset是否在复制缓冲区中，如果runid或offset有一个不满足，就会再次执行全量复制

  • 如果runid或offset检验通过

    • slave发送的offset与master缓冲区中的offset相同，则忽略，证明全量复制期间没有其他数据进入缓冲区
    • slave发送的offset与master缓冲区中的offset不相同，则发送+CONTINUE offset指令，通过socket发送复制缓冲区中slave发送的offset到master本身的offset的数据

slave收到master发送的+COUNTINUE指令，保存master的offset，接收信息后，执行bgrewriteaof对部分复制的指令进行重写，恢复数据，随后因为心跳机制的原因，slave周期性的向master发送请求以汇报自己的offset,获取最新的指令变更

⭐️1.3.3.1 心跳机制

传播阶段master与slave之间的联系是反复进行的，而这种反复进行的机制是由心跳包来控制的
  • 进入命令传播阶段，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线
  • master心跳
    • 指令：PING
    • 周期：由repl-ping-slave-period决定，默认10秒
    • 作用：判断slave是否在线
    • 查询：INFO replication
      • 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常
  • slave心跳任务
    • 指令：REPLCONF ACK[offset]
    • 周期：1秒
    • 作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
    • 作用2：判断master是否在线

在这里插入图片描述
如果lag不为1或者0，证明可能在ping某些时候可能丢过

心跳阶段注意事项

  • 当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步操作
    • min-slaves-to-write 2
    • min-slaves-max-lag 8
    • slave数量少于2，或者所有slave的延迟都大于等于8秒时，强制关闭master写功能，停止数据同步
  • slave数量是由slave发送REPLCONF ACK命令做确认
  • slave延迟是由slave发送REPLCONF ACK命令做确认

14 主从复制工作流程完整图示

在这里插入图片描述

在这里插入图片描述

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

发布者：全栈程序员-用户IM，转载请注明出处：https://javaforall.cn/170325.html原文链接：https://javaforall.cn

【正版授权，激活自己账号】： Jetbrains全家桶Ide使用，1年售后保障，每天仅需1毛

【官方授权 正版激活】： 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

赞 (0)
全栈程序员-用户IM全栈程序员-用户IM
0 0


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号