发表于 | 分类于 | 0 | 阅读次数 229

应用中的问题

​ 前文：在原文中，关于Redis主从复制在应用中的问题，作者放在了第六小节，但在我个人的学习中，我觉得原文篇幅较长，且关于在应用中的问题，与原理部分可以分开讲述。因此，我将原文中的该章节单独抽取出来。

1、读写分离及其中的问题

​ 在主从复制基础上实现的读写分离，可以实现Redis的读负载均衡：由主节点提供写服务，由一个或多个从节点提供读服务（多个从节点既可以提高数据冗余程度，也可以最大化读负载能力）；在读负载较大的应用场景下，可以大大提高Redis服务器的并发量。下面介绍在使用Redis读写分离时，需要注意的问题

1、延迟与不一致问题

​ 前面已经讲到，由于主从复制的命令传播过程是异步的，延迟与数据的不一致不可避免。如果应用对数据不一致的接受程度较低，可能的优化措施包括：优化主从节点之间的网络环境（如在同机房部署）；监控主从节点延迟（通过offset）判断，如果从节点延迟过大，通知应用不再通过该从节点读取数据；使用集群同时扩展写负载和读负载等

​ 在命令传播阶段以外的情况下，从节点的数据不一致问题可能更严重，例如连接在数据同步阶段，或从节点失去与主节点的连接时等。从节点的slave-server-stale-data参数便与此有关：它控制这种情况下从节点的表现；如果为yes（默认值），则从节点仍能够响应客户端的命令，如果为no，则从节点只能响应info、slaveof等少数命令。该参数的设置与应用对数据一致性要求有关；如果对数据一致性要求很高，则应设置为no

2、数据过期问题

​ 在单机版Redis中，存在两种删除策略：

  • 惰性删除：服务器不会主动删除数据，只有当客户端查询某个数据时，服务器判断改数据是否过期，如果过期则删除
  • 定期删除：服务器执行定时任务删除过期数据，但是考虑到内存和CPU的折中（删除会释放内存，但是频繁的删除操作对CPU不友好），该删除的频率和执行时间都收到了限制

​ 在主从复制场景下，为了主从节点数据一致性，从节点不会主动删除数据，而是由主节点控制从节点中过期数据的删除。由于主节点的惰性删除和定期删除策略，都不能保证主节点及时对过期数据执行删除操作 ，因此，当客户端通过Redis从节点读取数据时，很容易读取到已经过期的数据

​ 在Redis3.2中，Redis加入了一个新特性来解决主从不一致导致读取到过期数据的问题，在db.c文件中，作者对lookupKeyRead做了相应的修改，增加了key是否过期以及对主从库的判断，如果key已过期，当前访问的主节点则返回null；当前访问的是从节点，且执行的是只读命令也返回null

3、故障切换问题

​ 在没有使用哨兵的读写分离场景下，应用针对读和写分别连接不通的Redis节点；当主节点或从节点出现问题而发生更改时，需要及时需要应用程序读写Redis数据的连接；连接的切换可以手动进行，或者自己写监控程序进行切换，但前者响应慢，容易出错，后者实现复杂，成本都不算低

4、总结

​ 在使用读写分离之前，可以考虑其他方法增加Redis的读负载能力：如尽量优化主节点（减少慢查询，减少持久化等其他情况带来的阻塞等）提高负载能力；使用Redis集群同时提高读负载能力和写负载能力等。如果使用读写分离，可以使用哨兵，使主从节点的故障切换尽可能自动化，并减少对应用程序的侵入性

2、复制超时问题

​ 主从节点复制超时是导致复制中断的最重要原因之一，本小节单独说明超时问题，下一小节说明其他会导致复制中断的问题

1、超时判断的意义

​ 在复制建立连接过程中及之后，主从节点都有机制判断连接是否超时，其意义在于：

  1. 如果主节点判断连接超时，其会释放相应从节点的连接，从而释放各种资源，否则无效的从节点仍会占用主节点的各种资源（如输出缓冲区、带宽、连接等）；此外连接超时的判断可以让主节点更准确的知道有效节点的个数，有助于帮助保证数据安全（配合先前讲到的min-slaves-to-write等参数）
  2. 如果从节点判断连接超时，则可以即使重新建立连接，避免与主节点数据长期的不一致

2、判断机制

