详解Redis主从数据同步原理

详解Redis主从数据同步原理

全量同步

主要步骤就是

• 判断是不是第一次来
• 生成RDB文件传送给slave
• 发送repl_backlog给slave，其中记录了RDB生成过程中的并发操作，因为RDB是子进程进行的

master如何判断slave是不是第一次来同步数据？

• Replication Id：数据集的标记，id一直说明是同一个数据集，每个master都有唯一的id，slave会继承master结点的replid
• offset：偏移量，随着记录在repl_backlog中的数据增多而增大，slave完成同步时也会记录当前同步的offset，如果slave的offset小于master的offset，说明slave数据落后于master，需要更新

slave做数据同步时，必须提交自己的replication id和offset，master才能判断到底需要同步那些数据，所以判断是不是第一次来，就看id相等不相等

增量同步

通过offset来定位未同步的数据范围

类似与redo log的记录过程
如果两者差距达到了一圈，那就只能做全量同步

同步优化

• 在master中配置repl-diskless-sync yes 启动无磁盘复制，避免全量同步时的磁盘IO（得保证网络带宽的承载能力）
• Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
• 提高repl_baklog大小，发现slave宕机时快速恢复，尽可能避免全量同步
• 限制一个master上的slave节点数，采用主-从-从链式结构，减少master压力

Master宕机了！！

slave结点宕机可以用过master增量同步恢复数据，那master宕机怎么办呢，提出了哨兵机制

哨兵Sentinel实现主从集群的自动故障恢复

• 监控：Sentinel会不断检查master和slave是否按预期工作
• 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master，当实例恢复后，也以新的master为主
• 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端（例如使用Redistemplate时主节点地址更换了如何收到通知）

服务状态监控原理

Sentinel基于心跳机制检测服务状态，每隔1秒向集群的每个实例发送ping命令

• 一个哨兵发现未响应，就会主观下线
• 超过指定数量的哨兵都发现主观下线，那就会客观下线，指定值最好是哨兵实例的一半

选举新的master原理

• 判断slave与master断开时间的长短，超过指定值，就排除该slave
• 判断slave的slave-priority
• 判断offset，越大说明数据更新，优先级更高
• slave的运行id大小，越小优先级更高