Redis的数据实现主从同步的机制

一 概述

在Redis主从同步中，一般只有一个Master进行数据的写操作，而会有多个slave进行读操作，定期的数据备份也是通过一个单独的slave进行实现，使得Redis的性能能够最大程度发挥出来，为了支持数据的弱一致性和最终一致性，我们并不需要保证Master与Slave之间的数据是实时同步，但是在一段时间后它们保存的数据是趋于同步的，从而满足最终一致性。

二 Redis主从同步的机制

第一次同步到时候，主节点（Master节点）会执行一次BGSAVA操作，并将后续的修改操作记录到内存的缓存中，待完成后，会将全量的RDB镜像文件同步到节点中，从节点接收到该镜像文件之后加载都内存中，加载完成后会发送消息通知主节点，将期间修改的操作，记录及增量数据同步到从节点，进行保存。也就是将某个时间点的全量数据同步完成后，再将该时间点之后的增量数据进行存放，进而实现整个同步的进程。

全同步：

从节点发送同步消息给主节点，此时Master节点启动一个后台进程，将Redis中的数据快照保存到文件中，即BGSAVE操作及数据同步命令。

在启动后台进程的同时，Master节点会将保存数据快照期间接收到的写命令缓存起来，即将增量数据缓存起来，当Master节点完成写文件操作后，将该文件发送给Slave节点，Slave结点接收到文件之后就会将文件保存到磁盘中，然后加载文件到内存中，去恢复数据快照，当Slave完成数据快照恢复之后，master就会将这期间收集的增量命令发送给salve进行回放。进而完成全量同步，当完成全量同步的之后，所有的读操作会在Slave上执行，所有的写操作会在Master上执行。

当然，Master也可以实现读操作，但是为了性能更好，所以将读操作都放在Salve上，因此用户的写操作需要及时的扩散到所有的Slave上，以便保持主从数据最大量的同步，Redis的Master与Slave经常进行更新操作，包括写,删除和更改操作，及时将这些数据变化进行同步。

增量同步：

Redis的主从进程在正常运行期间，增量同步方式为Master接收到用户的操作指令，会执行相应的操作函数，判断操作是否需要扩散到各个Slave，如果需要就会进行下一个步骤，当涉及到增删改就需要及时扩散到Slave，查就可以不进行相关操作，另外需要将操作记录追加到AOF文件上，并将操作扩散到其他Slave中，此是需要注意以下几点：

1. 对齐主从数据库，确保从数据库是该操作对应的数据库。
2. 检查无误后，将命令和参数按照Redis的协议格式，写入响应Slave的Master缓存中。
3. 最后将Master缓存中的这些数据发送给Slave结点。

三 主从模式的弊端与哨兵模式的优点

主从模式的弊端为：不具备高可用性，当Master挂掉之后无法对提供写入操作。

此时,需要使用Redis Sentinel（Redis 哨兵，Redis官方提供的主从管理工具）解决主从同步Master宕机后的主从切换问题，其实Redis Sentinel也是一个独立运行的进程，他能监控多个master-slave,发现master宕机之后，能进行自动切换。

Redis Sentinel主要实现了以下功能：

监控：sentinel会不断的检查主服务器和从服务器是否能够正常运行。

提醒：当被监控的某个Redis服务器出现问题时，sentinel会通过API向管理员或者时其他应用程序发送故障通知，使得操作人员能够及时的了解到相关的故障。

自动故障迁移：当一个主服务器无法正常工作的时候，sentinel会自动进行一次故障迁移操作，它会将失效的主服务器的一个从服务器升级为Master，并让其他的Slave服务器改为复制新的master，即让之前的Slave结点识别新的Master结点，并实现主从同步，当客户端尝试连接失效的主服务器时，集群会自动返回新的主服务器地址，使得集群使用新的master代替新的Master。

Redis Sentinel是分布式的，我们可以在一个架构中运行多个Sentinel进程，这些进程遵循（留言协议）gossip protocol来接收主服务器是否下线的信息，并使用（自动投票协议）agreement protocol来决定是否进行自动故障迁移，以及选择哪个从服务器作为新的主服务器，有点类似于Zookeeper。