Redis7——基础篇（五）

前言：此篇文章系本人学习过程中记录下来的笔记，里面难免会有不少欠缺的地方，诚心期待大家多多给予指教。

基础篇：

接上期内容：上期完成了Redis的其他功能的学习。下面开始学习Redis的主从模式(重点)，话不多说，直接发车。

一、定义

Redis主从模式是一种数据复制架构，在这个架构中，存在一个主节点（Master）和多个从节点（Slave）。主节点负责处理所有的写操作，然后将写操作产生的数据变化同步给从节点。从节点则主要负责处理读操作，通过复制主节点的数据来提供数据读取服务。

总结一句话：当master数据变化的时候，自动将新的数据异步或同步到其它slave数据库。

二、功能

读写分离：主节点负责处理所有的写操作，确保数据的一致性和完整性。而从节点则主要承担读操作，它们通过复制主节点的数据来保持与主节点数据的同步。
容灾恢复：主节点正常运行时，持续将数据变化同步到从节点。当主节点因硬件故障、软件错误、人为误操作或自然灾害等原因出现故障时，系统能够快速切换到从节点继续提供服务。
数据备份：从节点周期性或实时地复制主节点的数据，在存储介质上形成数据副本。
负载均衡：读请求被分散到多个从节点上，使得系统能够更均衡地处理负载
水平扩容支持高并发：当系统面临高并发压力时，可以通过增加从节点的数量来进行水平扩容

三、实操

（一）、架构说明

在VMWare上装三台虚拟机，三台虚拟机都装上Redis，一台Master，两台slave。

（二）、三大命令

1、"主从复制"

配从（库）不配主（库）

bash 复制代码

replication 主库IP 主库端口

2、"改换门庭"

改换门庭指：主节点宕机，slave连接到新的主节点上。

bash 复制代码

slave 新主库IP 新主库端口

3、"自立为王"

自立为王指：slave从从节点晋升为主节点。

bash 复制代码

slave no one

（三）、细节操作

1、开启daemonize

主从都改

2、注释掉bind 127.0.0.1

主从都改

3、设置protected-mode no

主从都改

4、指定端口

主机不用指定默认6379，改从机，分别对应6380，6381

5、修改存储目录

主从都改**。在/myredis目录下面新建backups文件夹**

6、修改pid名字，方便辨识

主机不修改，改从机，一般加上端口即可。

7、修改日志文件名

**主从都改，**一般加上端口即可。在/myredis目录新建logs日志目录。方便后续排查问题。

8、设置访问客户端密码

自己学习建议主从都设置一样。

9、修改rdb文件名

**主从都改，**一般加上端口即可。

10、修改aof文件

**主从都改，**一般加上端口即可。

11、设置从机访问主机IP和通行密码

主机不用，从机必须加。

在从机上配置Master：

bash 复制代码

replicaof <masterip> <masterport>

查看IP地址命令

12、最终效果图

一台Master，两台slave。

13、设置防火墙

一定要配置正确，不然主从无法通信，一直搭建不起来。我在这里栽了大坑。我建议临时关闭防火墙。

临时关闭防火墙命令

bash 复制代码

systemctl stop firewalld

临时开启防火墙命令

bash 复制代码

systemctl start firewalld

（四）、常用模式

1、"一主二从"

所谓一主二从指的是一台Master，两台slave。启动主从模式有两种方案，一种是配置（永久生效 ），一种是手动（临时生效，redis宕机失效）。

1.1、方案一

1、先启动Master，在启动两台slave。

Master启动，不需要带端口号

如果发现从机启动不了，优先排查防火墙问题。（三台虚拟机都临时关闭防火墙），然后在看日志。

从机启动需要带上端口号

bash 复制代码

redis-cli -a xxx -p 6380

2、主从关系查看

主从关系查看分两种方式：

命令查看：
bash 复制代码
```
info replication
```

日志查看：进入/myredis/logs目录下，用vim打开日志

1.2、方案二

1、移除配置项

移除slave中replicaof的配置项。

2、启动三台redis服务

3、执行命令

从机执行命令。

bash 复制代码

slaveof 主机IP 主机端口号

6380执行后：

6381执行后：

