主从数据不一致

主从同步延时

可能会出现 slave 延迟导致读写不一致问题。

解决方案

1. 可以使用监控偏移量 offset ，如果 offset 超出范围就切换到 master上逻辑切换

2. 对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点 同时从节点的 slave-serve-stale-data 参数也与此有关，它控制这种情况下从节点的表现 当从库同主机失去连接或者复制正在进行，从机库有两种运行方式：

1
2

1) 如果slave-serve-stale-data设置为yes(默认设置)，从库会继续响应客户端的请求。 
2) 如果slave-serve-stale-data设置为no，除去INFO和SLAVOF命令之外的任何请求都会返回一个错误”SYNC with master in progress”。

异步复制导致数据丢失

因为master->slave的复制是异步，所以可能有部分还没来得及复制到slave就宕机了，此时这些部分数据就丢失了

解决方案

只能降低到可控范围,没办法做到100%不丢失

如以下配置要求：至少有1个slave，数据复制和同步的延迟不能超过10秒

1
2
3
4

#最少有多少台从机器才能写入
min-slaves-to-write 1
#从节点最大延迟时间,延迟小于min-slaves-max-lag秒的slave才认为是健康的slave
min-slaves-max-lag 10

如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了 有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可 以把master宕机时由于部分数据未同步到slave导致的数据丢失降低到可控范围内

从节点故障

对于从节点的故障问题，需要在客户端维护一个可用从节点可用列表，当从节点故障时，立刻切换到其他从节点或主节点。

配置不一致

主机和从机不同，经常导致主机和从机的配置不同，并带来问题

如maxmemory不一致，如果主机配置maxmemory为8G，从机 slave 设置为4G，这个时候是可以用的，而且还不会报错。 但是如果要做高可用，让从节点变成主节点的时候，就会发现数据已经丢失了，而且无法挽回。

全量复制

全量复制指的是当 slave 从机断掉并重启后，runid 产生变化而导致需要在 master 主机里拷贝全部数据。这种拷贝全部数据的过程非常耗资源

全量复制产生原因

1. 是主从机的运行 runid 不匹配。解释一下，主节点如果重启， runid 将会发生变化。如果从节点监控到 runid 不是同一个，它就会认为你的节点不安全。 当发生故障转移的时候，如果主节点发生故障，那么从机就会变成主节点。
2. 复制缓冲区空间不足，比如默认值1M，可以部分复制。但如果缓存区不够大的话，首先需要网络中断，部分复制就无法满足。其次需要增大复制缓冲区配置（relbacklogsize），对网络的缓冲增强。

注：reload的重启方式，重启后，主节点的runid和offset都不受影响，避免了全量复制

单机器复制风暴-主机挂掉

当一个主机下面挂了很多个 slave 从机的时候，主机 master 挂了，这时 master 主机重启后，因为 runid 发生了变化，所有的 slave 从机都要做一次全 量复制。这将引起单节点和单机器的复制风暴，开销会非常大

解决

采用树状结构降低多个从节点对主节点的消耗。从节点采用树状树非常有用，网络开销交给位于中间层的从节点，而不必消耗顶层的主节点。但是这种树状结构也带来了运维的复杂性，增加了手动和自动 处理故障转移的难度

单机器复制风暴-从机挂掉

由于 Redis 的单线程架构，通常单台机器会部署多个 Redis 实例。当一台机器（machine）上同时部署多个主节点 （master） 时，如果每个 master 主 机只有一台 slave 从机，那么当机器宕机以后，会产生大量全量复制。这种情况是非常危险的情况，带宽马上会被占用，会导致不可用

解决方案

1. 应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的主节点。
2. 当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制