redis优化-5.redis主从复制问题处理

 

1.读写分离

1.1复制数据延迟

Redis复制数据的延迟由于异步复制特性是无法避免的，延迟取决于网络带宽和命令阻塞情况，比如刚在主节点写人数据后立刻在从节点上读取可能获取不到。需要业务场景允许短时间内的数据延迟。对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避 免读取延迟过高的从节点，实现逻辑

处理说明：

1. 监控程序(monitor)定期检查主从节点的偏移量，主节点偏移量在info replication的master_repl_offset 指标记录，从节点偏移量可以查询主节点的slave0字段的 offset指标，它们的差值就是主从节点延迟的字节量。

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

1.2 读取过期数据

当主节点存储大量设置超时的数据时，redis内部需要维护过期数据删除策略，删除策略主要有两种：惰性删除和定时删除；

惰性删除：主节点每次处理读取命令时，都会检查键是否超时，如果超时则执行del命令删除键对象，之后del命令也会异步发送给从节点。因为保持复制的

一致性，从节点自身永远不会主动删除超时数据。

定时删除：Redis主节点在内部定时任务会循环采样一定数据量的键，当发现采样的键过期时执行del命令，之后再同步给从节点

 1.3 从节点故障问题

对于从节点的故障问题，需要在客户端维护一个可用从节点可用列表，当从节点故障时，立刻切换到其他从节点或主节点，之后讲解redis Cluster时候可以解决这个

 

2.配置不一致

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

主从配置不一致是一个容易忽视的问题。对于有些配置主从之间是可以不一致，比如:主节点关闭AOF在从节点开启。但对于内存相关的配置必须要一致， 比如 maxmemory, hash-max-ziplist-entries等参数。

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

 

3.规避全量复制

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

全量复制是不可避免的，例如第一次的全量复制是不可避免的，这时我们需要选择小主节点，且 maxmemory 值不要过大，这样就会比较快。同时选择在低峰值 的时候做全量复制。

造成全量复制的原因

1. 是主从机的运行 runid 不匹配。解释一下，主节点如果重启， runid 将会发生变化。如果从节点监控到 runid 不是同一个，它就会认为你的节点不安全。 当发 生故障转移的时候，如果主节点发生故障，那么从机就会变成主节点。我们会在后面讲解哨兵和集群。

2. 复制缓冲区空间不足，比如默认值1M，可以部分复制。但如果缓存区不够大的话，首先需要网络中断，部分复制就无法满足。其次需要增大复制缓冲区配 置 （relbacklogsize），对网络的缓冲增强。参考之前的说明

怎么解决

在一些场景下，可能希望对主节点进行重启，例如主节点内存碎片率过高，或者希望调整一些只能在启动时调整的参数。如果使用普通的手段重启主节点，会使 得runid发生变化，可能导致不必要的全量复制。

为了解决这个问题，Redis提供了debug reload的重启方式：重启后，主节点的runid和offset都不受影响，避免了全量复制

 

4.规避复制风暴

复制风暴是指大量从节点对同一主节点或者对同一台机器的多个主节点短时间内发起全量复制的过程。复制风暴对发起复制的主节点或者机器造成大量开销，导致 CPU、内存、带宽消耗。因此我们应该分析出复制风暴发生的场景，提前采用合理的方式规避。规避方式有如下几个。 这些在之后讲解哨兵和redis内存的时候讲解

4.1单节点复制风暴

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

解决：

可以采用树状结构降低多个从节点对主节点的消耗

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

4.2单机器复制风暴

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

解决：

应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的主节点。

当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制

 

5.主从延时模拟

docker run -itd -v /redis_2004/masterandslave/master:/redis -p 6350:6379 --network=redis5sm --ip=192.160.1.150 --name redis5master redis5asm

docker run -itd -v /redis_2004/masterandslave/slave:/redis -p 6340:6379 --network=redis5sm --ip=192.160.1.140 --name redis5slave redis5asm

docker run -itd -v /redis_2004/masterandslave/slave_130:/redis -p 6330:6379 --network=redis5sm --ip=192.160.1.130 --name redis5slave_130 redis5asm

docker run --privileged -itd -v /redis_2004/masterandslave/slave_120:/redis -p 6320:6379 --network=redis5sm --ip=192.160.1.120 --name redis5slave_120 redis5asm

slave_120机器

SLAVEOF 192.160.1.150 6379

apk add iproute2

tc qdisc add dev eth0 root netem delay 5000ms

添加数据