Emove

  • 首页
  • 归档
  • 分类
  • 标签

  • 搜索
context 反射 channel LRU BeanDefinition JVM 装饰者模式 MyBatis 快慢指针 归并排序 链表 hash表 栈 回溯 贪心 主从复制 二分查找 双指针 动态规划 AOF RDB 规范 BASE理论 CAP B树 RocketMQ Sentinel Ribbon Eureka 命令模式 访问者模式 迭代器模式 中介者模式 备忘录模式 解释器模式 状态模式 策略模式 职责链模式 模板方法模式 代理模式 享元模式 桥接模式 外观模式 组合模式 适配器模式 建造者模式 原型模式 工场模式 单例 UML 锁 事务 sql 索引

Redis主从复制关于应用中的问题

发表于 2020-04-12 | 分类于 Redis | 0 | 阅读次数 149

应用中的问题

​ 前文:在原文中,关于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中展示的大部分内容在前文中都已经讲述,这里不再详述

# context # 反射 # channel # LRU # BeanDefinition # JVM # 装饰者模式 # MyBatis # 快慢指针 # 归并排序 # 链表 # hash表 # 栈 # 回溯 # 贪心 # 主从复制 # 二分查找 # 双指针 # 动态规划 # AOF # RDB # 规范 # BASE理论 # CAP # B树 # RocketMQ # Sentinel # Ribbon # Eureka # 命令模式 # 访问者模式 # 迭代器模式 # 中介者模式 # 备忘录模式 # 解释器模式 # 状态模式 # 策略模式 # 职责链模式 # 模板方法模式 # 代理模式 # 享元模式 # 桥接模式 # 外观模式 # 组合模式 # 适配器模式 # 建造者模式 # 原型模式 # 工场模式 # 单例 # UML # 锁 # 事务 # sql # 索引
整数转罗马数字
最长公共前缀
  • 文章目录
  •   |  
  • 概览
林亦庭

林亦庭

less can be more

87 文章
11 分类
54 标签
RSS
Github
Creative Commons
© 2021 林亦庭
粤ICP备20029050号