Redis 主从同步 问题
前言
相关系列
- 《Redis & 目录》（持续更新）
- 《Redis & 主从同步 & 源码》（学习过程/多有漏误/仅作参考/不再更新）
- 《Redis & 主从同步 & 总结》（学习总结/最新最准/持续更新）
- 《Redis & 主从同步 & 问题》（学习解答/持续更新）
什么是主从同步？
主从同步是Redis用于提高数据可用/可靠性的数据复制机制。主从同步允许Redis实例将自身设置为其它Redis实例的从机，从而令主机的数据可以向从机进行同步。如此一来当主机因为各项原因而宕机且一时难以立即恢复时，从机便可以及时取代主机以对外提供服务，从而得以保证数据的可用/可靠性。此外主从同步还间接具备提升数据读/写性能的效果，因为只要将读/写指令分别引导至从/主机执行以实现读/写分离，那么原本该由主机一力承担的指令便可以分摊至多台Redis实例上并发执行，从而大幅提升读/写效率。
主从同步有哪些架构？它们的优/缺点分别是什么？
一主多从
一主多从架构的核心是令任意数量的从机都同步相同主机，是实际场景使用最为频繁的主从架构…该架构的优/缺点具体如下：
- 同步效率高：所有的从机都直接由主机负责数据同步。
- 主机负载高：当从机的数量较多时，用于实现数据同步的开销将对主机运行造成相当大的压力。
级联
级联架构在一主多从架构的基础上添加了等级概念，即其允许从机继续携带从机，而非所有的从机都直接向主机进行同步…该架构的优/缺点具体如下：
- 主机负载小：主机并不需要负责所有数据同步，这在从机数量较多时可以大幅降低主机的运行压力。
- 同步效率低：数据需要进行多级传导，因为上游从机已完成数据同步的情况下下游从机可能尚未开始同步；
- 监控难度大：从机的宕机可能导致整个分支不可用，因此在引入哨兵的情况下，所有携带有从机的主/从机都应该被监控。
主从同步有几种同步方式？大致流程是什么样的？
主从同步有“全量同步&增量同步”两种同步方式，前者通常（但不限于）在主/从机（启动/重启）首次建立长链接时使用；而后者在用于在网络分区/断线重连时延续之前中断的数据同步。
全量同步
- 从机向主机发送{SYNC/PSYNC}指令请求全量同步；
- 主机接收到{SYNC/PSYNC}指令，并在判定为全量同步后返回全量同步回应。然后异步执行{SAVE}指令生成RDB快照文件，并在文件生成后将之发送至从机。而从RDB快照文件开始生成起，主机并发接收到的所有写指令都会被同步写入replication_buffer @ 复制缓冲区中，以备后续对从机进行持续性的指令同步；复制缓冲区的大小默认为1MB，当满溢时其会阻塞内存读写。此外如果全量同步是由{PSYNC}指令触发的，那么主机接收的“所有”写指令还会被同步写入replication_backlog_buffer @ 复制积压缓冲区中，用于为可能发生增量同步提供数据支持；
- 从机接收全量同步回应，并准备接受RDB快照文件；
- 从机接收到RDB快照文件，随后异步加载其中数据。该异步加载可能会阻塞主进程的内存读/写，因为在此期间主进程虽然允许执行其它的初始化行为，但在RDB快照文件正式完成加载前其实不允许接受/执行指令的，否则就会出现数据不一致问题；
- 主机结束对RDB快照文件的发送，随后持续向从机发送复制缓冲指令以进行持续性的指令同步；
- 从机持续接收并执行复制缓冲指令，从而实现对主机数据的同步。
增量同步
- 从机向主机发送{PSYNC}指令请求增量同步；
- 主机接收{PSYNC}指令，在根据其携带的主机运行ID/从机偏移量确定可执行增量同步后返回增量同步回应。随后通过从机偏移量在复制积压缓冲区中定位最后同步指令的位置，并向从机发送尚未同步的复制加压缓冲指令以实现持续性的指令同步；
- 从机接收增量同步回应，并准备接受复制积压缓冲指令；
- 从机持续接收并执行复制加压缓冲指令，从而实现对主机数据的同步。
开启主从同步后还需要开启持久化吗？推荐的持久化方案又是什么呢？
持久化机制即使是在已启动主从同步的情况下也是必须开启的，因为数据只有存入磁盘后才能彻底避免/减少丢失的情况发生。而单纯使用主从同步做数据热备是无法彻底做到这一点的，甚至主从同步本身还会成为数据丢失的原因。例如在没有开启持久化机制的情况下，如果主机宕机后又恢复运行，那么主从同步就会导致从机的热备数据因为主机数据的丢失而清空…因此持久化机制才是避免/减少数据丢失的最佳方案。
在开启主从同步的情况下，主机更推荐同时开启RDB/AOF机制以保证数据尽可能的完整，毕竟其是数据的实际来源，而从机的持久化方案则需要根据实际情况来定。如果从机仅用于在主机宕机时暂用，那么通常是无需开启持久化或只需开启RDB持久化；而如果从机后会用于在主机宕机后作为新主机使用的，那么就推荐和主机一样同时开启RDB/AOF机制。