[大数据] redis主从复制

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 大数据 -> redis主从复制 -> 正文阅读

[大数据]redis主从复制

一、主从复制的概念：

一、什么是主从复制：
在这里插入图片描述

主从复制，是指将一台Redis主节点服务器的数据，复制到其他的Redis从节点服务器。

主节点称为(master/leader)，从节点称为(slave/follower)；
1.数据的复制是单向的，只能由主节点到从节点。

2.Master（主节点）以写为主，Slave 从节点以读为主。

3.默认情况下，每台Redis服务器都是主节点，如果想让其成为从节点，需要对其进行配置；

且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

总结就是：主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性。

在这里插入图片描述

二、为什么使用Redis主从复制：

假设只有一台Redis服务，这就是单机模式。

第一个问题是当服务器宕机，数据丢失，如果数据很重要，那会造成很大的损失。

第二个问题是内存问题，一台服务器的内存是会达到峰值的，一台服务器也不可能无限升级。

针对上述问题，我们需要准备多台服务器，配置主从复制。将数据保存在多台服务器上，并且保证每台服务器的数据是同步的。即使有一台服务器宕机，也不影响用户的使用。redis可以继续实现高可用，同时实现数据的冗余备份。

三、使用Redis主从复制的作用：

1，数据冗余：主从复制实现了数据的热备份，这也是持久化实现的另一种方式。

2，故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3，读写分离：master服务主要用来写，slave服务主要用来读数据。可以提高服务器的负载能力，可以根据需求的变化，添加从节点的数量。

4，负载均衡：同时配合读写分离，由主节点提供写服务，从节点提供读服务，分担服务器的负载。在写少读多的情况下，通过多个从节点分担读负载，能够大大提高Redis服务的并发量和负载。

5，高可用的基石，主从复制是哨兵和集群模式能够实施的基础。

四、主从复制的操作：

先查看当前启动的主机的主从信息：

127.0.0.1:6379> info replication
role角色：master（主机）
connected_slaves（已连接的从机）:0(没有)
master_failover_state （主机_故障切换_状态）：no-failover(没有故障切换)

在这里插入图片描述

主从复制步骤：

实际生产中，我们用几个单独的linux主机来配置主从关系，这里我们在一台linux机子上模拟多台redis服务，来实现主从复制：
在这里插入图片描述

第一步：创建/myredis文件夹。
第二步：复制redis.conf配置文件到myredis文件夹中。
操作：
在这里插入图片描述

第三步：配置一主两从，创建三个新的配置文件：redis6379.conf,redis6380.conf,redis6381.conf

注意：这里也可以分别单独把redis.conf复制三份，然后改名字为redis6379.conf,redis6380.conf,redis6381.conf，然后分别修改三个配置文件。但是有点繁琐，修改的内容不清晰，我们这里采用新建文件，并引用原redis.conf中的内容，再添加新增内容即可（有点像thymleaf中的引用）。

myredis文件夹中最终是四个文件，一个完整的redis.conf和三个新建的不完整的conf文件（redis6379.conf,redis6380.conf,redis6381.conf），三个不完整的文件从完整文件引入了一些内容；

具体操作：

①首先编辑源redis.conf配置文件：
修改的内容为：关闭 aop：appendonly no即可，因为主从同步就是 RDB 文件的上传下载

redis支持master-slave模式，一主多从，redis server可以设置另外多个redis server为slave，从机同步主机的数据。配置后，读写分离，主机负责读写服务，从机只负责读。减轻主机的压力。redis实现的是最终会一致性，具体选择强一致性还是弱一致性，取决于业务场景。
redis 主从同步有两种方式（或者所两个阶段）：全同步和部分同步。

主从刚刚连接的时候，进行全同步；全同步结束后，进行部分同步。当然，如果有需要，slave 在任何时候都可以发起全同步。redis 策略是，无论如何，首先会尝试进行部分同步，如不成功，要求从机进行全同步，并启动 BGSAVE……BGSAVE 结束后，传输 RDB 文件；如果成功，允许从机进行部分同步，并传输积压空间中的数据。简单来说，主从同步就是 RDB 文件的上传下载；主机有小部分的数据修改，就把修改记录传播给每个从机。

②然后新建redis6379.conf文件，并编辑：

vim redis6379.conf
写入以下内容：
include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

在这里插入图片描述
③同理，我们新建其他两个从机的配置文件：

vim redis6380.conf
写入以下内容：
include /myredis/redis.conf
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb

vim redis6381.conf
写入以下内容：
include /myredis/redis.conf
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb

说明：includ 可以引入配置文件的公共部分，其他内容我们自己配置：

在这里插入图片描述
最终效果：

④启动三台redis服务器,并查看是否启动成功：

[root@localhost myredis]# redis-server redis6379.conf
[root@localhost myredis]# redis-server redis6380.conf
[root@localhost myredis]# redis-server redis6381.conf
ps -ef | grep redis

在这里插入图片描述

⑤查看三台主机的运行情况：

info replication

[root@localhost ~]# cd /usr/local/bin
[root@localhost bin]# redis-cli -p 6379
127.0.0.1:6379> info replication

