目录
为什么需要主从复制？
在分布式系统中，有一个很关键的问题：单点问题（只搞一个物理服务器，来部署一个服务器程序）
1. 可用性，如果这个服务器挂了，服务就中断
2. 性能 / 支持的并发量有限
主从复制
假设有多个物理服务器分别部署了 redis-server 进程，就能把其中一个作为 " 主节点 "，其他的作为 " 从节点 "（从节点的数据跟随主节点变化，要和主节点保持一致），只对读操作进行并发量和可用性的提高。
配置
· 建立主从复制关系
（1）首先启动多个 redis 服务器。（每个部署在不同的主机上）
（2）在从节点的配置文件中添加以下行，然后重启服务。
slaveof <master_ip> <master_port>（3）查看主从状态（不放心的可以看看【滑稽】）
info replication· 断开主从复制关系
在从节点服务器输入
slaveof no one注意：从节点变成主节点，里面的数据不会抛弃。
· 更换主从结构
slaveof <ip> <port>注意：这种修改是临时性的，当重启 redis 后还是会安装配置文件中的进行
拓扑结构
若干个节点安装什么方式进行组织链接。
一主一从
主节点读 / 写数据请求，从节点读数据请求。如果写的数据过多主节点压力太大，可以关闭主节点的 AOF，只在从节点开启 AOF。（主节点挂了，不能自动重启。自动重启的话，主节点丢失写的数据，然后进行同步，把写到从节点的数据也删除），应该在主节点挂后，先把从节点的 AOF 文件复制到主节点再重启。
一主多从
更好的分担压力。（但是从节点过多，会影响主节点的网络带宽，修改一条就得同步几份）
树形主从结构
很好的缓解了一主多从的缺点。（一旦数据进行修改，数据延时同步时间会增加）
主从复制流程
psync 命令图解：
1. 全量数据同步
2. 增量数据同步
3. 不支持 ( 可以使用sync )
复制流程：
（1）先保存主节点的 ip 和端口。（变量）
（2）建立 TCP 连接。（验证通信双方是否能正确读写数据）
（3）验证主节点是否正常工作。
（4）redis 主节点开启密码，会进行权限验证。
（5）全量复制
① psync
② FULLRESSYNC
③ 保存必要信息（replid 等）
④ 主节点进行 bgsave 生成 RDB 文件
⑤ 把 RDB 文件发送给从节点，从节点保存文档到本地硬盘
⑥ 把新命令写入到缓冲区，等从节点保存完后再将缓冲区分给从节点
⑦ 从节点清空自身原有数据
⑧ 加载 RDB 文件
⑨ 如果开启 AOF 进行实时同步
现在也支持 " 无硬盘模式" ：主节点的数据不放到文件中，直接进行网络传输给从节点。从节点直接把加载数据。
（6）增量复制
① 主从节点出现网络中断时，如果超过 repl-timeout 时间，主节点会终止连接。
② 断开连接后，主节点仍然响应命令，但无法发给从节点，把数据挤压到缓冲区（内存队列）。
③ 网络恢复后，从节点连接主节点
④ 从节点发送 psync ，参数中包含 repid 和 offset（复制偏移量）
⑤ 主节点验证后，跟随 offset 去复制挤压缓冲区查找数据，然后响应 +CONTINUE给从节点。
⑥ 主节点发送数据给从节点
实时复制
当主节点已经同步数据给从节点后，后面也要进行数据的同步，此时就要进行实时复制。这时，主从节点会建立长时间的 TCP 连接，通过心跳包机制来检验连接是否正常。
心跳包机制：
主节点默认 10s 给从节点发一个 ping 命令，从节点收到返回 pong。
从节点默认 1s 给主节点发一个特点请求上报当前的 offset。
优点：
· 数据备份和恢复：主从复制为系统提供了实时的备份机制。从节点可以作为主节点的热备份，一旦主节点发生故障，可以迅速将从节点提升为新的主节点，保障数据的完整性和可用性。
· 负载均衡：在高并发的场景下，读操作往往占据了大量的系统资源。通过主从复制，可以将读请求分发到多个从节点，从而分担主节点的压力，提升系统的整体性能和响应速度。
· 高可用性（HA）：部署多个从节点，能够在主节点故障时迅速切换到从节点，减少系统的停机时间。结合故障转移（failover）机制，可以实现系统的高可用性，保证服务的持续性。
· 数据分布：可以将从节点部署在不同的地理位置，实现数据的地理分布。这样可以减少跨区域的网络延迟，提升用户的访问速度和体验。