规避全量复制问题

引言

首先，redis复制有全量复制和部分复制两种，而全量复制的开销是很大的。那么来看看，如何尽量去规避全量复制。

1、第一次全量复制

当某一台slave第一次去挂到master上时，是不可避免要进行一次全量复制的，那么如何去想办法降低开销呢？

方案1：小主节点，例如把redis分成2G一个节点，这样一来会加速RDB的生成和同步，同时还可以降低fork子进程的开销（master会fork一个子进程来生成同步需要的RDB文件，而fork是要拷贝内存快的，如果主节点内存太大，fork的开销就大）。

方案2：既然第一次不可以避免，那可以选在集群低峰的时间（凌晨）进行slave的挂载。

2、节点RunID不匹配

例如主节点重启（RunID发生变化），对于slave来说，它会保存之前master节点的RunID，如果它发现了此时master的RunID发生变化，那它会认为这是master过来的数据可能是不安全的，就会采取一次全量复制。

解决办法：对于这类问题，只有是做一些故障转移的手段，例如master发生故障宕掉，选举一台slave晋升为master（哨兵或集群）。

3、复制积压缓冲区不足

在master生成RDB同步到slave时，slave加载RDB这段时间里，master的所有写命令都会保存到一个复制缓冲队列里（如果主从直接网络抖动，进行部分复制也是走这个逻辑），待slave加载完RDB后，拿offset的值到这个队列里判断，如果在这个队列中，则把这个队列从offset到末尾全部同步过来，这个队列的默认值为1M。

而如果发现offset不在这个队列，就会产生全量复制。

解决办法：增大复制缓冲区的配置 rel_backlog_size 默认1M，我们可以设置大一些，从而来加大offset的命中率。这个值，可以假设，一般网络故障时间是分钟级别，那可以根据当前的QPS来算一下每分钟可以写入多少字节，再乘以可能发生故障的分钟就可以得到我们这个理想的值。