精华内容
下载资源
问答
  • Redis的主从复制原理

    2018-08-12 16:40:08
    redis的主从复制原理 1、从库向主库发送sync命令,也就是从库向主库发送同步请求; 2、当主库接受到sync命令后,会执行bgsave命令(保存此刻主库的一个快照),创建一个RDB文件,创建RDB文件期间主库上的执行过的...

    redis的主从复制原理

    1、从库向主库发送sync命令,也就是从库向主库发送同步请求;
    2、当主库接受到sync命令后,会执行bgsave命令(保存此刻主库的一个快照),创建一个RDB文件,创建RDB文件期间主库上的执行过的命令都会被保存到缓冲区中;
    3、当主库执行完bgsave时,会向从库发送RDB文件,从库接受该文件并加载该文件,将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态;
    4、主库将缓冲区的所有写命令发给从库执行;
    5、至此可以认为redis主从建立成功,之后主库的每一个写命令都会传到从库上执行。
    复制原理说明:
    master创建RDB文件是通过一个子进程进行的,所以master依然可以处理客户端发来的请求。但这也导致了在保存RDB文件期间,“键空间”可能发生变化(譬如接收到一个客户端请求,执行”set name diaocow”命令),因此为了保证数据同步的一致性,master会在保存RDB文件期间,把接受到的这些可能变更数据库“键空间”的命令保存到缓冲区中。

    下图比较完整地反映出redis的主从建立过程示意图:
    Redis主从建立过程
    说明:
    redis目前的复制是异步的,只保证最终一致性,而不是强一致性。具体的可以理解为:主库上的写命令操作后传到从库再重现一遍,从库执行完后主从是完全同步的,这是最终一致性;如果主库上的写命令传到从库上执行成功后,主库上才会反馈该命令执行成功,那么这是强一致性。

    命令传播
    在上面的同步操作执行完毕后,主从库的状态就是一致的了,但这种一致并不是一致不变的。每当主服务器接收到一个写命令时,主服务器的数据就会发生改变,而从服务器并没有接收到该命令。所以为了保证主从的一致,需要主服务器将写命令传播到从服务器上,在从服务器上实现一遍,这样主从就始终一致了。

    主从断线后重连

    在redis2.8版本之前,主从断线后,实现主从重同步的方式就是从库向主库发送sync命令,主库生成RDB文件传到从库,从库应用该文件实现同步。这样的实现方式和最开始的主从建立方式一模一样。其实现方式可以用下图表示:
    redis2.8前的主从断线重连示意图
    但是这样实现重连的方式太低效了,从库实际上只需要将断开期间主库变化的数据同步起来即可,为了让从服务器补足一小部分缺失的数据,却要让主从重新执行依次sync命令,这种做法过于低效。
    为了解决旧版复制功能在处理断线重复制情况时的低效问题,redis从2.8开始使用PSYNC命令代替SYNC命令来执行复制时的同步操作。
    PSYNC命令具有完整重同步和部分重同步两种模式:
    ·完整重同步用于处理初次复制情况:完整重同步的执行步骤和sync的执行步骤基本是一样的。
    ·部分重同步则用于处理断线后重复制情况:当从服务器重新连接上主服务器时,如果条件允许,主服务器可以将连接断开期间执行过的写命令发送给从服务器,从服务器只要接收并执行这些写命令,就可以达到主服务器当前所处状态。
    下图可以形象地反映PSYNC命令下重复制过程:
    PSYNC命令下的重复制过程

    部分重同步的实现原理
    部分重同步功能主要由以下三个部分构成:
    ·主服务器的复制偏移量和从服务器的复制偏移量
    ·主服务器的复制积压缓冲区
    ·服务器的运行ID
    下面分别介绍这三个部分
    1、复制偏移量
    在复制过程中,主从服务器都会分别维护一个复制偏移量:
    ·主服务器每次向从服务器传播N个字节的数据时,就会将自己的复制偏移量的值加上N;
    ·从服务器每次收到主服务器传播来的N个字节的数据时,就将自己的复制偏移量的值加上N。
    例如下图中,主从服务器的偏移量都为10086:

    如果主服务器发送33字节的数据,那么主从的复制偏移量都更新为10119,如下图:

    如果在服务器发送33字节数据之前,从服务器A断线了,那么主服务器传播的数据只有B和C能够接收到,主服务器和从服务器B、C的复制偏移量都为10119,而A的偏移量为10086,如下图:

    假设从服务器A在断线之后就立即重新连接主服务器,并且成功。那么接下来A会向主服务器发送psync命令,报告A当前的复制偏移量为10086,那么这时,主服务器应该对从服务器执行完整重同步还是部分重同步呢?如果执行部分重同步的话,主服务器又如何补偿从服务器A在断线期间丢失的那部分数据呢?以上问题的答案都和复制积压缓冲区有关。
    2、复制积压缓冲区
    复制积压缓冲区是由主服务器维护的一个固定长度先进先出队列,默认大小为1MB。当主服务器进行命令传播时,它不仅会将写命令发送给所有从服务器,还会将写命令入队到复制积压缓冲区里。复制缓冲区里保存着一部分最近传播的写命令,并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量,大致如下图所示:

    当从服务器重新连上主服务器时,从服务器会通过psync命令将自己的复制偏移量发送给主服务器,主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作:
    ·如果偏移量之后的数据(也即是偏移量offset+1开始的数据)仍然存在于复制积压缓冲区里面,那么服务器将对从服务器执行部分重同步操作;
    ·相反,如果偏移量之后的数据已经不存在于复制积压缓冲区,那么主服务器将对从服务器执行完整重同步操作。
    所以,复制积压缓冲区的大小似乎相当重要,正确估算和设置复制积压缓冲区的大小非常重要。复制缓冲区的最小大小可以根据下面的公式估算:
    second * write_size_per_second
    second为从服务器断线后重连上主服务器所需的平均时间;write_size_per_second则是主服务器平均每秒产生的写命令数据量。为了安全起见,可以将复制积压缓冲区的大小设为:
    2 * second * write_size_per_second
    复制积压缓冲区的大小与参数repl-backlog-size有关。
    3、服务器运行ID
    除了复制偏移量和复制积压缓冲队列,实现重同步还需要服务器运行ID(run
    ID)。每个redis服务器,不论主服务器还是从服务器都有自己的运行ID,运行ID在服务器启动时自动生成,由40个随机的十六进制字符组成。
    当从服务器对主服务器进行初次复制时,主服务器会将自己的运行ID传送给从服务器。当从服务器断线并重新连上一个主服务器时,从服务器将向当前连接的主服务器发送之前保存的运行ID:
    ·如果从服务器保存的ID和当前连接的主服务器的运行ID相同,那么说明从服务器断线之前复制的就是当前连接的这个主服务器,主服务器可以尝试执行部分重同步操作;
    ·如果从服务器保存的ID和当前连接的主服务器的运行ID不同,则从服务器断线之前复制的不是当前连接的这个主服务器,主服务器就将对从服务器执行完整重同步操作。

    PSYNC命令的具体实现

    PSYNC命令的调用方法有两种:
    ·如果从服务器以前没有复制过任何主服务器,或者之前执行过slaveof no one命令,那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ? -1命令,主动请求主服务器进行完整重同步(因为这时不可能执行部分重同步);
    ·如果从服务器之前已复制过某个主服务器,那么从服务器在开始一次新的复制时将向主服务器发送PSYNC 命令。runid是上一次复制的主服务器ID,而offset则是从服务器当前的复制偏移量。接收到该命令的主服务器通过这两个参数来判断执行何种同步操作。
    根据情况,接收到PSYNC命令的主服务器会向从服务器返回以下三种回复之一:
    ·主服务器返回:+FULLRESYNC 。那么表示主服务器将与从服务器执行完整重同步操作,runid是这个主服务器的运行ID,从服务器会将这个ID保存下来,在下次发送PSYNC命令时使用;而offset则是主服务器当前的偏移量,从服务器会将这个值作为自己的初始化偏移量。
    ·主服务器返回:+CONTINUE。那么表示主服务器将与从服务器执行部分重同步操作,从服务器只要等着主服务器将自己缺少的那部分数据发送过来即可。
    ·主服务器返回:-ERR。表示主服务器版本低于2.8,它识别不了PSYNC命令。之后从服务器将发送sync命令,与主服务器执行完整重同步操作。

    注意:如果是从库宕机了,那么恢复后直接就是完全同步;如果仅是主从掉线,从库还在线,那么则视情况而定。

    借鉴自《redis设计与实现(第二版)》

    展开全文
  • redis的主从复制原理

    2019-09-29 14:19:43
    和MySQL主从复制的原因一样,Redis虽然读取写入速度都特别快,但是也会产生读压力特别大情况。为了分担读压力,Redis支持主从复制Redis主从复制可以根据是否是全量分为全量同步和增量同步。 2. 旧版复制功能...

    1. 前言

            和MySQL主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis主从复制可以根据是否是全量分为全量同步和增量同步。

    2. 旧版复制功能实现

    redis复制功能分为同步和命令传播两种操作:

    (1)同步操作负责将从数据库的状态更新为和主数据库状态一致

    (2)命令传播操作则用于当主服务器状态修改时,让从服务器状态重新回到一致

    2.1 同步

    同步操作由sync操作完成:

    (1)从服务器向主服务器发送sync命令

    (2)收到sync命令的主服务器执行BGSAVE命令,生成RDB文件,并使用一个缓冲区缓存生成RDB期间所有的写命令

    (3)RDB生成完成时,发送RDB给从服务器,从服务器载入RDB,状态和主服务器一致

    (4)然后主服务器将缓冲区中的写命令全部传给从服务器,状态一致

    2.2 命令传播

           同步操作完成后,主从状态一致,但是每当客户端向主服务器执行写命令时,主服务器会修改,和从服务器状态不一致,为了让主从状态重新回到一致,主服务器会发送写命令给从服务器,让从服务器回到和主服务器一致的状态。

    2.3 旧版复制功能的不足之处

    在redis2.8之前,主从服务器的复制会分为两种:

    (1)初次复制:从服务器以前从没复制过其他主服务器,或者从服务器的主服务器换了

    (2)断线后复制:处于命令传播阶段的主从服务器,发生了断线,重新连上后,从服务器继续复制主服务器

    为什么说效率低呢?因为在旧版复制中,断线重新连接后进行的复制,是通过sync命令实现的,而之前说了sync命令实现是主服务器重新生成RDB文件,发送给从服务器,重新生成RDB是很低效的,而且主服务器生成RDB时是阻塞状态的,所以旧版复制是低效率的。

    3. 新版复制功能实现

    为了解决旧版复制低效问题,新版复制采用了psync命令来代替sync命令,psync命令具有完全重同步和部分重同步:

    (1)完全重同步:和上面的sync一样

    (2)部分重同步:专门用于负责处理断线后重连,通过重连后只执行断线期间的写命令而不是全同步来达到高效

    3.1 部分重同步实现

    部分重同步实现由以下三部分构成:

    (1)主服务器的复制偏移量和从服务器的复制偏移量

    (2)主服务器的复制积压缓冲区

    (3)服务器运行ID

    3.1.1 复制偏移量

    主从服务器都会维持一个复制偏移量:

    • 主服务器每次向从服务器发送n个字节的命令,就在自己复制偏移量加n
    • 从服务器每次接收到n个字节数据,就在自己复制偏移量加n

           例如,主从服务器当前偏移是100,主向从服务器发送33个字节命令,那么主从此时的复制偏移量都是133,所以判断主从当前状态是否一致,可以通过复制偏移量来判断:复制偏移量如果一样,就代表状态一致,否则不一致。如果断线时,从服务器因为收不到命令,而主服务器一直发送命令,这时的偏移量肯定不一样,所以状态不一致,那么如果让中间漏掉的命令重新传给从服务器呢,这和积压缓冲区有关。

    3.1.2 复制积压缓冲区

    复制积压缓冲区是一个主服务器维护的固定长度的先进先出队列。每当主服务器进行命令传播时,它不仅将命令传给从服务器,还会将命令写入到缓冲区:

                  

     

    如上图所示,就是一个积压缓冲区的现状,当从服务器重连后,向主服务器发送一个psycn命令,同时会将从服务器当前的复制偏移量(offset)带过去,主服务器会根据从服务器的offset,来决定是全同步还是部分同步:

    (1)如果从服务器的offset是10086,那么此时要复制的偏移量应该是从10087开始,在缓冲区存在,将从10087开始往后所有数据都发送给从服务器,所以执行的是部分重同步

    (2)相反的,如果不存在,就需要进行全同步了!

    如下图:如果进行部分重同步,就向从服务器发送一个CONTINUE回复。

                                      

    3.1.3 服务器运行ID

    除了复制偏移量和复制积压缓冲区之外,实现部分重同步还需要用到服务器运行ID(run ID):

    • 每个Redis服务器,不论主服务器还是从服务,都会有自己的运行ID

           当从服务器对主服务器进行初次复制时,主服务器会将自己的运行ID传送给从服务器,而从服务器则会将这个运行ID保存起来(注意哦,是从服务器保存了主服务器的ID)。

    当从服务器断线并重新连上一个主服务器时,从服务器将向当前连接的主服务器发送之前保存的运行ID:

    • 如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同,那么说明从服务器断线之前复制的就是当前连接的这个主服务器,主服务器可以继续尝试执行部分重同步操作;
    • 相反地,如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同,那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器,主服务器将对从服务器执行完整重同步操作。

    4. 心跳机制

           在命令传播阶段时,从服务器每隔一秒都会向主服务器发送命令:REPLCONF ACK <replication_offset>,每发送一次这个命令从服务器都会向主服务器报告一次自己的复制偏移量,如果超过一秒,就代表主从连接出了问题。那此时尽管主服务器发送给从服务器的SET key value丢失了。也无所谓,主服务器马上就知道了,但是要注意,这时的偏移量不一致,并不是断线导致的,而是以为主服务器传给从服务器的命令丢失了,连接情况还是正常的,这种称之为命令丢失

     

                                                          

     

    转载于:https://www.cnblogs.com/Booker808-java/p/9866155.html

    展开全文
  • Redis的主从复制原理以及实现 前言: 上一个博客讲到Redis的数据持久化,如果说Redis节点宕机了,那么我们的系统就无法对数据在redis进行缓存处理,这个可以通过Redis的哨兵模式或者集群模式解决,本篇博客先从Redis...

    Redis的主从复制原理以及实现

    前言: 上一个博客讲到Redis的数据持久化,如果说Redis节点宕机了,那么我们的系统就无法对数据在redis进行缓存处理,这个可以通过Redis的哨兵模式或者集群模式解决,本篇博客先从Redis的主从复制说起,后续会发布哨兵模式和集群模式的实现。
    主从结构图:
    主从结构图
    主从的特点:

    1. 一个主数据库(master)下面可以有多个从数据库(slave);
    2. 从数据库(slave)也可以拓展多个从数据库(slave),形成了强大的多级服务器集群架构即master->slave->slave模式;
    3. 一主多从实现了读写分离,master用于写,slave用于读操作,因为实际生产的环境读操作是远远高于写操作的;
    4. master以非阻塞的方式同步数据至slave,同时master会继续处理client的读写请求。

    主从复制的原理:
    全量同步(init):
    当slave从数据库在启动成功之后会向主数据库发送一个ping包,通知主数据库,然后主数据库把rdb文件发送到从数据库,当从数据库接收完毕之后会把该rdb文件下载到硬盘上,然后再把rdb的数据加载到内存中。
    增量同步:
    当从数据库启动完成并完成第一次的全量同步之后,之后的同步都是增量形式进行同步,也就是说,当主数据库有写的操作后,从数据库也会执行对应写的命令。
    注意:使用主从复制一定要开启数据库的持久化机制。

    搭建redis的主从复制其实只用修改从节点的redis配置,下面为大家罗列出需要修改的地方以及参数说明。
    本人搭建的一主一从,电脑容量有限
    在这里插入图片描述
    我们把192.168.181.129作为从节点,现在对129的数据库redis.conf配置进行修改

    ################################# REPLICATION #################################
    
    #
    #   +------------------+      +---------------+
    #   |      Master      | ---> |    Replica    |
    #   | (receive writes) |      |  (exact copy) |
    #   +------------------+      +---------------+
    #  从数据的配置 主节点IP 端口
    # replicaof <masterip> <masterport>
    replicaof 192.168.181.129 6379
    
    # 如果主数据库定义了密码,这里配置,我没有设置密码所以这个不配
    # masterauth <master-password>
    
    #当从库同主机失去连接或者复制正在进行,从机库有两种运行方式:1) 如果slave-serve-stale-data设置为
    #yes(默认设置),从库会继续响应客户端的请求。2) 如果slave-serve-stale-data设置为no,
    #INFO,replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG,SUBSCRIBE, UNSUBSCRIBE,
    #PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB,COMMAND, POST, HOST: and LATENCY命令之外的任何请求
    #都会返回一个错误”SYNC with master in progress”。
    replica-serve-stale-data yes
    
    #从数据库只读模式开启
    replica-read-only yes
    
    # 是否使用socket方式复制数据。目前redis复制提供两种方式,disk和socket。如果新的slave连上来或者
    #重连的slave无法部分同步,就会执行全量同步,master会生成rdb文件。有2种方式:disk方式是master创建
    #一个新的进程把rdb文件保存到磁盘,再把磁盘上的rdb文件传递给slave。socket是master创建一个新的进
    #程,直接把rdb文件以socket的方式发给slave。disk方式的时候,当一个rdb保存的过程中,多个slave都能
    #共享这个rdb文件。socket的方式就的一个个slave顺序复制。在磁盘速度缓慢,网速快的情况下推荐用socket方式。
    repl-diskless-sync no
    
    #diskless复制的延迟时间,防止设置为0。一旦复制开始,节点不会再接收新slave的复制请求直到下一个rdb传输。所以最好等待一段时间,等更多的slave连上来
    repl-diskless-sync-delay 5
    

    设置好之后保存并退出然后重启从数据库的服务。

    /etc/init.d/redis_init_script stop
    /etc/init.d/redis_init_script start
    

    查看进程是否启动成功:
    在这里插入图片描述主数据库查看主从信息如下:
    在这里插入图片描述
    从数据库查看的信息如下:
    在这里插入图片描述
    下面进行主从复制测试:
    主从数据库没数据
    在这里插入图片描述
    主数据库插入成功:
    在这里插入图片描述
    这里从数据库复制成功:
    在这里插入图片描述
    主从复制搭建完成!
    【Redis-Series】:
    一、Linux生产环境安装部署Redis
    二、Redis的两种持久化机制RDB/AOF
    四、Redis哨兵模式讲解及SpringBoot配置(图文详解)
    五、Redis-Cluster集群模式讲解及SpringBoot配置(图文详解)
    六、Redis击穿、穿透、雪崩讲解以及解决方案

    展开全文
  • redis 的主从复制原理能介绍一下么?redis 的哨兵原理能介绍一下么? 面试官心理分析 其实问这个问题,主要是考考你,redis 单机能承载多高并发?如果单机扛不住如何扩容扛更多的并发?redis 会不会挂?既然 redis...

    面试题

    如何保证 redis 的高并发和高可用?redis 的主从复制原理能介绍一下么?redis 的哨兵原理能介绍一下么?

    面试官心理分析

    其实问这个问题,主要是考考你,redis 单机能承载多高并发?如果单机扛不住如何扩容扛更多的并发?redis 会不会挂?既然 redis 会挂那怎么保证 redis 是高可用的?

    其实针对的都是项目中你肯定要考虑的一些问题,如果你没考虑过,那确实你对生产系统中的问题思考太少。

    面试题剖析

    如果你用 redis 缓存技术的话,肯定要考虑如何用 redis 来加多台机器,保证 redis 是高并发的,还有就是如何让 redis 保证自己不是挂掉以后就直接死掉了,即 redis 高可用。

    由于此节内容较多,因此,会分为两个小节进行讲解。

    redis 实现高并发主要依靠主从架构,一主多从,一般来说,很多项目其实就足够了,单主用来写入数据,单机几万 QPS,多从用来查询数据,多个从实例可以提供每秒 10w 的 QPS。

    如果想要在实现高并发的同时,容纳大量的数据,那么就需要 redis 集群,使用 redis 集群之后,可以提供每秒几十万的读写并发。

    redis 高可用,如果是做主从架构部署,那么加上哨兵就可以了,就可以实现,任何一个实例宕机,可以进行主备切换。

     

    展开全文
  • Redis 的主从复制原理能介绍一下么?Redis 的哨兵原理能介绍一下么?   面试题 如何保证 redis 的高并发和高可用?redis 的主从复制原理能介绍一下么?redis 的哨兵原理能介绍一下么? 面试官心理分析 其实...
  • redis的主从复制原理能介绍一下么?redis的哨兵原理能介绍一下么? 面试题 如何保证Redis的高并发和高可用?redis的主从复制原理能介绍一下么?redis的哨兵原理能介绍一下么? 面试官心里分析 其实问这个问题,...
  • redis 的主从复制原理能介绍一下么?redis 的哨兵原理能介绍一下么? 面试官心理分析 其实问这个问题,主要是考考你,redis 单机能承载多高并发?如果单机扛不住如何扩容扛更多的并发?redis 会不会挂?既然 redis...
  • redis 的主从复制原理能介绍一下么?redis 的哨兵原理能介绍一下么? 面试官心理分析 其实问这个问题,主要是考考你,redis 单机能承载多高并发?如果单机扛不住如何扩容扛更多的并发?redis 会不会挂?既然 redis...
  • Redis 的主从复制原理能介绍一下么?Redis 的哨兵原理能介绍一下么?主从架构下的数据部分复制? 考虑如何用 redis 来加多台机器,保证 redis 是高并发的,如何让 redis 保证自己不是挂掉以后就直接死掉了,即 redis...
  • 编程界小学生一、为什么要主从复制二、主备和主从1、主备2、主从三、主从三种方式1、同步阻塞1.1、原理图1.2、优缺点2、异步非阻塞2.1、原理图2.2、优缺点3、同步阻塞MQ3.1、原理图3.2、优缺点四、主从原理及实战1...
  • 主从复制,是指将一台Redis服务器数据,复制到其他的Redis服务器。前者称为主节点(master),后者称为从节点(slave);数据复制是单向,只能由主节点到从节点。 默认情况下,每台Redis服务器都是主节点;且一个...
  • 从库配置:slaceof 主库IP主库端口在没有SLAVEOF之前,三个机器处于都是master角色,但是当执行SLAVEOF之后,主机角色就是role,从机角色就是slave,执行SLAVEOF之后,会把主机上所有数据按照主从复制的原则...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,597
精华内容 638
关键字:

redis的主从复制原理

redis 订阅