主从模式详解

主从模式是分布式系统中,多个服务器部署redis的一种方式。
分布式系统主要是解决“单点问题”。

如果某个服务器程序,只有一个节点(只有一个物理服务器,来部署服务器程序)。存在可用性问题,如果这个机器挂了,意味着服务中断。并且单个服务器性能不高,支持的并发量有限。

而在分布式系统中,通过多个服务器来部署redis服务,从而构成一个redis集群。此时就可以让这个集群给整个分布式系统中提供服务,提供更稳定,更高效的数据存储功能。

什么是主从模式

引入多个服务器(多个节点)分别部署redis-server进程,在若干个redis节点中,其中一个是“主”节点,其他的是“从”节点。从节点的数据要跟随主节点变化,数据要和主节点保存一致。
image.png
由于从节点的数据时刻和主节点保持一致,因此其他客服端从 从节点读取的数据,和从主节点读取的数据,没有区别。后续有客服端来读取数据,就可以从上述节点中,随机挑选一个节点,给客服端提供服务。

如果我修改了从节点的数据,能否把从节点的数据同步到主节点?

redis主从模式中,从节点的数据不允许修改,只能读取

如果从节点挂了,是否有影响?

此时可以从主节点或者其他从节点读取数据

如果主节点挂了,是否有影响?

从节点只能读取数据,如果需要写数据,就无法写入,可用性视乎不是很理想。并且一般不搞多个主节点,因为相互之间进行数据同步,非常麻烦

如果整个redis集群挂了,怎么办?

考虑到更高的可用性,就需要把这些机器放到不同的机房中,异地多活。

主从模式,主要针对“读操作”进行并发量&可用性的提高。而写操作,依赖于主节点,主节点又不能搞多个,所以可用性&并发量并没有得到提升。

redis主从结构

redis主从结构,需要启动多个redis服务器,正常来说,每个redis服务器,应该在单独的主机上,但是我只有一个云服务器,因此只能在一个云服务器上,运行多个redis-server进程。

需要保证多个redis-server的端口是不同的,本来redis-server默认的端口是6379,此时新启动的redis-server不能再使用6379

配置redis主从结构

  1. 将主节点的的配置信息负责到从节点中
    :::tips
    cd redis-conf/
    cp /etc/redis.conf ./slave1.conf
    cp /etc/redis.conf ./slave2.conf
    :::

  2. 在从节点的配置文件中修改redis端口和运行后台运行
    :::tips
    vim slave1.conf
    vim slave1.conf
    :::
    端口要不相同
    开启后台进程

  3. 启动两个从节点
    :::tips
    redis-server ./slave1.conf
    redis-server ./slave2.conf
    :::

  4. 配置两个从节点,以6379端口的redis-server为主节点

image.png
image.png

  1. 此时在主节点插入数据,从节点就可以访问到,并且从节点无法添加/修改数据

主节点
从节点获取数据
从节点无法添加/修改数据

查看主从结构信息

通过info replication命令查看当前redis节点的相关状态

  • 主节点

image.png

  • 从节点

image.png

断开/修改主从结构

断开主从结构

使用slaveof no one命令,断开主从复制关系。
image.png
从节点断开主从关系,原有的数据不会丢失,但是后续主节点如果针对数据做出修改,从节点就无法自动同步数据。
image.png
image.png

修改主从结构

slaveof命令还可以实现切换主节点操作,执行slaveof [newMasterIp] [newMasterPort]命令即可。
认另外一个从节点为主节点
虽然6381端口的redis服务器,有了从节点,但仍然是6379的从节点
image.png
通过slaveof修改了主从结构,此处的修改是临时性的,如果重新启动了redis服务器,仍然会按照最初配置文件中设置的内容来建立主从结构。

传输延迟

主从节点一般部署在不同机器上,主节点和从节点的网络通信是采用tcp协议,tcp内部支持nagle算法(默认开启),该算法针对小的tcp数据包进行合并,减少了包的个数。

  • 开启以后,会增加tcp传输延迟,节省网络带宽
  • 关闭以后,就会减少tcp传输延迟,增加了网络带宽

在redis的配置文件中,repl-disable-tcp-nodelay参数用于主从同步通信过程中,选择no关闭tcp的nagle算法,减少传输时延;选择yes则开启tcp的nagel算法,节省网络带宽。
image.png

拓扑结构

