全量增量的理解
全量同步的第一次建立连接的时候 这个时候slave节点没有任何数据 所以需要全量同步
那么如何判断是否需要全量同步
情况有两种
第一种是完全没来过的 也就是id都跟master都不一样 那么就很好识别的
id不一样就进行全量同步 全量同步后发送给slave节点的时候带上master的版本信息跟id
第二种是来过了 但是由于故障 导致存储的数据 offset便宜量被master占据 所以这个时候就已经完全跟不上repl_backlog版本了 所以就只能重头开始
因为repl_backlog实际上是一个数组 当master读完就会从头开始覆盖 所以如果salve节点没有持续更新就会被覆盖
那么就需要全量同步
那么同理 什么时候需要增量同步了
首先是为什么需要增量同步 这个其实很好理解全量同步是所有数据一起同步
那么如果时时刻刻每次都全量同步的话 那明显是不实际是 所以我们只需要记录相差的版本
进行这些数量同步就可以了
那么什么时候是增强同步呢
就是id一样 master没有完全覆盖salve的repl_backlog的offset这个时候就可以增量同步就可以了
主从同步优化
主从同步可以保证主从数据的一致性，非常重要。
可以从以下几个方面来优化Redis主从就集群：
在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力
