- 主从复制
(1) 主从复制概述：主从复制是指将一台redis服务器中的数据，复制到其它的redis服务器。前者称为主节点(master),后者称为从节点；数据的复制是单向的，只能是主节点到从节点
(2) 主从复制的作用
① 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式
② 故障恢复
③ 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载；尤其是在写多读少的情况下，通过多个从节点分担读负载，可以大大提高redis服务器的并发量
④ 高可用基石
(3) 主从库之间采用的是读写分离的方式
① 读操作：主库、从库都可以接收
② 写操作：首先到主库执行，然后，主库将写操作同步给从库
(4) 主从复制原理
① 全量(同步)复制：比如第一次被同步时
② 增量(同步)复制：只会把从库网络断连期间主库收到的命令，同步给从库
(5) 全量复制：但我们启动多个redis实例的时候，他们相互之间就可以通过replicaof命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步
① 确立主从关系
1) 现在有实例1(ip:172.16 .19.3)和实例2(ip:172.16.19.5),在实例2上执行 命令，实例2就变成了实例1的从库，并从实例1上复制数据
2) 命令：replicaof 172.16.19.3 6379
② 全量复制三个阶段图示
③ 全量复制三个阶段
1) 主从库建立连接、协商同步的过程
2) 主库将所有数据同步给从库：从库收到数据后在本地完成加载。整个过程依赖于内存快照生成的RDB文件
3) 主库会把第二阶段执行过程中新受到的写命令，再发送给从库：
(6) 增量复制
① 为什么会设计增量复制
1) 如果主从库在命令传播时出现网络闪断，那么从库就会和主库重新进行一次全量复制，开销非常大。从redis2.8开始，网络断了之后，主从库会采用增量复制的方式继续同步
② 增量复制的流程图示
③ 如果在网络断开期间，repl_backlog_size环形缓冲区写满之后，从库是会丢失掉那部分被覆盖掉的数据，还是直接进行全量复制呢？（重点）
1) 一个从库如果和主库断开时间过长，造成它在主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉了，此时将会进行全量复制。
2) 每个从库会记录自己的slave_repl_offset,每个从库的复制进度也不一定相同。在和主库重新连接进行恢复时，从库会通过psync命令把自己记录的slave_repl_offset发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制
(7) 当主服务器不进行持久化时复制的安全性
① 为什么不持久化的主服务器自动重启非常危险呢？反例（后果：主服务器和从服务器中的数据库都被删除了）
1) 设置节点A为主服务器，关闭持久化，节点B和节点C从节点A复制数据
2) 出现奔溃，但是redis具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集
3) 当在高可用系统中使用Redis Sentinel,关闭的主服务器的持久化，并且允许自动重启，这种情况是很危险的。比如主服务器在短时间内就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面所说的这种情况就发生了
4) 注意：如果数据比较重要，并且在使用主从复制时关闭了主服务器持久化功能的场景中，都应该禁止实例自动重启
② 为什么主从全量复制使用RDB而不适用AOF?
1) RDB文件内容是经过压缩的二进制数据，文件小可以尽量降低对主库机器网络带宽的消耗，成本也比较低
2) 假设要使用AOF做全量复制，就必须打开AOF功能，打开AOF就要选择文件刷盘的策略，选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量复制数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景中，其实是不需要开启AOF的
(8) 读写分离及其中的问题
① 延迟与不一致问题
② 数据过期问题
③ 故障切换问题
④ 总结：在使用读写分离之前，可以考虑其他方法增加Redis的读负载能力：如尽量优化主节点（减少慢查询、减少持久化等其他问题带来的阻塞）提高负载能力；使用redis集群同时提高读负载能力和写负载能力等。如果使用读写分离，可以使用哨兵，使主从节点的故障切换尽可能自动化，并减少对应用程序的入侵