redis进行主从复制的拓扑结构可以支持单层或多层复制关系,根据拓扑复杂性可以分为三种:一主一从,一主多从,树状主从结构。

一主一从结构

image.png

如果写数据请求太多,就会给主节点造成一些压力

可以通过关闭主节点的aof,只开启从节点的aof,缓解压力。

如果主节点挂了,不能让主节点自动重启,如果自动重启,此时没有aof文件,就会丢失数据,进一步主从同步,连同从节点的数据也给删除了

改进方法:当主节点挂了,就让主节点从从节点获取到aof文件,再启动

一主多从结构

image.png
在实际开发中,读请求远高于写请求。一主多从结构可以把读命令负载均衡到不同的从节点上分担压力,同时一些耗时的读命令还可以指定一台专门的从节点来执行。
但是由于从节点较多,主节点完成写请求,同步给从节点需要耗费大量的网络带宽。

树状主从结构

image.png
树状的主从结构可以减少主节点同步压力,只是同步的延时更长了。

主从复制原理

主从复制过程

image.png

  • 权限验证:如果主节点设置requirepass参数,则需要密码验证,从节点通过配置masterauth参数设置密码,如果验证失败,则从节点的复制将会停止。
  • 同步数据集:对于首次建立复制的场景,主节点会把当前所有数据同步给从节点
  • 命令持续复制:当从节点复制了主节点的所有数据以后,针对之后的修改命令,主节点会持续的把命令发送给从节点,从节点执行修改命令,保证主从数据的一致性

数据同步psync

psync不需要咱们手动执行,redis服务器会在建立好主从同步关系之后,自动执行psync。从节点负责执行psync,从主节点这边拉取数据。
语法格式:psync replicationid offset

replicationid 复制id

由主节点生成(主节点启动的时候会生成,从节点晋升成主节点也会生成),即使同一个主节点,每次重启,生成的replicationid都是不同的。当从节点和主节点建立了复制关系,就会从主节点这边获取到replicationid。我们可以通过info replication获取当前replicationid的值。
image.png
假设主节点A,从节点B。主节点A生成replid,从节点获取到A的replid。当A和B通信过程中发生网络抖动,B可能误认为A挂了,B就会自己成为主节点(给自己生成一个replid)。此时B还会记得之前旧的replid,即用replid2存储。后续网络稳定了,B就可以根据replid2重新回到A的怀抱。

offset偏移量

  • 主节点的offset:主节点会收到很多修改操作的命令,将这些修改命令所占字节进行累加得到
  • 从节点的offset:描述了现在从节点数据同步到哪里了,如果从节点的偏移量和主节点的偏移量一致,就是同步了,“赶上直播了”

从节点每秒钟上报自身的复制偏移量给主节点
psync可以从主节点获取全量数据,也可以获取一部分数据。主要是看offset怎么写,
offset写作-1,就是获取全量数据,offset写作具体的正整数,则是从当前偏移量位置往后获取。获取全量数据是最稳妥的,但是也是比较低效。如果从节点之前已经从主节点复制过一部分数据,就只需要将之前没有复制过的数据复制过来即可。

psync运行流程

image.png
并不是从节点索要哪部分,主节点就会给哪部分,主节点会自行判定,看当前是否方便给部分数据,不方便就给全量。

什么时候进行全量复制

  1. 首次和主节点进行数据同步
  2. 主节点不方便进行部分复制

什么时候进行部分复制

从节点之前已经从主节点复制过数据,因为网络抖动或者从节点重启,从节点需要重新从主节点同步数据,此时看能不能只同步一小部分(大部分数据都是一致)

全量复制流程

全量复制流程图
image.png

  1. 从节点发送psync命令给主节点进行数据同步,由于是第一次进行复制,从节点没有主节点的replicationidoffset,所以发送psync ? -1获取全量数据。
  2. 主节点根据命令,解析出要进行全量复制,回复+FULLRESYNC响应
  3. 从节点接收主节点的运行信息进行保存,如ip,port
  4. 主节点执行bgsave进行RDB文件的持久化(rdb是二进制格式,节省空间),不使用原有的rdb文件,而是重新生成rdb快照,因为已有的rdb文件可能和当前最新的数据存在较大差异
  5. 主节点发送RDB文件给从节点,从节点保存RDB数据到本地磁盘
  6. 在主节点生成rdb文件和传输rdb文件的过程中,还会收到很多新的修改操作。新修改的数据也必须同步给从节点,将新修改的数据放入缓冲区,当从节点收完主节点发来的rdb数据后,主节点就会把缓冲区的数据补发给从节点,补发的数据仍然按照二进制格式追加写入到收到的rdb文件中,保持主从一致性。
  7. 从节点清空自身原有的旧数据
  8. 从节点加载rdb文件得到和主节点一致的数据
  9. 如果从节点开启了aof,在上述加载数据过程中,从节点就会产生很多aof日志,会存在一定的冗余信息,因此针对aof日志使用bgrewriteaof重写,进行整理。