​ 主从复制超时判断的核心，在于repl-timeout参数，该参数规定了超时时间的阈值（默认60s），对于主节点和从节点同时有效；主从节点触发超时的条件分别如下：

  1. 主节点：每秒一次调用复制定时函数（replicationCron()），在其中判断当前时间距离上次收到各个从节点REPLCONF ACK的时间，是否超过了repl-timeout值，如果超过了则释放相应从节点的连接

  2. 从节点：从节点对超时的判断同样是在复制定时函数中判断，基本逻辑是

    • 如果当前处于连接建立阶段，且距离上次收到主节点的信息的时间已经超过了repl-timeout，则释放与主节点的连接
    • 如果当前处于数据同步阶段，且受到主节点的RDB文件的时间超时，则停止数据同步，释放连接
    • 如果当前处于命令传播阶段，且距离上次收到主节点的PING命令或数据的时间已超过了repl-timeout值，则释放与主节点的连接

    主从节点判断连接超时的相关源代码如下：

    /* Replication cron function, called 1 time per second. */
void replicationCron(void) {
    static long long replication_cron_loops = 0;

    /* Non blocking connection timeout? */
    if (server.masterhost &&
        (server.repl_state == REDIS_REPL_CONNECTING ||
         slaveIsInHandshakeState()) &&
         (time(NULL)-server.repl_transfer_lastio) > server.repl_timeout)
    {
        redisLog(REDIS_WARNING,"Timeout connecting to the MASTER...");
        undoConnectWithMaster();
    }

    /* Bulk transfer I/O timeout? */
    if (server.masterhost && server.repl_state == REDIS_REPL_TRANSFER &&
        (time(NULL)-server.repl_transfer_lastio) > server.repl_timeout)
    {
        redisLog(REDIS_WARNING,"Timeout receiving bulk data from MASTER... If the problem persists try to set the 'repl-timeout' parameter in redis.conf to a larger value.");
        replicationAbortSyncTransfer();
    }

    /* Timed out master when we are an already connected slave? */
    if (server.masterhost && server.repl_state == REDIS_REPL_CONNECTED &&
        (time(NULL)-server.master->lastinteraction) > server.repl_timeout)
    {
        redisLog(REDIS_WARNING,"MASTER timeout: no data nor PING received...");
        freeClient(server.master);
    }

    //此处省略无关代码……

    /* Disconnect timedout slaves. */
    if (listLength(server.slaves)) {
        listIter li;
        listNode *ln;
        listRewind(server.slaves,&li);
        while((ln = listNext(&li))) {
            redisClient *slave = ln->value;
            if (slave->replstate != REDIS_REPL_ONLINE) continue;
            if (slave->flags & REDIS_PRE_PSYNC) continue;
            if ((server.unixtime - slave->repl_ack_time) > server.repl_timeout)
            {
                redisLog(REDIS_WARNING, "Disconnecting timedout slave: %s",
                    replicationGetSlaveName(slave));
                freeClient(slave);
            }
        }
    }

    //此处省略无关代码……

}

3、需要注意的问题

​ 下面介绍与复制阶段连接超时有关的一些实际问题：

  1. 数据同步阶段：在主从节点进行全量复制bgsave时，主节点需要首先fork子进程将当前数据保存到RDB文件中，然后再将RDB文件通过网络传输到从节点。如果RDB文件过大，主节点在fork子进程+保存RDB文件时耗时过多，可能会导致从节点长时间收不到数据而触发超时；此时从节点会重连主节点，然后再次全量复制，再次超时，再次重连...这是个悲伤的循环。为了避免这种情况的发生，除了注意Redis单机数据量不要过大，另一方面就是适当增大repl-timeout值，具体的大小可以根据bgsave耗时来调整
  2. 命令传播阶段：如前所述，在该阶段主节点会向从节点发送PING命令，频率有repl-ping-slave-period控制；该参数应明显小于repl-time值（后者至少是前者的几倍）。否则如果两个参数相等或相近，网络抖动导致个别PING命令丢失，此时恰巧主节点也没有向从节点发送数据，则从节点很容易判断超时
  3. 慢查询导致的阻塞：如果主节点或从节点执行了一些慢查询（如keys * 或者对大数据的hgetall等），导致服务器阻塞；阻塞期间无法响应复制连接中对方节点的请求，可能导致复制超时

3、复制中断问题

​ 主从节点超时是复制中断的原因之一，除此之外，还有其他情况可能导致复制中断，其中最主要的是复制缓冲区溢出问题

复制缓冲区溢出

