Redis开发与运维学习笔记---(11)

Redis开发与运维中遇到的问题

之前的文章中，我们讲述了redis的复制机制，通过复制，数据可以被备份，然后这些备份的副本可以用来做读写分离、负载均衡、故障转移等，在实际应用复制功能时，有一些点还是需要注意的，这里咱们罗列下。

1

读写分离

对于读占比比较高的场景，我们可以把一部分流量分摊到从节点slave来减轻主节点master的压力，当使用读节点来响应读请求时，可能遇到下面的问题：

1、复制数据延迟

2、读到过期数据

3、从节点故障

首先来看复制数据延迟：

redis复制数据延迟主要是异步复制导致的，延迟取决于网络带宽和命令阻塞情况，比如刚在主节点写入数据之后，立刻在从节点读取数据，可能会出现读取不到的问题。如果业务无法忍受大量延迟场景，则需要编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警。

再看过期数据：

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

惰性删除是指主节点每次处理读取命令时，都会检查键是否超时，如果超时，则执行del命令删除对象，此时del命令也会异步发送给从节点。

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

注意，如果此时主节点上数据大量超时，主节点的采样速度跟不上过期速度，而且主节点没有读取过期键的操作，那么从节点将无法收到del命令。此时从节点上将会读取到已经超时的数据。

从节点故障问题：

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

以上所述为使用Redis做读写分离是存在的成本，Redis本身的性能非常高，开发人员在使用额外的从节点提升读性能之前，尽量在主节点上做充分的优化，提前解决慢查询、持久化阻塞等问题。

2

主从配置不一致

主从配置不一致有时候会造成主从的数据不一致，例如maxmemory等参数，如果不一致(假设从库的参数较小)，当复制的数据量超过从节点的maxmemory时，复制仍然会进行，但是主从的数据已经不一致了，此时需要人工介入。

3

规避全量复制

我们知道，全量复制是一个非常消耗资源的操作，如何规避全量复制是需要我们关注的运维点。以下是全量复制的所有场景：

1、第一次建立复制：由于是第一次建立复制关系，这种情况，全量复制无法避免。

2、节点运行 ID不匹配：主从复制建立后，如果主节点因故障重启，则运行ID会改变，从节点发现运行ID不匹配后会认为自己复制了一个新的主节点而进行全量复制。这种情况下，可以在主节点发生故障后，手动提升从节点为主节点，提供故障转移功能。

3、复制积压缓冲区不足：当主节点网络中断后，从节点再次连接主节点时，如果psync命令在主节点中的复制积压缓冲区中找不到指定的偏移量，部分复制会退化为全量复制。这种命令需要根据网络延迟，中断时长，写命令的数据量等来综合确定复制积压缓冲区的大小，从而避免复制积压缓冲区不足的情况，并且不会带来额外的空间浪费。

4

规避复制风暴

复制风暴是指大量从节点对统一主节点或者对同一台机器的多个主节点短时间内发起全量复制的过程，这类操作会对主节点或者机器造成大量开销，导致CPU、内存、带宽的大量消耗，规避此类问题的方法有如下几种：

1、单主节点复制风暴

单节点复制风暴一般发生在主节点挂载多个从节点的场景，当主节点重启恢复后，从节点会发起全量复制流程，这时主节点就会为从节点创建RDB快照，如果在快照创建完毕之前，有多个从节点都尝试与主节点进行全量同步，那么其他从节点将共享这份RDB快照，但是虽然是共享，同时向多个从节点发送RDB快照会使得主节点的网络带宽消耗严重，造成主节点延迟变大。

解决方案是：减少主节点挂载的从节点数量，或者采用树状的级联复制结构，加入中间层节点来保护主节点。

2、单机器复制风暴

由于redis是单线程架构，通常单台机器会部署对个redis实例，当一台机器上同时部署多台机器时，如果这台机器出现故障或者网络长时间中断，当它恢复后，会有大量从节点针对这台机器上的主节点进行全量复制，会导致网络带宽耗尽。

规避方法如下：

把主节点尽量分散在多台机器上，避免单台机器部署过多的主节点；当主节点所在机器出现故障后，提供故障转移机制，避免机器恢复后的密集全量复制。