（进阶篇）Redis6.2.0 集群 一主二从 读写分离_故障解决_03

本文主要是介绍（进阶篇）Redis6.2.0 集群 一主二从 读写分离_故障解决_03，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

主多从少就是在网络延迟的情况下，从服务器尚未把主服务器的数据全部复制过来。
第一种：这时我们可以等延迟结束之后，让从服务器进行部分重同步，就是我们说增量复制。
第二种：如果比较着急，向让他立刻执行重同步，需要任务干预。在从节点输入
psync 主节点master的run_id 追加需要复制的起始偏移量offset
就可以实现部分重同步
第三种：人为断开让从节点和主节点重新建立连接，也会触发部分重同步。

知识点：在redis2.8版本之前，如果从节点和主节点断开重新连接，从节点就会全量复制，这无疑是一个降低性能的问题。
为了解决这个问题，redis在2.8版本之后，添加了一个特性；我们主从断开重连的时候，可以进行一个逻辑判断处理，来判断从节点进行全量复制还是增量复制？
其实就是我们的主服务器在内存中为为每一个从服务器都维护了一个同步日志和同步标识，这三个同步日志就是backlog ，这个同步标识就是offset，每个从服务器在跟主服务器进行同步的时候，会携带同步标识和上次同步的位置，这样就会判断出这个复制，要做全量复制还是增量复制。
主少从多：这种情况是从服务器开启了写的操作导致的，也就是我们的从服务器是读写模式，当从从服务器写入，就会导致主从不一致。
把从服务器数据清空，让从服务器和主服务器重新建立连接，进行去哪量数据复制即可。

数据延迟，根据那些配置或者属性决定的。在info replication返回的信息中有一个偏移量，其实，就是根据这个偏移量来决定当前数据的一个健康状态，数据是否有延迟，我们的主节点在写入命令的时候，比如：我写入3000字节的一个偏移量，此时，我们的从节点只复制了1000，他们的差值比较大的时候，就说明数据延迟就很高了。
解决方案：
1
2
脏数据产生的场景：
惰性：现在有一个key已经过期了，现在没有人活着客户端访问，就不会删除这个过期的key；在访问的时候在判断这个key是否过期，过期了就会删除，导致一个过期的key如果不被访问就会永远存在内存中。
定时：解决惰性缺点，内部有一个定时任务，隔一段时间就会判断一批key是否过期，过期了就删除掉，
主动删除：当前数据存储超过了redia的存储上限，然后，触发主动删除，正是因为erdis删除机智的原因导致有脏数据的产生。
从节点可写导致的，从节点一般都是只读模式，如果你开启了读写模式，这个数据从从节点误写入，可能导致产生脏数据。
解决方案：
忽略：比如：12306查询票，双11查询库存，当你去查询这些信息的时候，我并没有去做一个写操作，这样业务场景允许你出现一定的的错误，有一定的容错。我么可以选择忽略。当我们买一张车票，下单呢？秒杀抢购这个商品，这个时候数据一定要是准确的，我们可以采用强制读主的方式，

这篇关于（进阶篇）Redis6.2.0 集群 一主二从 读写分离_故障解决_03的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！