无硬盘模式

  1. 在全量复制的第4个步骤中,主节点需要生成rdb文件,再传输给从节点。而“无硬盘模式”不进行bgsave生成rdb文件的过程,直接将数据传输给从节点,节省了一系列读写硬盘的操作
  2. 从节点之前需要先收到rdb数据,写入硬盘,然后再加载。而“无硬盘模式”省略了这个过程,直接把收到的数据进行加载。

虽然引入“无硬盘模式”省去了一系列读写硬盘操作,但是全量复制的整个过程仍然比较重量,相比网络传输而言,读写硬盘是个小头。

部分复制

从节点要从主节点进行全量复制,开销很大,有些时候,从节点本身已经持有主节点的大部分数据,这个时候就不太需要进行全量复制了。例如,网络抖动,主节点最近修改的数据无法及时同步过去,而网络抖动,一般是暂时性的,当从节点和主节点重新建立连接以后,就需要进行数据同步。
部分复制流程图
image.png

  1. 主从节点之间出现网络中断,如果超过repl-timeout时间,主节点会认为从节点故障并中断复制连接
  2. 主从连接中断期间主节点依旧响应命令,但是这些复制命令都因网络中断无法及时发送给从节点,所以暂时将这些命令写入复制积压缓冲区

积压缓冲区:由数组构成的一个循环队列,记录的总量有限,随着时间推移,会把前面的数据逐渐覆盖掉。

  1. 当主从节点网络恢复后,从节点再次连上主节点
  2. 从节点将之前保存的replicationidoffset作为psync的参数发送给主节点,请求进行部分复制。

replicationid描述”数据来源“,offset描述”数据的复制进度“

:::warning
主节点会先判定replicationid,如果和自己的id不一样,说明以前不具备主从关系,直接全量复制。如果replicationid一样,再判定offset,如果从节点的进度再当前的积压缓冲区之内,进行部分复制;如果当前从节点的进度超出积压缓冲区的范围,继续全量复制。
:::

  1. 主节点接到psync请求后,进行必要验证,随后根据offset去复制积压缓冲区查找合适的数据,并响应+CONTINUE给从节点。
  2. 主节点将需要让从节点 同步的数据发送给从节点,最终完成一致性

实时复制

全量复制是从节点刚连上主节点之后,进行的数据初始化工作;部分复制是全量复制的特殊情况,是对全量复制的优化,目的和全量复制一样。而实时复制是从节点已经和主节点同步好了数据,但是之后,主节点会不断收到新的修改数据的请求,需要同步给从节点。

怎么进行实时复制

从节点和主节点之间建立TCP长连接,然后主节点把自己收到的修改数据的请求,通过上述连接,发送给从节点再根据这些修改请求,修改内存中的数据

上述过程正常来说,延时比较短,但是如果是多级从节点的树形结构,延时也会上升

在进行实时复制的时候,需要保证连接处于可用状态。依靠”心跳包“机制来检查

  • 主节点:默认每隔10s给从节点发送一个ping命令,从节点收到就返回pong。超时阈值默认是60s
  • 从节点:默认每隔1s就给主节点发送一个特定请求,上报当前从节点复制数据的进度,即offset

主从复制的问题

最大的问题是在主节点上,当主节点挂了,虽然还能够提供读操作,但是从节点无法自动升级成主节点,替换原有主节点对应的角色,需要程序员手动恢复主节点。而自动替换主节点需要redis的哨兵机制。文章来源地址https://uudwc.com/A/aYLAy

原文地址:https://blog.csdn.net/weixin_61427900/article/details/132891955

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请联系站长进行投诉反馈,一经查实,立即删除!

h
上一篇 2023年09月15日 03:30
linux驱动开发--day1(驱动、内核模块及相关命令、内核模块传参)
下一篇 2023年09月15日 03:30