redis主从原理_scrapy redis 使用redis原理 - CSDN
  • 一、单机的问题:1、机器故障:导致redis不可用2、容量瓶颈:容量不能水平扩展3、OPS瓶颈:一台机器的网络带宽总是有限的,如果能够分配到多台机器,可以有效解决QPS问题二、主从复制的作用1、数据副本:多一份数据...

    一、单机的问题:

    1、机器故障:导致redis不可用

    2、容量瓶颈:容量不能水平扩展

    3、OPS瓶颈:一台机器的网络带宽总是有限的,如果能够分配到多台机器,可以有效解决QPS问题

    二、主从复制的作用

    1、数据副本:多一份数据副本,保证redis高可用

    2、扩展性能:如容量、QPS等

    三、主从复制特点

    1、一个master可以有多个slave

    2、一个slave只能有一个master

    3、数据流向是单向的,master到slave

    四、实现主从复制的两种方式

    1、slaveof命令:

    A、在运行的时候执行

    B、取消:slaveof no one

    2、配置:

    A、在启动之前配置,重新配置需要重启,可以统一配置

    B、配置项:

    slaveof ip port

    slave-read-only yes #配置只读

    五、redis主从复制的一些概念

    1、runid,每次启动redis都会分配一个id,重启之后runid变化。 


    2、offset,请求master数据额偏移量,部分复制的时候,根据这个进行复制


    3、repl_backlog_size,复制缓冲区大小,默认为1M,部分复制的时候,如果offset在这个范围内,则开始部分复制,否者要进行全量复制。可以修改这个大小以达到更好地复制机制。

    例如我们计算平均网络断开时间,在算上单位时间内产生的数据数量,两个相乘,就大概得到了我们需要的复制缓冲区大小。可以在这个基础上增加或者减少。

    六、全量复制

    1、全量复制的原理,过程:


    ①slave发送psync,由于是第一次复制,不知道master的runid,自然也不知道offset,所以发送psync ? -1

    ②master收到请求,发送master的runid和offset给从节点。

    ③从节点slave保存master的信息

    ④主节点bgsave保存rdb文件

    ⑤主机点发送rdb文件

    并且在④和⑤的这个过程中产生的数据,会写到复制缓冲区repl_back_buffer之中去。

    ⑥主节点发送上面两个步骤产生的buffer到从节点slave

    ⑦从节点清空原来的数据,如果它之前有数据,那么久会清空数据

    ⑧从节点slave把rdb文件的数据装载进自身。

    redis中文网站全量复制介绍

    2、全量复制的开销:

    ①bgsave时间

    ②rdb文件网络传输时间

    ③从节点清空数据的

    ④从节点加载rdb的时间

    ⑤可能的aof重写时间,这是针对从节点,例如开启了aof之后,从节点添加buffer数据时候,可能需要aof重写

    基于上面的原因,有的情况下不适合使用全量复制,例如网络抖动之后,从节点只需要传送一部分数据,不需要传送全部数据,redis2.8之后实现了部分复制功能

    七、部分复制

    原理:


    ①假设发送网络抖动或者别的情况,暂时失去了连接

    ②这个时候,master还在继续往buffer里面写数据

    ③slave重新连接上了master

    ④slave向master发送自己的offset和runid

    ⑤master判断slave的offset是否在buffer的队列里面,如果是,那就返回continue给slave,否则需要进行全量复制(因为这说明已经错过了很多数据了)

    ⑥master发送从slave的offset开始到缓冲区队列结尾的数据给slave

    redis中文完整对于部分复制的介绍

    八、redis故障处理

    如果master重启了之后,slave再去读取就会读取到一个新的runid,所以就需要全量复制。这个时候最好能用另外一种方式,例如把slave作为晋升为主节点这种自动故障转移机制。redis做了这个功能,例如redis sentinel

    九、redis复制常见的问题

    1、读写分离:

    好处:流量可以分摊到不同的从节点上

    可能遇到的问题:

    ①复制数据的延迟:例如从节点发生阻塞,就会到值复制数据的延迟

    ②读到过期的数据

    ③从节点也有可能发生故障

    2、配置不一致

    例如maxmemory不一致,容易丢失数据,或者发生诡异的情况

    数据结构优化参数(例如has-max-ziplist-entries):会出现内存不一致的情况

    3、规避全量复制

    ①第一次全量复制:第一次不可避免,但是我们可以使用小的主节点,或者在半夜低峰的时刻做全量复制

    ②节点运营的ID不匹配:例如主节点重启,runid就会变化,我们可以使用自动故障转移,例如哨兵或者集群

    ③复制积压缓冲区不足:网络中断,部分复制功能无法满足,这个时候可以增大复制缓冲区配置rep_backlog_size。

    4、规避复制风暴

    ①单主节点复制风暴:由于主节点从起,多个从节点要复制,会产生复制风暴,解决办法是:更换复制0拓扑

    ②单机器复制风暴:由于多个主节点都部署在同一个机器上面,机器宕机后需要大量的全量复制,解决办法是:主节点分配到多台机器上面或者使用一些高可用架构,讲从节点晋升为主节点


    展开全文
  • Redis主从复制原理

    2018-08-30 09:34:29
    一、主从复制概述 从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master),后者称为从节点(slave);数据的复制是单向的,只能由主节点到从节点。 默认情况下,每台Redis服务器都...

    一、主从复制概述

    从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master),后者称为从节点(slave);数据的复制是单向的,只能由主节点到从节点。
    默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。

    主从复制的作用

    数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。

    故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。

    负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。

    高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。

    二、如何使用主从复制

    为了更直观的理解主从复制,在介绍其内部原理之前,先说明我们需要如何操作才能开启主从复制。

    1. 建立复制

    需要注意,主从复制的开启,完全是在从节点发起的;不需要我们在主节点做任何事情。
    从节点开启主从复制,有3种方式:
    (1)配置文件
    在从服务器的配置文件中加入:slaveof <masterip> <masterport>
    (2)启动命令
    redis-server启动命令后加入 :slaveof <masterip> <masterport>
    (3)客户端命令

    Redis服务器启动后,直接通过客户端执行命令:
    slaveof <masterip> <masterport>,则该Redis实例成为从节点。

    上述3种方式是等效的,下面以客户端命令的方式为例,看一下当执行了slaveof后,Redis主节点和从节点的变化。

    实例

    准备工作:启动两个节点

    方便起见,实验所使用的主从节点是在一台机器上的不同Redis实例,其中主节点监听6379端口,从节点监听6380端口;从节点监听的端口号可以在配置文件中修改:
    这里写图片描述
    启动后可以看到:
    这里写图片描述
    两个Redis节点启动后(分别称为6379节点和6380节点),默认都是主节点。

    建立复制
    此时在6380节点执行slaveof命令,使之变为从节点:

    这里写图片描述

    观察效果
    1、下面验证一下,在主从复制建立后,主节点的数据会复制到从节点中。
    (1)首先在从节点查询一个不存在的key
    这里写图片描述
    (2)然后在主节点中增加这个key:
    这里写图片描述
    (3)此时在从节点中再次查询这个key,会发现主节点的操作已经同步至从节点:
    这里写图片描述
    (4)然后在主节点删除这个key:
    这里写图片描述
    (5)此时在从节点中再次查询这个key,会发现主节点的操作已经同步至从节点:
    这里写图片描述

    3. 断开复制

    通过slaveof 命令建立主从复制关系以后,可以通过slaveof no one断开。需要注意的是,从节点断开复制后,不会删除已有的数据,只是不再接受主节点新的数据变化。
    从节点执行slaveof no one后,打印日志如下所示;可以看出断开复制后,从节点又变回为主节点。
    这里写图片描述

    三、主从复制的实现原理

    主从复制过程大体可以分为3个阶段:连接建立阶段(即准备阶段)、数据同步阶段、命令传播阶段;下面分别进行介绍。

    1. 连接建立阶段

    该阶段的主要作用是在主从节点之间建立连接,为数据同步做好准备。
    步骤1:保存主节点信息

    从节点服务器内部维护了两个字段,即masterhost和masterport字段,用于存储主节点的ip和port信息。

    需要注意的是,slaveof是异步命令,从节点完成主节点ip和port的保存后,向发送slaveof命令的客户端直接返回OK,实际的复制操作在这之后才开始进行。

    步骤2:建立socket连接

    从节点每秒1次调用复制定时函数replicationCron(),如果发现了有主节点可以连接,便会根据主节点的ip和port,创建socket连接。如果连接成功,则:
    从节点:为该socket建立一个专门处理复制工作的文件事件处理器,负责后续的复制工作,如接收RDB文件、接收命令传播等。
    主节点:接收到从节点的socket连接后(即accept之后),为该socket创建相应的客户端状态,并将从节点看做是连接到主节点的一个客户端,后面的步骤会以从节点向主节点发送命令请求的形式来进行。

    步骤3:发送ping命令

    从节点成为主节点的客户端之后,发送ping命令进行首次请求,目的是:检查socket连接是否可用,以及主节点当前是否能够处理请求。
    从节点发送ping命令后,可能出现3种情况:
    (1)返回pong:说明socket连接正常,且主节点当前可以处理请求,复制过程继续。
    (2)超时:一定时间后从节点仍未收到主节点的回复,说明socket连接不可用,则从节点断开socket连接,并重连。
    (3)返回pong以外的结果:如果主节点返回其他结果,如正在处理超时运行的脚本,说明主节点当前无法处理命令,则从节点断开socket连接,并重连。

    步骤4:身份验证

    如果从节点中设置了masterauth选项,则从节点需要向主节点进行身份验证;没有设置该选项,则不需要验证。从节点进行身份验证是通过向主节点发送auth命令进行的,auth命令的参数即为配置文件中的masterauth的值。
    如果主节点设置密码的状态,与从节点masterauth的状态一致(一致是指都存在,且密码相同,或者都不存在),则身份验证通过,复制过程继续;如果不一致,则从节点断开socket连接,并重连。

    步骤5:发送从节点端口信息

    身份验证之后,从节点会向主节点发送其监听的端口号(前述例子中为6380),主节点将该信息保存到该从节点对应的客户端的slave_listening_port字段中;该端口信息除了在主节点中执行info Replication时显示以外,没有其他作用。

    2、数据同步阶段

    主从节点之间的连接建立以后,便可以开始进行数据同步,该阶段可以理解为从节点数据的初始化。具体执行的方式是:从节点向主节点发送psync命令(Redis2.8以前是sync命令),开始同步。
    数据同步阶段是主从复制最核心的阶段,根据主从节点当前状态的不同,可以分为全量复制和部分复制,下面会有一章专门讲解这两种复制方式以及psync命令的执行过程,这里不再详述。
    需要注意的是,在数据同步阶段之前,从节点是主节点的客户端,主节点不是从节点的客户端;而到了这一阶段及以后,主从节点互为客户端。原因在于:在此之前,主节点只需要响应从节点的请求即可,不需要主动发请求,而在数据同步阶段和后面的命令传播阶段,主节点需要主动向从节点发送请求(如推送缓冲区中的写命令),才能完成复制。

    3. 命令传播阶段

    数据同步阶段完成后,主从节点进入命令传播阶段;在这个阶段主节点将自己执行的写命令发送给从节点,从节点接收命令并执行,从而保证主从节点数据的一致性。
    在命令传播阶段,除了发送写命令,主从节点还维持着心跳机制:PING和REPLCONF ACK。由于心跳机制的原理涉及部分复制,因此将在介绍了部分复制的相关内容后单独介绍该心跳机制。

    延迟与不一致

    需要注意的是,命令传播是异步的过程,即主节点发送写命令后并不会等待从节点的回复;因此实际上主从节点之间很难保持实时的一致性,延迟在所难免。数据不一致的程度,与主从节点之间的网络状况、主节点写命令的执行频率、以及主节点中的repl-disable-tcp-nodelay配置等有关。
    repl-disable-tcp-nodelay no:该配置作用于命令传播阶段,控制主节点是否禁止与从节点的TCP_NODELAY;默认no,即不禁止TCP_NODELAY。当设置为yes时,TCP会对包进行合并从而减少带宽,但是发送的频率会降低,从节点数据延迟增加,一致性变差;具体发送频率与Linux内核的配置有关,默认配置为40ms。当设置为no时,TCP会立马将主节点的数据发送给从节点,带宽增加但延迟变小。
    一般来说,只有当应用对Redis数据不一致的容忍度较高,且主从节点之间网络状况不好时,才会设置为yes;多数情况使用默认值no。

    后面一篇继续延续:Redis主从复制原理(2)

    展开全文
  • Redis主从同步原理-SYNC

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

    原文地址:https://blog.csdn.net/sk199048/article/details/50725369

    和MySQL主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,下图为级联结构。 

    Redis主ä»ç»æ 

     Redis主从复制可以根据是否是全量分为全量同步和增量同步。

    1 全量同步
      Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下: 
      1)从服务器连接主服务器,发送SYNC命令; 
      2)主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令; 
      3)主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令; 
      4)从服务器收到快照文件后丢弃所有旧数据,载入收到的快照; 
      5)主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令; 
      6)从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令; 

     

     Rediså¨éåæ­¥è¿ç¨

    完成上面几个步骤后就完成了从服务器数据初始化的所有操作,从服务器此时可以接收来自用户的读请求。

    2 增量同步
      Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 
    增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。

    3 Redis主从同步策略
      主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。redis 策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。

    4 其他
    Redis 2.8以后提供了PSYNC优化了断线重连的效率 
    http://blog.csdn.net/sk199048/article/details/77922589

    参考:
    [1] 《Redis IN ACTION》 
    [2] http://blog.csdn.net/houjixin/article/details/27680183 
    [3] http://daoluan.net/blog/2014/04/22/decode-redis-replication/

     

    展开全文
  • Sentinel(哨兵)的来由书接上文,我们学习了redis的replication的原理,我们这一章来讨论一下redis主从策略的高可用性。这个哨兵的插件是我们redis里面集成了的(部署简单略),哨兵会监控主从的各个节点状态,当主...

    Sentinel(哨兵)的来由

    书接上文,我们学习了redis的replication的原理,我们这一章来讨论一下redis主从策略的高可用性。这个哨兵的插件是我们redis里面集成了的(部署简单略),哨兵会监控主从的各个节点状态,当主节点被视为不可用时,那么,哨兵之间或进行“投票协商”进行判刑master的死亡,并且从slave中选举出新的master。这就是哨兵在redis主从结构中的重要作用。



    Redis 2.8版开始正式提供名为Sentinel的主从切换方案,Sentinel用于管理多个Redis服务器实例,主要负责三个方面的任务:
        1. 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
        2. 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
        3. 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。

    Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。

    一般集群数量为基数策略,原因是有一个值quorum(sentinel集群认为master宕机的数量),这个值用来跟majority来比较的,当quorum>=majority认为master节点宕机。majority就是我们所谓的集群基数标准(1主2从:2,1主3从:2)。这也能实现集群利用率最大化。

    启动Sentinel
    使用--sentinel参数启动,并必须指定一个对应的配置文件,系统会使用配置文件来保存 Sentinel 的当前状态, 并在 Sentinel 重启时通过载入配置文件来进行状态还原。
    /src/ redis-sentinel sentinel.conf
    使用TCP端口26379,可以使用redis-cli或其他任何客户端与其通讯。
    如果启动 Sentinel 时没有指定相应的配置文件, 或者指定的配置文件不可写(not writable), 那么 Sentinel 会拒绝启动。
    配置Sentinel

    Sentinel.conf详解


    1. ##sentinel实例之间的通讯端口  
    2. ##redis-0  
    3. port 26379  
    4. ##sentinel需要监控的master信息:<mastername> <masterIP> <masterPort> <quorum>  
    5. ##<quorum>应该小于集群中slave的个数,只有当至少<quorum>个sentinel实例提交"master失效"  
    6. ##才会认为master为O_DWON("客观"失效)  
    7. sentinel monitor def_master 127.0.0.1 6379 2  
    8.   
    9. sentinel auth-pass def_master 012_345^678-90  
    10.   
    11. ##master被当前sentinel实例认定为“失效”的间隔时间  
    12. ##如果当前sentinel与master直接的通讯中,在指定时间内没有响应或者响应错误代码,那么  
    13. ##当前sentinel就认为master失效(SDOWN,“主观”失效)  
    14. ##<mastername> <millseconds>  
    15. ##默认为30秒  
    16. sentinel down-after-milliseconds def_master 30000  
    17.   
    18. ##当前sentinel实例是否允许实施“failover”(故障转移)  
    19. ##no表示当前sentinel为“观察者”(只参与"投票".不参与实施failover),  
    20. ##全局中至少有一个为yes  
    21. sentinel can-failover def_master yes  
    22.   
    23. ##当新master产生时,同时进行“slaveof”到新master并进行“SYNC”的slave个数。  
    24. ##默认为1,建议保持默认值  
    25. ##在salve执行salveof与同步时,将会终止客户端请求。  
    26. ##此值较大,意味着“集群”终止客户端请求的时间总和和较大。  
    27. ##此值较小,意味着“集群”在故障转移期间,多个salve向客户端提供服务时仍然使用旧数据。  
    28. sentinel parallel-syncs def_master 1  
    29.   
    30. ##failover过期时间,当failover开始后,在此时间内仍然没有触发任何failover操作,  
    31. ##当前sentinel将会认为此次failoer失败。  
    32. sentinel failover-timeout def_master 900000  
    33.   
    34. ##当failover时,可以指定一个“通知”脚本用来告知系统管理员,当前集群的情况。  
    35. ##脚本被允许执行的最大时间为60秒,如果超时,脚本将会被终止(KILL)  
    36. ##脚本执行的结果:  
    37. ## 1    -> 稍后重试,最大重试次数为10;   
    38. ## 2    -> 执行结束,无需重试  
    39. ##sentinel notification-script mymaster /var/redis/notify.sh  
    40.   
    41. ##failover之后重配置客户端,执行脚本时会传递大量参数,请参考相关文档  
    42. # sentinel client-reconfig-script <master-name> <script-path>  

    坑点:

    min-slaves-to-write 3

    min-slaves-max-lag 10

    至多有3个slave延迟同步不能超过10秒,如果一旦触发master不会再接收请求(可以在client端做处理,比如延时队列,持久化磁盘等)

    主观下线和客观下线
        1. 主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
        2. 客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。
    客观下线条件只适用于主服务器: 对于任何其他类型的 Redis 实例, Sentinel 在将它们判断为下线前不需要进行协商, 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。
    只要一个 Sentinel 发现某个主服务器进入了客观下线状态, 这个 Sentinel 就可能会被其他 Sentinel 推选出, 并对失效的主服务器执行自动故障迁移操作。
    每个Sentinel实例都执行的定时任务
        1. 每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
        2. 如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是: +PONG 、 -LOADING 或者 -MASTERDOWN 。
        3. 如果一个主服务器被标记为主观下线, 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
        4. 如果一个主服务器被标记为主观下线, 并且有足够数量的 Sentinel (至少要达到配置文件指定的数量)在指定的时间范围内同意这一判断, 那么这个主服务器被标记为客观下线。
        5. 在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时, Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
        6. 当没有足够数量的 Sentinel 同意主服务器已经下线, 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时, 主服务器的主管下线状态就会被移除。
    Sentinel API
    有两种方式可以与Sentinel进行通讯:指令、发布与订阅。
        Sentinel命令
           PING :返回 PONG 。
           SENTINEL masters :列出所有被监视的主服务器,以及这些主服务器的当前状态;
           SENTINEL slaves <master name> :列出给定主服务器的所有从服务器,以及这些从服务器的当前状态;
           SENTINEL get-master-addr-by-name <master name> : 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作, 或者针对这个主服务器的故障转移操作已经完成, 那么这个                     命令返回新的主服务器的 IP 地址和端口号;
           SENTINEL reset <pattern> : 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态, 包括正在执行中的故障转移, 并移除目前已经发现和关联的, 主服务器的所有从服务器和 Sentinel ;
           SENTINEL failover <master name> : 当主服务器失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移。
    客户端可以通过SENTINEL get-master-addr-by-name <master name>获取当前的主服务器IP地址和端口号,以及SENTINEL slaves <master name>获取所有的Slaves信息
        发布与订阅信息
        客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器: 你不可以使用 PUBLISH 命令向这个服务器发送信息, 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令, 通过订阅给定的频道来获取相应的事件提醒。
       一个频道能够接收和这个频道的名字相同的事件。 比如说, 名为 +sdown 的频道就可以接收所有实例进入主观下线(SDOWN)状态的事件。
       通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。
            +switch-master <master name> <oldip> <oldport> <newip> <newport> :配置变更,主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
        可以看出,我们使用Sentinel命令和发布订阅两种机制就能很好的实现和客户端的集成整合:
        使用get-master-addr-by-name和slaves指令可以获取当前的Master和Slaves的地址和信息;而当发生故障转移时,即Master发生切换,可以通过订阅的+switch-master事件获得最新的Master信息。
        *PS:更多Sentinel的可订阅事件参见官方文档
    sentinel.conf中的notification-script
        在sentinel.conf中可以配置多个sentinel notification-script <master name> <shell script-path>, 如sentinel notification-script mymaster ./check.sh
        这个是在群集failover时会触发执行指定的脚本。脚本的执行结果若为1,即稍后重试(最大重试次数为10);若为2,则执行结束。并且脚本最大执行时间为60秒,超时会被终止执行。
        PS:目前会存在该脚本被执行多次的问题,查找资料有人解释是:
            脚本分为两个级别, SENTINEL_LEADER 和 SENTINEL_OBSERVER ,前者仅由领头 Sentinel 执行(一个 Sentinel),而后者由监视同一个 master 的所有 Sentinel 执行(多个 Sentinel)。

    sdown和odown
    各个sentinel之间通过命令SENTINEL is_master_down_by_addr来获得其它sentinel对master的检测结果。
    从sentinel的角度来看,如果发送了PING心跳后,在一定时间内没有收到合法的回复,就达到了SDOWN的条件。这个时间在配置中通过is-master-down-after-milliseconds参数配置。
    当足够多的sentinal认为master宕机了,就从sdown切换成了odown。这个足够多的数量就是quonum。也就是 sdown(主观宕机)*quonum = odown(客观宕机)
    sentinel是靠redis的pub/sub实现通讯的_sentinel_:hello channel
    配置纠正:slave切换matser,需要哨兵去更新其他slave的matser配置


    *master选举算法:

    1,排除不适合选举成master的slave【down-after-milliseconds*10+milliseconds_since_master_is_in_SDOWN_state(master的宕机时长)
    2, slave-priority越小优先级越高
    3,replica offset,slave 复制了数据越多,offset越靠后,优先级越高
    4,选一个run id比较小的slave




    展开全文
  • Redis主从同步原理

    2018-08-07 17:09:41
    Redis主从同步原理-SYNC  和MySQL主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,下...

    Redis主从同步原理-SYNC

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

    1 全量同步

      Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下: 
      1)从服务器连接主服务器,发送SYNC命令; 
      2)主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令; 
      3)主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令; 
      4)从服务器收到快照文件后丢弃所有旧数据,载入收到的快照; 
      5)主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令; 
      6)从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令; 
    Redis全量同步过程 
      完成上面几个步骤后就完成了从服务器数据初始化的所有操作,从服务器此时可以接收来自用户的读请求。

    2 增量同步

      Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 
    增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。

    3 Redis主从同步策略

      主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。redis 策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。

    4 其他

    Redis 2.8以后提供了PSYNC优化了断线重连的效率 
    http://blog.csdn.net/sk199048/article/details/77922589

    参考:

    [1] 《Redis IN ACTION》 
    [2] http://blog.csdn.net/houjixin/article/details/27680183 
    [3] http://daoluan.net/blog/2014/04/22/decode-redis-replication/

    展开全文
  • Redis主从用法像MySQL一样,redis是支持主从同步的,而且也支持一主多从以及多级从结构。主从结构,一是为了纯粹的冗余备份,二是为了提升读性能,比如很消耗性能的SORT就可以由从服务器来承担。redis的主从同步是...
  • 主从模式可以保证redis的高可用,那么redis是怎么保证主从服务器的数据一致性的,接下来我们浅谈下redis主(master)从(slave)同步的原理。 2.初次全量同步 当一个redis服务器初次向主服务器发送salveof命令时,redis...
  • redis主从复制原理

    2018-05-06 17:16:13
    Redis持久化保证了即使redis服务重启也不会丢失数据,因为redis服务重启后会将硬盘上持久化的数据恢复到内存中,但是当redis服务器的硬盘损坏了可能会导致数据丢失,如果通过redis主从复制机制就可以避免这种单点...
  • 作用 我们正常在项目中对redis进行应用,一般都不会是单点的。因为,单点的宕机即不可用,不能保证可用性。... redis主从策略分为两大类知识点:1,replication复制策略。2,sentinal高可用性故...
  • 相信很多小伙伴都已经配置过主从复制,但是对于redis主从复制的工作流程和常见问题很多都没有深入的了解。咔咔这次用时俩天时间给大家整理一份redis主从复制的全部知识点。 主从复制(一)什么是redis主从复制?...
  • 为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。 全量同步 Redis全量复制一般发生在Slave初始化...
  • redis主从复制原理以及流程图 概念:就是将一台服务器的数据,复制到其他的redis服务器,前者为主节点(master/leader),后者称为从节点(slave/follower),数据的复制是单向的,只能从主节点到从节点,master以写...
  • &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&...Redis主从同步原理-PSYNC 1、PSYNC &lt; runid&gt; &lt; offset&gt; 请求数据同步
  • Redis主从同步原理-SYNC 和MySQL主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,下图...
  • 在前一篇文章中,对Redis主从复制进行了较为详细的说明,本文将参考redis官网上关于主从复制的说明进行简单说明一下,这里对官网的英文描述进行简单翻译说明一下。首先说明下主从复制的特点,然后对主从复制的原理...
  • Redis主从复制的功能非常强大,它有以下好处:1.避免Redis单点故障 2.构建读写分离架构,满足读多写少的应用场景1.主从架构1.1 Redis主从架构拓扑图结构 1.2 主从结构搭建Redis集群不用安装多个Redis,只需复制多个...
  • [Redis专题] Redis主从复制及其心跳检测实现机制1、Redis主从工作模式简述2、同步2.1老版本的Redis(2.8之前)新版本的Redis(2.8之后)3、命令传播4、新版本主从节点同步示例5、心跳检测5.1 检测主从服务器的网络...
  • (2)断线后重复制:处于命令传播阶段的主从服务器因为网络原因而中断了复制,但从服务器通过自动重连接重新连上了主服务器,并继续复制主服务器 旧版2.8版本以前,不管是初次复制,还是断线后重复制都是完整复制,...
  • redis——redis主从复制

    2018-07-11 18:43:00
    为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。一、概念主从复制,是指将一台Redis服务器的数据,复制到其他的Redis...
  • 配置Redis主从复制和集群配置详解1. 配置redis主从复制。1.1. 应用场景一般来说,要将Redis运用于工程项目中,只使用一台Redis是万万不能的,原因如下:a) 从结构上,单个Redis服务器会发生单点故障,并且一台...
1 2 3 4 5 ... 20
收藏数 23,672
精华内容 9,468
关键字:

redis主从原理