Redis 数据同步原理
全量同步
这种同步只有在第一次建立连接的时候才回去执行，因为生成 RDB 文件是特别慢的，特别消耗性能
master 如何判断 slave 是不是第一次来同步数据？这里会有两个重要的概念：
-
Replication Id : 简称 replid ，是数据集的标记，id 一致则说明是同一数据集。每一个 master 都有唯一的 rerplid ，slave 则会继承 master 节点的 replid
-
offset ：偏移量，随着记录在 repl_baklog 中的数据增多而逐渐增大。slave 完成同步时也会记录当前同步的 offset 。如果 slave 的 offset 小于 master 的 offset ，则说明 slave 的数据 落后于 master ，需要更新
因此，slave 做数据同步时，必须向 master 声明自己的 replication id 和 offset ，master 才可以确认到底要同步哪些数据，master 判断 slave 是不是第一次来同步数据只能是 replication id 不能是 offset ，因为 offset 也可能是 slave 从别的 master 那里同步过数据
简述全量同步的流程
-
slave 节点请求增量同步
-
master 节点判断 replid ， 发现不一致，拒绝增量同步
-
master 将完整内存数据生成一个 RDB ，发送 RDB 到 slave
-
slave 清空本地数据，加载 master 的 RDB
-
master 将 RDB 期间的命令及记录在 repl_baklog ，并持续将 log 中的命令发送给 slave
增量同步
注意：repl_baklog 大小有上限，写满后会覆盖最早的那一批数据，如果 slave 断开太久了，导致尚未备份的数据被覆盖，则无法基于 log 做增量同步，只能再次全量同步
可以从一下几个方面来优化 Redis 主从集群
-
在 master 中配置 repl-diskless-sync yes 启动五磁盘复制，避免全量同步时的磁盘 IO
-
Redis 单节点上的内存占用不要太大，减少 RDB 导致的过多磁盘 IO
-
适当提高 repl_baklog 的大小，发现 slave 宕机时尽快实现故障恢复，尽可能避免全量同步