企业级Redis开发运维从入门到实践 （22）— 全量、部分复制的故障处理

故障处理

无自动故障转移

当Server1故障无法向Client提供服务时，无法将服务转移到Server2继续为Client提供个服务。

自动故障转移

当Server1故障无法向Client提供服务时，将服务转移到Server2继续为Client提供个服务。

主从结构 — 故障转移

slave 故障

当一个 Slave 出现故障，对于 Master 来说没有太大的问题，除非 Master 的压力非常大，需要通过扩容做一个新的 Slave 读写的分离的处理；对于右下角的Client 将无法读取到数据，此时需要将此 Client 的请求连接切换到其他的Slave上；需要考虑 另一个 Slave 是否能承受这些压力，一般来说不会有太大的问题。

master 故障

对于 Master 出现的故障，左边的 Client 是无法在做读写操作；右边的只读客户端是正常的，对应的 Client 服务是正常使用的；此时需要对这个故障进行处理，比较简单的方法是 向一个Slave 执行 slaveof no one 命令，将其设为新的 Master ，对另外的 Slave 执行 slaveof new master 命令将其连接到新的 Master 上；此时左边的 Client 就可以做读写操作了，右上角的Clinet设置只读权限。

主从复制故障转移问题？

以上的故障问题都可以解决，但是还是需要一定的时间和经验才能处理好；但是这些还没实现主从复制故障的自动转移，假如有一种机制帮助管理，自动进行故障转移，当 Master 故障将选出一个 Slave 晋升为新 Master，然后将其他的 Slave 同步到新的 Master，并且通知客户端新的 Master 是谁。

Redis 提供了 sentinel 解决了这个问题，以实现 Redis 的高可用。

开发与运维中的问题

读写分离

读写分离
读流量分摊到从节点，通过 Master 进行写入，Slave 进行读取；降低 Master 写的压力，同时扩展了读的能力。

可能遇到的问题

1. 复制数据延迟：虽然大多数情况 Master 写入，对于 Slave 会做一个异步的同步将数据复制给 Slave；但是这是有时间差的，当 Slave 发生阻塞的时候会延迟接收到写的命令，因此引起读写不一致的情况。可以通过偏移量监控这个问题。
2. 读到过期数据：当过期数量非常多，采样数据比不上过期数据时，会造成很多过期数据没有删除，但是 Redis 里 Master 和 Slave 达成的协定是 Slave 是不能处理数据的，这样 Slave 就会读到脏数据。3.2版解决了这个问题。[懒惰策略（key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null），定时删除（每隔一段时间执行一次采样一些key看有没有过期，删除过期key操作）]。
3. 从节点故障：当从节点故障，怎么讲从节点进行一个迁移，它的成本是非常高的。

主从配置不一致

1. maxmemory不一致（例如 Master 设置为4G，slave 设置为2G，当全量复制时 RDB 文件过大，Slave 就会触发maxmemory policy将数据进行一个淘汰）：丢失数据。
2. 例如数据结构优化参数（例如hash-max-ziplist-entries）：内存不一致。

规避全量复制

1. 第一次全量复制：不可避免。
   如何优化：
   小主节点：数据分片（maxmemory）设置不要过大，这样 bgsave 的传输、加载的速度都会比较快，开销相对会小一些；包括fork的耗时都会降低。
   低峰 ：在访问低峰时，Redis 集群及机器的负载比较低时做这样的操作。
2. runid 不匹配：主节点重启（runid变化）。
   如何优化：
   故障转移：主节点故障，从节点晋升为主节点，可以避免这样的问题的出现。
   哨兵或集群：提供可以解决该问题的机制。
3. 复制积压缓冲区（队列）不足： 网络中断，部分复制无法满足。
   如何优化：
   增大复制缓冲区配置rel_backing_size。
   网络“增强”。

规避复制风暴

1. 单节点复制风暴
   问题：主节点重启，多从节点复制
   如何优化：
   更换复制拓扑

2. 单机器复制风暴
   如下图：机器宕机后，大量全量复制
   如何优化：
   主节点分散多个机器