开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 6 天，点击查看活动详情

主从架构

上一节介绍了Redis的持久化，本节将开始介绍Redis的主从架构，这是保证Redis高可用的重要特性，避免在主服务器损坏后丢失数据并且可以故障转移。

主从架构是什么

如果说数据都只保存在一个节点的话，万一发生了故障，那么数据都会丢失，那么我们就需要将数据备份到其他的节点上，如果主节点发生故障的话还可以用子节点进行故障转移。

客户端可以在主节点和从节点读取数据，但是修改数据只能在主节点进行。主节点在修改完数据后需要将写命令同步到从节点中。关于数据的同步，在Redis中分为不同类别的同步，分别是从节点第一次建立连接后的同步，建立连接后的同步以及从节点下线后重新上线的同步。

第一次建立连接同步

首先是从节点第一次建立连接的同步。从节点连接上主节点后会向主节点发送PSYNC命令，请求复制数据，主节点接收到这个命令后，会通过bgsave保存RDB快照，并将该快照发送给从节点，从节点收到快照后会丢弃所有数据将RDB加载进内存。

上一节说到bgsave期间，主线程仍然会处理指令，所以单纯的RDB快照会造成主从数据不一致，因此还会将bgsave期间，发送快照期间以及从节点加载快照期间的写指令放入缓冲区中，待从节点加载RDB文件完毕后发送。

建立连接后同步

其次是建立连接后的同步。在完成第一次同步后，主从会维持一个TCP的长链接，后续的写命令同步都会通过这个长连接进行传播。

主从间会维持ping-pong的心跳感应。主节点会每10秒向从节点发送ping指令来检查从节点是否存活。

从节点会每1秒向主键点发送replconf ack{offset}命令。除了检测主从间的网络状况外，还会将从节点的数据偏移量发送给主节点检查数据是否丢失，如果丢失，则从主节点复制缓冲区中获取数据。

从节点下线后重新上线同步

如果说每一次从节点下线后重新上线就向主节点同步所有的数据的话，那么就太浪费时间了，因为从节点里本来就存有主节点的数据，因此只需要同步下线期间丢失的数据就可以了。

master执行完写命令后不仅仅会发送同步命令给从节点，在这之前还会将该命令保存在内存中的环形缓存中，也就是上一部分提到的复制缓冲区。当从节点发送PSYNC命令后还会附带两个信息，分别是master id和offset，如果master id和当前需要同步的主节点id不同，那么当然是要全量更新。

如果id一致那么就要检查offset，查看当前的这个偏移量是否在主节点的复制缓冲区中。如果不在，就意味着从节点的数据太旧了，也需要进行全量的更新。相反，如果在的话只需要同步后面缺失的指令即可。

总结

本节介绍了Redis的主从架构，分析了主从架构中不同的几种同步方式。但是主从架构有一个很大的问题，就是如果主节点发生了故障，必须手动地将从节点变成主节点，无法自动地完成故障转移，而这个问题将在哨兵架构中得到解决。

感谢观看！