在这里插入图片描述

⑥配置从库不配置主库：

在这里插入图片描述

将6380机器配置成从机：

slaveof 主机ip 主机端口号
info replication

在这里插入图片描述
将6381机器配置成从机：

从主机查看：
在这里插入图片描述

⑦测试主从复制的效果：

在这里插入图片描述

注意：从机这里只能读数据，配置文件中只读功能被开启了：
在这里插入图片描述

在这里插入图片描述

总结：

开启主从复制的方式有两种：

方式一、配置配置文件：

从服务器配置master节点

# 主节点ip port  配置自己节点的端口
# replicaof <masterip> <masterport>
# 主节点的认证密码(可选)
# masterauth <master-password>

方式二、使用命令开启：

客户端使用该命令slaveof 主机ip 主机端口号

info replication命令可查看节点信息

常用三招：

一主二仆：

一主二仆特点：
特点一：当我们把的一个从服务器挂掉了，那么在从服务器停机的这个时间段，主机进行了一些写的操作，当我们人为的把从机修好启动了之后，那主机写的数据能同步到新启动的从机吗，当然是可以的，因为你从机一旦新上线，我主机立马复制我的所有写数据到你从机中。

从机需要重新加入到主机上：
info replication 查看重新启动的从服务器后，他的角色变成了主服务器：
然后需要重新让其变成从机：slaveof 127.0.0.1 6379(这种方式还是比较麻烦的)

在这里插入图片描述
特点二：当主服务器挂掉后，从服务器不做任何事，还承认原先主服务器的位置，当挂掉的主服务器再次启动后，又回到主机的位置。

在这里插入图片描述

主从复制原理：

主从复制的三个阶:

Redis主从复制的完整工作流程有以下三个阶段。

建立连接过程：这个是slave跟master建立连接的过程。
数据同步的过程：是maser同步数据给slave的过程。
命令传播过程：是反复同步数据的过程。

在这里插入图片描述

全量复制：
全量复制是主从节点第一次建立主从复制关系时必须经历的阶段，复制流程如下：
在这里插入图片描述

从节点判断需要进行全量复制，向主节点传递命令 psync ? -1 (由于不知道主节点的 runid 和 offset，所以传 -1)
主节点收到全量复制的请求，传递 FULLRESYNC < runid > < offset > 返回主节点的 runid 和 offset
从节点保存主节点的 runid 和 offset 信息
主节点执行 bgsave，在后台生成 RDB 文件，并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令
主节点的 bgsave 执行完成后，将 RDB 文件发送给从节点
主节点执行 send buffer 操作，向从节点同步生成快照过程中的缓存命令
从节点清空旧数据并加载 RDB 文件
如果从节点开启了 AOF，则会触发 bgrewriteaof 的执行，从而保证 AOF 文件更新至主节点的最新状态

通过全量复制的过程可以看出，整个过程是十分消耗资源和时间的：

主节点通过 bgsave 命令执行 fork 操作创建子进程进行 RDB 持久化，该过程是非常消耗 CPU、内存和磁盘 I/O 资源

主节点通过网络向从节点传递 RDB 文件，耗费主服务器大量的网络资源包括带宽和流量，并对主服务器响应命令请求的时间产生影响

从节点清空旧数据并加载新的 RDB 文件的过程是阻塞的而无法响应其他命令请求，如果执行 bgrewriteaof 操作也会带来额外的消耗

增量复制:

当从节点正在复制主节点时出现网络异常或其他异常，从节点会请求主节点补发缺失的命令数据，主节点只需要将复制积压缓冲区的数据发送到从节点即可。相比于全量复制，增量复制的成本代价小很多，其流程如下：
在这里插入图片描述

网络发生抖动，主节点和从节点断开连接
主节点会将写命令备份到复制积压缓冲区中
从节点再次连接上主节点
从节点通过命令 psync < runid > < offset > 向主节点告知之前连接的 runid 和自己的偏移量
主节点进行校验后向从节点返回命令 CONTINUE 表示可以进行增量复制
主节点将缓冲区的数据发送到从节点

主从刚刚连接的时候，进行全量同步；全量同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

在这里插入图片描述

薪火相传：

过程举例：主机6379 ：ip127.0.0.1—>主机6379 下有一个从机6380：ip127.0.0.1–>然后
从机6380下自己也有一个从机8381 ，相当于三代人单脉相传；

薪火相传的特点和一主二仆基本一样;

在这里插入图片描述

反客为主：(主机挂掉，从机上位当主机)

反客为主特点：
在某一个从机手动使用命令 slaveof no one 将当前从机变成主机。

在这里插入图片描述

哨兵模式：（生产中用）

哨兵模式介绍：
在这里插入图片描述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵）架构来解决这个问题。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理就是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

在这里插入图片描述

这里的哨兵有两个作用：

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵检测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行互相监控，这样就形成了多哨兵模式。

多哨兵模式:

在这里插入图片描述

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover（故障转移）过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

哨兵模式使用：

第一步：调整为一主二仆的模式，并启动服务和配置主从关系：
在这里插入图片描述