Redis 主从复制需要注意的问题（2）
规避全量复制
全量复制是一个非常消耗资源的操作，因此如何规避全量复制是需要重点关注的运维点。 下面我们对需要进行全量复制的场景
逐个分析。
·第一次建立复制： 由于是第一次建立复制， 从节点不包含任何主节点数据， 因此必须进行全量复制才能完成数据同步。 对于这种情况全量复制无法避免。 当对数据量较大且流量较高的主节点添加从节点时， 建议在低峰时进行操作， 或者尽量规避使用大数据量的Redis节点。
·节点运行ID不匹配： 当主从复制关系建立后， 从节点会保存主节点的运行ID， 如果此时主节点因故障重启， 那么它的运行ID会改变， 从节点发现主节点运行ID不匹配时， 会认为自己复制的是一个新的主节点从而进行全量复制。 对于这种情况应该从架构上规避， 比如提供故障转移功能。 当主节点发生故障后， 手动提升从节点为主节点或者采用支持自动故障转移的哨兵或集群方案。
·复制积压缓冲区不足： 当主从节点网络中断后， 从节点再次连上主节点时会发送psync{offset}{runId}命令请求部分复制， 如果请求的偏移量不在主节点的积压缓冲区内， 则无法提供给从节点数据， 因此部分复制会退化为全量复制。 针对这种情况需要根据网络中断时长， 写命令数据量分析出合理的积压缓冲区大小。 网络中断一般有闪断、 机房割接、 网络分区等情况。 这时网络中断的时长一般在分钟级（net_break_time） 。 写命令数据量可以统计高峰期主节点每秒info replication的master_repl_offset差值获取（ write_size_per_minute） 。 积压缓冲区默认为1MB， 对于大流量场景显然不够， 这时需要增大积压缓冲区， 保证
repl_backlog_size>net_break_time*write_size_per_minute， 从而避免因复制积压缓冲区不足造成的全量复制。
规避复制风暴
复制风暴是指大量从节点对同一主节点或者对同一台机器的多个主节点短时间内发起全量复制的过程。 复制风暴对发起复制的主节点或者机器造成大量开销， 导致CPU、 内存、 带宽消耗。 因此我们应该分析出复制风暴发生的场景， 提前采用合理的方式规避。 规避方式有如下几个
单主节点复制风暴
单主节点复制风暴一般发生在主节点挂载多个从节点的场景。 当主节点重启恢复后， 从节点会发起全量复制流程， 这时主节点就会为从节点创建RDB快照， 如果在快照创建完毕之前， 有多个从节点都尝试与主节点进行全量同步， 那么其他从节点将共享这份RDB快照。 这点Redis做了优化， 有效避免了创建多个快照。 但是， 同时向多个从节点发送RDB快照， 可能使主节点的网络带宽消耗严重， 造成主节点的延迟变大， 极端情况会发生主从节点连接断开， 导致复制失败。
解决方案首先可以减少主节点（master） 挂载从节点（slave） 的数量，或者采用树状复制结构， 加入中间层从节点用来保护主节点， 如图所示。（采用树状结构降低多个从节点对主节点的消耗）
单机器复制风暴
由于Redis的单线程架构， 通常单台机器会部署多个Redis实例。 当一台机器（machine） 上同时部署多个主节点（master） 时， 如图所示。
如果这台机器出现故障或网络长时间中断， 当它重启恢复后， 会有大量从节点（slave） 针对这台机器的主节点进行全量复制， 会造成当前机器网络带宽耗尽。如何避免？ 方法如下：
·应该把主节点尽量分散在多台机器上， 避免在单台机器上部署过多的主节点。
·当主节点所在机器故障后提供故障转移机制， 避免机器恢复后进行密集的全量复制。