​ 前面曾提到过，在全量复制阶段，主节点会将执行的写命令放到复制缓冲区中，该缓冲区存放的数据包括了以下几个时间段内主节点执行的写命令：bgsave生成RDB文、RDB文件由主节点发往从节点，从节点清空旧数据并载入RDB文件中的数据。当主节点数据量较大，或者主从节点之间网络延迟较大时，可能导致该缓冲区的大小超过了限制，此时主节点会断开与从节点之间的连接。这种情况可能引起全量复制->复制缓冲区溢出导致连接中断->重连->全量复制->复制缓冲区溢出导致连接中断-> 重连...的循环

​ 复制缓冲区的大小由client-output-buffer-limit slave 配置，默认值是client-output-buffer-limit slave 256MB 64MB 60，其含义是：如果buffer大于256MB，或者连续60s大于64MB，则主节点会断开与该从节点的连接。该参数是可以通过config set命令动态配置的（即不重启Redis也可以生效）。

​ 当复制缓冲区溢出是，主节点打印日志如下所示：

output-buffer-out-of-limit

​ 需要注意的是，复制缓冲区是客户端输出缓冲区的一种，主节点会为每一个从节点分别分配复制复制缓冲区；而复制积压缓冲区则是一个主节点只有一个，无论它有多少个从节点

4、各场景下复制的选择及优化技巧

​ 在介绍了Redis复制的种种细节后，现在我们可以来总结一下，在下面常见的场景中，何时使用部分复制，以及需要注意哪些问题

1、第一次建立复制

​ 此时全量复制不可避免，但仍有几点需要注意：如果主节点的数据量较大，应该尽量避开流量的高峰期，避免造成阻塞；如果有多个从节点需要建立对主节点的复制，可以考虑将几个从节点错开，避免主节点占带宽占用过大。此外，如果从节点过多，也可以调整主从复制的拓扑结构，由一主多从结构变为树状结构（中间的节点既是主节点的从节点，也是其从节点的主节点）；但使用树状结构应该谨慎：虽然主节点的直接从节点减少，降低了主节点的负担，但是多层从节点的延迟增大，数据一致性变差；且结构复杂，维护相当困难。

2、主节点重启

​ 主节点重启可以分为两种情况来讨论，一种故障导致宕机，另一种则是有计划的重启。

  • 主节点宕机

    主节点重启后，runid会发生变化，因此不能进行部分复制，只能全量复制

    实际上在主节点宕机的情况下，应进行故障转移处理，将其中的一个从节点升级为主节点，其他从节点从新的主节点进行复制；且故障转移应尽量的自动化，后面文章将要介绍哨兵便可以进行自动的故障转移

  • 安全重启：debug reload

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

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

    如下图所示，debug reload重启后runid和offset都未受影响：

    debug-reload

    但debug reload是一柄双刃剑：他会清空当前内存中的数据，重新从RBD文件中加载，这个过程导致主节点的阻塞，因此也需要谨慎

  • 从节点重启

    从节点宕机重启后，其保存的主节点的runid会丢失，因此即使再次执行salveof，也无法进行部分复制

  • 网络中断

    如果主从节点之间出现网络问题，造成短时间内网络中断，可以分为多种情况讨论。

    1. 网络问题时间极为短暂，只造成了短暂的丢包，主从节点都没有判定超时（为触发repl-timeout）；此时只需要通过REPLCONF ACK来补丢失的数据即可
    2. 网络问题时间很长，主从节点判断超时（触发repl-timeout），且丢失的数据过多，超过了复制积压缓冲区所能存储的范围；此时主从节点无法进行部分复制，只能进行全量复制。为了尽可能避免这种情况的发生，应该根据实际情况适当适当调整复制积压缓冲区的大小；此外及时发现并修复网络中断，也可以减少全量复制
    3. 介于前述两种情况之间，主从节点判断超时，且丢失的数据仍然都在复制积压缓冲区中；此时主从节点可以进行部分复制

5、复制相关的配置

​ 这一节总结一下与复制有关的配置，说明这些配置的作用，其作用的阶段，以及配置方法等；通过了解这些配置，一方面加深对Redis复制的了解，另一方面掌握这些配置的方法，可以优化Redis的使用，少走坑。

​ 配置大致可以分为主节点相关配置、从节点相关配置以及主从节点都有关的配置，下面分别说明。

1、与主从节点都有关的配置

​ 首先介绍最特殊的配置，他决定了该节点是主节点还是从节点：

  1. slaveof ：Redis启动时其作用；作用是建立复制关系，开启了该配置的Redis服务器在启动后成为从节点。该注释默认注释掉，即Redis服务器默认都是主节点
  2. repl-timeout 60：与各个阶段主从节点连接超时判断有关，见前面的介绍

