一、 主从数据一致性

1. 主多从少

主从网络延迟时，主多从少情况下，进行部分重同步。
场景简述：主多从少就是在网络延迟的情况下，从服务器尚未把主服务器的数据全部复制过来。
解决方案：
第一种：这时，我们可以等延迟结束之后，让从服务器进行部分重同步，就是我们说增量复制。
第二种：如果比较着急，向让他立刻执行重同步，需要任务干预。在从节点输入

psync 主节点master的run_id 追加需要复制的起始偏移量offset

就可以实现部分重同步
第三种：人为断开让从节点和主节点重新建立连接，也会触发部分重同步。

2. 主少从多

主少从多情况下，进行全量复制。
场景简述(主少从多)：这种情况是从服务器开启了写的操作导致的，也就是我们的从服务器是读写模式，当从从服务器写入，就会导致主从不一致。
解决方案:
把从服务器数据清空，让从服务器和主服务器重新建立连接，进行去哪量数据复制即可。

3. 知识点补充

在redis2.8版本之前，如果从节点和主节点断开重新连接，从节点就会全量复制，这无疑是一个降低性能的问题。
为了解决这个问题，redis在2.8版本之后，添加了一个特性；我们主从断开重连的时候，可以进行一个逻辑判断处理，来判断从节点进行全量复制还是增量复制？
其实就是我们的主服务器在内存中为每一个从服务器都维护了一个同步日志和同步标识，这三个同步日志就是backlog ，这个同步标识就是offset，每个从服务器在跟主服务器进行同步的时候，会携带同步标识和上次同步的位置，这样就会判断出这个复制，要做全量复制还是增量复制。

二、 数据延迟

2.1. 数据延迟因素

数据延迟，根据那些配置或者属性决定的。在info replication返回的信息中有一个偏移量，其实，就是根据这个偏移量来决定当前数据的一个健康状态，数据是否有延迟，我们的主节点在写入命令的时候，比如：我写入3000字节的一个偏移量，此时，我们的从节点只复制了1000，他们的差值比较大的时候，就说明数据延迟就很高了。

2.2. 解决方案

1.编写外部程序监听主从节点的复制偏移量，延迟较大时发出报警或者通知客户端，切换到主节点或者其他节点。
2设置从节点slave-serve-stale-data为no 除INFO SLAVEOF命令之外的任何请求都会返回一个错误“SYNC with master in progress”

三、 脏数据

3.1. 脏数据产生的场景

• 惰性：现在有一个key已经过期了，现在没有人活着客户端访问，就不会删除这个过期的key；在访问的时候在判断这个key是否过期，过期了就会删除，导致一个过期的key如果不被访问就会永远存在内存中。

• 定时：解决惰性缺点，内部有一个定时任务，隔一段时间就会判断一批key是否过期，过期了就删除掉。

• 主动删除：当前数据存储超过了redia的存储上限，然后，触发主动删除，正是因为rerdis删除机智的原因导致有脏数据的产生。
  从节点可写导致的，从节点一般都是只读模式，如果你开启了读写模式，这个数据从从节点误写入，可能导致产生脏数据。

3.2. 解决方案

• 忽略：比如：12306查询票，双11查询库存，当你去查询这些信息的时候，我并没有去做一个写操作，这样业务场景允许你出现一定的的错误，有一定的容错。我么可以选择忽略。
• 强制读主：当我们买一张车票，下单呢？秒杀抢购这个商品，这个时候数据一定要是准确的，我们可以采用强制读主的方式，从节点间接变为了备份服务器(某个业务)
• 从节点只读：规避从节点写入脏数据
  目前redis6.x之后，读取数据之前检查键过期时间来决定是否返回数据

四、 数据安全性

4.1. 场景

关闭主节点持久化会提升性能，同时会带来复制的安全性问题。

4.2. 解决方案

主节点不自动重启，不是用shell脚本手段监控主节点自动触发重启

五、 规避全量复制

5.1. 低峰时段

第一次全量复制解决方案：低峰时段挂载slave节点，比如：晚上12点

5.2. 主节点变更

选举slave为主节点

待补充

5.3. 增大复制缓冲区

六、 规避复制风暴

5.1. 单主节点

单主节点复制风暴：主节点重启，从节点全量复制
解决方案：
选举slave为主节点、树状复制结构

5.2. 单机多主

单机多主复制风暴：一台机器，多个主节点(树状复制架构)
解决方案：把主节点分散在多台机器上