查看Master信息：

主从模式通过命令配置成功。

1.3、主从模式Ｑ＆Ａ

Q1：从机可以执行写命令吗？

A：不可以。主从模式的优点就是可以进行读写分离。Master写，slave读。

Q2：从机是从头开始复制还是从切入点复制？

A：假设Master已经启动成功，slave1也跟着一起启动成功，slave2在Maseter写到k3的时候才启动成功。此时slave2才加入，那么slave2第一次同步为全量同步，后续，Master写一个，slave跟写一个。

一句话：什么时候变成slave，什么时候全量继承Master，其后在增量同步。

6380：

6381此时还没启动成功：

由于我们手动移除了配置文件，所以只能通过命令实现主从关系。

Q3：主机宕机后，从机会上位吗？

A：不会，从机只会成为望夫石，等待Master的归来。

Master关机：

6380、6381不会上位：

Q4：主机宕机后，重新启动成功后，主从关系还存在吗？

A：不管是通过命令还是配置方式构建的主从关系，主机宕机后，重启成功后，主从关系依旧存在。

Q5：从机宕机后，重新启动成功后，从机的数据能跟Master保持一致吗？

A：能保持一致。Q1做了测试。

Q6：通过命令配置的主从关系，重启后，主从关系还存在吗？

A：如果是通过命令配置的主从关系，主机没有宕机，从机宕机后重启，主从关系不存在。但是如果是主机宕机从机没有宕机，主机重启后，主从关系依旧存在。

2、"薪火相传"

薪火相传指的是在一主二从的模式下，其中的某台slave2变成了slave1的slave，但是不管slave1还是slave2的最终数据来源都是Master。

薪火相传的架构图：

2.1、实操

中途变更转向:会清除之前的数据，重新建立拷贝最新的**。**

将6381转变为6301的从机:

注意：虽然6380由slave变成了6381的Master，但是还是不具备写的权限，毕竟它还是6379的slave。

3、"反客为主"

反客为主指的是两台slave造反了，自己当老大，不给6379打工了。自此三分天下，各自为政。

3.1、实操

cpp 复制代码

slaveof no one

注意：虽然自立为王，但是起家的资本不能丢。所以，slave本身已经同步的数据不会清除。

所以架构图变成了：

四、主从模式的流程和原理

1、slave启动，同步初清

slave启动成功连接到master后会发送一个sync命令，slave首次全新连接master，第一次完全同步（全量复制)将被自动执行，slave自身原有数据会被master数据覆盖清除。

2、首次连接，全量复制

master节点收到sync命令后会开始在后台保存快照(即RDB持久化，主从复制时会触发RDB)，同时收集所有接收到的用于修改数据集命令缓存起来，master节点执行RDB持久化完后，master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步。而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化。

3、心跳持续，保持通信

master发出PING包的周期，默认是10秒。

4、进入平稳，增量复制

Master继续将新的所有收集到的修改命令自动依次传给slave，完成同步。

5、从机下线，重连续传

当slave下线后，重新启动，master会检查backlog里面的offset，master和slave都会保存一个复制的offset和masterId，offset是保存在backlog中的。Master只会把已经复制的offset后面的数据复制给Slave，类似断点续传。

五、主从模式优劣势对比

优势

提高读写性能：通过读写分离，能够显著提升系统在高并发场景下的读写能力。
数据备份：多节点的数据冗余保证了数据的安全性，降低了数据丢失的风险。
易于扩展：可以方便地添加从节点来应对不断增长的读请求。

劣势

写操作单点问题：所有写的操作都集中在主节点，如果主节点出现故障，在故障转移期间，写操作会受到影响。
数据一致性问题：由于主从节点之间的数据同步存在一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

六、总结

Redis主从模式是一种简单而有效的架构，能够满足大部分应用场景对于读写性能和数据安全的需求。通过合理配置和使用主从模式，可以大大提升系统的性能和稳定性。然而，在实际应用中，也需要充分考虑其存在的劣势，采取相应的措施来解决可能出现的问题，希望本文能帮助大家对Redis主从模式有更深入的理解和应用。

ps：努力到底，让持续学习成为贯穿一生的坚守。学习笔记持续更新中。。。。