# Redis主从复制
# 1、概念
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者的Redis服务器称为主节点(master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。 Master以写为主，Slave 以读为主。
一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：
1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有 内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。
一般情况下，每台Redis服务器都是主节点，一个主服务器可以有多个从服务器。可以采用一主多从或者级联结构。
# 2、Redis为什么需要主从复制？
1、Redis的读写速度都非常快，单节点的Redis是能够支撑QPS大概再5W左右的量，如果进来上千万的用户访问，Redis就承受不住了，成为高并发的瓶颈了。
2、单节点的Redis是不能保证高可用的，当Redis因为某些原因意外宕机时，缓存就不可用了。
3、CPU的利用率上，单台Redis实例只能利用单个核心，这单个核心在面临海量数据的存取和管理工作时压力会非常大。
# 3、主从复制的作用
1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 （即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写 少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量，实现高可用。
4、高可用：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是 Redis高可用的基础。
# 4、主从复制的缺点
所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave服务器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重
# 5、模拟主从
# 5.1、创建环境配置
每次与 master 断开之后，都需要重新连接，除非你配置进 redis.conf 文件！
1、修改配置文件（本地测试）
我们配置主从复制，至少需要三个，一主二从！配置三个客户端！
我是在本地开启的redis服务，先找到redis的目录，然后找到redis.conf文件，在当前的文件夹下复制三份。
并改名为redis6379.conf、redis6380.conf、redis6381.conf
接下就要修改里面的配置了，每个文件都要进行修改：（以下端口不一定和我的一致，可自定义）
- 指定端口（看文件命名端口的号）
- 开启
daemonize yes - Pid文件名字： pidfile
/var/run/redis_端口号.pid - Log文件名字 logfile
"端口号.log" - Dump.rdb 名字 dbfilename
dump端口号.rdb
三个服务列表：
上面都配置完毕后，3个服务通过3个不同的配置文件开启，我们的准备环境就可以了！
# 5.2、一主二从
1、查看节点信息
Info replication # 查看信息
由上图可以看出，三个都是Master 主节点
2、配置从节点
此时要将两个设置为Slave从节点，我选择的是6080和6081作为从节点，需要修改一下。
slaveof 主库ip 主库端口 # 配置主从
以上就设置了一个主节点，两个从节点。
3、测试
在主机设置值，在从机都可以取到！从机不能写值！
6380从机不能写值：
6379主机写值：
6380从机不能取值：
神奇吧，从机可以取到值耶，6381的从机也可以取到值，可以自己测试一下。
# 5.3、模拟场景
1、主机挂了，查看从机信息，主机恢复，再次查看信息
停掉主机后：
主机恢复：
总结：主机挂了，查看从机信息（从机配置信息不变），主机恢复，再次查看信息（主机还是有两个从机，从机配置不变）
2、从机挂了，查看主机信息，从机恢复，查看从机信息
我将6380服务停掉：
# 5.4、节点链路
上一个Slave 可以是下一个slave 和 Master，Slave 同样可以接收其他 slaves 的连接和同步请求，那么 该 slave 作为了链条中下一个的master，可以有效减轻 master 的写压力！
| 节点1 | 节点2 | 节点3 |
|---|---|---|
| 主 | 从 主 | 从 |
此时我们在6379服务上添加一个值。其他的两个服务都获取到了值。
# 5.5、从升主
一主二从的情况下，如果主机断了，从机可以使用命令 SLAVEOF NO ONE 将自己改为主机！
这个时候其余的从机链接到这个节点。对一个从属服务器执行命令 SLAVEOF NO ONE 将使得这个从属服务器 关闭复制功能，并从从属服务器转变回主服务器，原来同步所得的数据集不会被丢弃。
# 6、复制原理
可参考：https://blog.csdn.net/zhaohuodian/article/details/126489359
# 6.1、复制过程
- 从节点执行 slaveof 命令。
- 从节点只是保存了 slaveof 命令中主节点的信息，并没有立即发起复制。
- 从节点内部的定时任务发现有主节点的信息，开始使用 socket 连接主节点。
- 连接建立成功后，发送 ping 命令，希望得到 pong 命令响应，否则会进行重连。
- 如果主节点设置了权限，那么就需要进行权限验证；如果验证失败，复制终止。
- 权限验证通过后，进行数据同步，这是耗时最长的操作，主节点将把所有的数据全部发送给从节点。
- 当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。
# 6.2、全量复制
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。
步骤如下（可了解）：
- 从服务器连接主服务器，发送SYNC命令。
- 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令。
- 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令。
- 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照。
- 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令。
- 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令。
注意：如果master和slave之间的连接出现断开，slave可以自动重连到master。根据版本的不同，断连后同步的方式也不同：
2.8版本之前：重连成功之后，一次全量同步操作将被自动执行。 2.8版本之后：重连成功之后，进行部分同步操作。
只要是重新连接master，一次完全同步（全量复制）将被自动执行
# 6.3、增量复制
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
# 6.4、心跳
主从节点在建立复制后，他们之间维护着长连接并彼此发送心跳命令。
心跳的关键机制：
主从都有心跳检测机制，各自模拟成对方的客户端进行通信，通过
client list命令查看复制相关客户端信息，主节点的连接状态为 flags = M，从节点的连接状态是 flags = S。![image-20221118102719400]()
主节点默认每隔 10 秒对从节点发送 ping 命令，可修改配置
repl-ping-slave-period控制发送频率。从节点在主线程每隔一秒发送
replconf ack{offset}命令，给主节点上报自身当前的复制偏移量。主节点收到 replconf 信息后，判断从节点超时时间，如果超过
repl-timeout 60秒，则判断节点下线。