2、主节点相关配置

  1. repl-diskless-sync no：作用于全量复制阶段，控制主节点是否使用diskless复制（无盘复制）。所谓diskless复制，是指在全量复制时，主节点不再先把数据写入RDB文件，而是直接写入slave的socket中，整个过程中不涉及硬盘；diskless复制在磁盘IO很慢而网速很快时更有优势。需要注意的是，截止Redis3.0，diskless复制处于试验阶段，默认是关闭的
  2. repl-diskless-sync-delay 5：该配置作用于全量复制阶段，当主节点使用diskless复制时，该配置决定主阶段向从节点发送之前停顿的时间，单位是秒；只有当diskless复制打开时有效，默认是5秒。之所以设置停顿时间，是基于一下两个考虑：
    1. 向slave的socket的传输一旦开始，新连接的slave只能等待当前数据传输结束后，才能开始新的数据传输
    2. 多个从节点有较大的的概率在短时间内建立主从复制
  3. client-output-buffer-limit slave 256MB 64MB 60：与全量复制阶段主节点的缓冲区大小有关，见前面介绍
  4. repl-disable-tcp-nodelay no：与命令传播阶段的延迟有关，见前面介绍
  5. masterauth ：与连接建立阶段的身份验证有关，见前面的介绍
  6. repl-ping-slave-period 10：与命令传播阶段主从节点的超时判断有关，见前面介绍
  7. repl-blacklog-size 1mb：复制积压缓冲区的大小，见前面介绍
  8. repl-backlog-ttl 3600：当主节点没有从节点时，复制积压缓冲区保留的时间，这样当断开的从节点重新连进来时，可以进行全量复制；默认3600s，如果设置为0，则永远不会释放复制积压缓冲区
  9. min-slaves-to-write 3 与min-slaves-max-lag 10：规定了主节点的最小从节点数目，及对应的最大延迟，见前面介绍

3、从节点相关配置

  1. slave-serve-stale-data yes：与从节点的数据陈旧时是否响应客户端命令有关，见前面介绍
  2. slave-read-only yes：从节点是否只读；默认是只读的。由于从节点开启写操作容易导致主从节点的数据不一致，因此该配置尽量不要修改

6、单机内存大小限制

​ 在深入学习Redis（2）：持久化一文中，降到了fork操作对Redis单机内存大小的限制。实际上在Redis的使用中，限制单机内存大小的因素非常之多，下面总结一下在主从复制中，单机内存过大可能造成的影响：

  1. 切主：当主节点宕机时，一种常见的容灾策略时间其中一个从节点提升为主节点，并将其他从节点挂在到新的主节点上，此时这些从节点只能进行全量复制；如果Redsi单机内存达到10GB，一个从节点的同步时间在几分钟的级别；如果从节点较多，恢复的速度会更慢。如果系统的读负载很高，而这段时间从节点无法提供服务，会对系统造成很大的压力
  2. 从库扩容：如果访问量突然增大，此时希望增加从节点分担读负载，如果数据量过大，从节点同步太慢，难以及时应对访问量的暴增
  3. 缓冲区溢出：上面1和2都是从节点可以正常同步的情形（虽然慢），但是如果数据量过大，导致全量复制阶段主节点的复制缓冲区溢出，从而导致复制中断，则主从节点的数据同步会全量复制->复制缓冲区溢出导致复制中断->重连->全量复制->复制缓冲区溢出导致复制中断....的循环
  4. 超时：如果数据量过大，全量复制阶段主节点fork+保存RDB文件耗时过大，从节点长时间接收不到数据触发超时，主从节点的数据同步同样可能陷入全量复制->超时导致复制中断->重连->全量复制->超时导致复制中断...的循环

​ 此外，主节点单机内存除了绝对量不能太大，其占用主机内存的比例也不应太大：最好只是用50%~65%的内存，剩下的内存留于执行bgsave命令和创建复制缓冲区等。

7、info Replication

​ 在Redis客户端通过info Replication可以查看与复制相关的状态，对于了解主从节点的当前状态，以及解决出现的问题都会有帮助

​ 主节点：
info-replication-master

​ 从节点：

info-replication-slave

​ 对于从节点，上半部分展示的是其作为从节点的状态， 从connected_slaves开始，展示的是其作为潜在的主节点状态。

​ info Replication中展示的大部分内容在前文中都已经讲述，这里不再详述