主从模式详解

指挥部在下面

于 2023-09-14 22:26:02 发布

阅读量1k

点赞数

分类专栏： redis 文章标签： redis 缓存数据库

本文链接：https://blog.csdn.net/weixin_61427900/article/details/132891955

版权

redis 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

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

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

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

什么是主从模式

引入多个服务器（多个节点）分别部署redis-server进程，在若干个redis节点中，其中一个是“主”节点，其他的是“从”节点。从节点的数据要跟随主节点变化，数据要和主节点保存一致。

由于从节点的数据时刻和主节点保持一致，因此其他客服端从从节点读取的数据，和从主节点读取的数据，没有区别。后续有客服端来读取数据，就可以从上述节点中，随机挑选一个节点，给客服端提供服务。

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

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

如果从节点挂了，是否有影响？

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

如果主节点挂了，是否有影响？

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

如果整个redis集群挂了，怎么办？

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

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

redis主从结构

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

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

配置redis主从结构

将主节点的的配置信息负责到从节点中
:::tips
cd redis-conf/
cp /etc/redis.conf ./slave1.conf
cp /etc/redis.conf ./slave2.conf
:::
在从节点的配置文件中修改redis端口和运行后台运行
:::tips
vim slave1.conf
vim slave1.conf
:::
启动两个从节点
:::tips
redis-server ./slave1.conf
redis-server ./slave2.conf
:::
配置两个从节点，以6379端口的redis-server为主节点

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

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

查看主从结构信息

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

主节点

从节点

断开/修改主从结构

断开主从结构

使用slaveof no one命令，断开主从复制关系。

从节点断开主从关系，原有的数据不会丢失，但是后续主节点如果针对数据做出修改，从节点就无法自动同步数据。

修改主从结构

slaveof命令还可以实现切换主节点操作，执行slaveof [newMasterIp] [newMasterPort]命令即可。
认另外一个从节点为主节点
虽然6381端口的redis服务器，有了从节点，但仍然是6379的从节点

通过slaveof修改了主从结构，此处的修改是临时性的，如果重新启动了redis服务器，仍然会按照最初配置文件中设置的内容来建立主从结构。

传输延迟

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

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

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

拓扑结构

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

一主一从结构

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

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

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

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

一主多从结构

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

树状主从结构

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

主从复制原理

主从复制过程

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

数据同步psync

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

replicationid 复制id

由主节点生成（主节点启动的时候会生成，从节点晋升成主节点也会生成），即使同一个主节点，每次重启，生成的replicationid都是不同的。当从节点和主节点建立了复制关系，就会从主节点这边获取到replicationid。我们可以通过info replication获取当前replicationid的值。

假设主节点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运行流程

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

什么时候进行全量复制

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

什么时候进行部分复制

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

全量复制流程

全量复制流程图

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

无硬盘模式

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

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

部分复制

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

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

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

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

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

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