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

    2020-04-08 19:50:12
    Redis主从复制原理总结 转至元数据结尾 Created by 仲伟杰 on 2019-01-21 转至元数据起始 和Mysql主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis...

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

    在这里插入图片描述

    全量同步
    Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下:

    • 从服务器连接主服务器,发送SYNC命令;
    • 主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;
    • 主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;
    • 从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;
    • 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;
    • 从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;
      在这里插入图片描述

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

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

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

    注意点
    如果多个Slave断线了,需要重启的时候,因为只要Slave启动,就会发送sync请求和主机全量同步,当多个同时出现的时候,可能会导致Master IO剧增宕机。

    Redis主从复制的配置十分简单,它可以使从服务器是主服务器的完全拷贝。需要清除Redis主从复制的几点重要内容:
    1)Redis使用异步复制。但从Redis 2.8开始,从服务器会周期性的应答从复制流中处理的数据量。
    2)一个主服务器可以有多个从服务器。
    3)从服务器也可以接受其他从服务器的连接。除了多个从服务器连接到一个主服务器之外,多个从服务器也可以连接到一个从服务器上,形成一个
    图状结构。
    4)Redis主从复制不阻塞主服务器端。也就是说当若干个从服务器在进行初始同步时,主服务器仍然可以处理请求。
    5)主从复制也不阻塞从服务器端。当从服务器进行初始同步时,它使用旧版本的数据来应对查询请求,假设你在redis.conf配置文件是这么配置的。
    否则的话,你可以配置当复制流关闭时让从服务器给客户端返回一个错误。但是,当初始同步完成后,需要删除旧的数据集和加载新的数据集,在
    这个短暂的时间内,从服务器会阻塞连接进来的请求。
    6)主从复制可以用来增强扩展性,使用多个从服务器来处理只读的请求(比如,繁重的排序操作可以放到从服务器去做),也可以简单的用来做数据冗余。
    7)使用主从复制可以为主服务器免除把数据写入磁盘的消耗:在主服务器的redis.conf文件中配置“避免保存”(注释掉所有“保存“命令),然后连接一个配
    置为“进行保存”的从服务器即可。但是这个配置要确保主服务器不会自动重启(要获得更多信息请阅读下一段)

    主从复制的一些特点:
    1)采用异步复制;
    2)一个主redis可以含有多个从redis;
    3)每个从redis可以接收来自其他从redis服务器的连接;
    4)主从复制对于主redis服务器来说是非阻塞的,这意味着当从服务器在进行主从复制同步过程中,主redis仍然可以处理外界的访问请求;
    5)主从复制对于从redis服务器来说也是非阻塞的,这意味着,即使从redis在进行主从复制过程中也可以接受外界的查询请求,只不过这时候从redis返回的是以前老的数据,
    如果你不想这样,那么在启动redis时,可以在配置文件中进行设置,那么从redis在复制同步过程中来自外界的查询请求都会返回错误给客户端;(虽然说主从复制过程中
    对于从redis是非阻塞的,但是当从redis从主redis同步过来最新的数据后还需要将新数据加载到内存中,在加载到内存的过程中是阻塞的,在这段时间内的请求将会被阻,
    但是即使对于大数据集,加载到内存的时间也是比较多的);
    6)主从复制提高了redis服务的扩展性,避免单个redis服务器的读写访问压力过大的问题,同时也可以给为数据备份及冗余提供一种解决方案;
    7)为了编码主redis服务器写磁盘压力带来的开销,可以配置让主redis不在将数据持久化到磁盘,而是通过连接让一个配置的从redis服务器及时的将相关数据持久化到磁盘,
    不过这样会存在一个问题,就是主redis服务器一旦重启,因为主redis服务器数据为空,这时候通过主从同步可能导致从redis服务器上的数据也被清空;

    Redis大概主从同步是怎么实现的?
    全量同步:
    master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件,与此同时,服务器会缓存所有接收到的来自客户端的写命令(包含增、删、改),当后台保存进程
    处理完毕后,会将该rdb文件传递给slave服务器,而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存,在此之后master服务器会将在此期间缓存的
    命令通过redis传输协议发送给slave服务器,然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。

    部分同步:
    从redis 2.8版本以前,并不支持部分同步,当主从服务器之间的连接断掉之后,master服务器和slave服务器之间都是进行全量数据同步,但是从redis 2.8开
    始,即使主从连接中途断掉,也不需要进行全量同步,因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在master服务器内存中给每个slave服务器维护了
    一份同步日志和同步标识,每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后,slave服务器隔断时间
    (默认1s)主动尝试和master服务器进行连接,如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中,那么就从slave发送的偏移量开始继续上次的同步
    操作,如果slave发送的偏移量已经不再master的同步备份日志中(可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内master服务器接收到大量的写操作),则
    必须进行一次全量更新。在部分同步过程中,master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

    主从同步中需要注意几个问题

    1)在上面的全量同步过程中,master会将数据保存在rdb文件中然后发送给slave服务器,但是如果master上的磁盘空间有效怎么办呢?那么此时全部同步对于master来说
    将是一份十分有压力的操作了。此时可以通过无盘复制来达到目的,由master直接开启一个socket将rdb文件发送给slave服务器。(无盘复制一般应用在磁盘空间有限但是网
    络状态良好的情况下)

    2)主从复制结构,一般slave服务器不能进行写操作,但是这不是死的,之所以这样是为了更容易的保证主和各个从之间数据的一致性,如果slave服务器上数据进行了修改,
    那么要保证所有主从服务器都能一致,可能在结构上和处理逻辑上更为负责。不过你也可以通过配置文件让从服务器支持写操作。(不过所带来的影响还得自己承担哦。。。)

    3)主从服务器之间会定期进行通话,但是如果master上设置了密码,那么如果不给slave设置密码就会导致slave不能跟master进行任何操作,所以如果你的master服务器
    上有密码,那么也给slave相应的设置一下密码吧(通过设置配置文件中的masterauth);

    4)关于slave服务器上过期键的处理,由master服务器负责键的过期删除处理,然后将相关删除命令已数据同步的方式同步给slave服务器,slave服务器根据删除命令删除
    本地的key。

    当主服务器不进行持久化时复制的安全性

    在进行主从复制设置时,强烈建议在主服务器上开启持久化,当不能这么做时,比如考虑到延迟的问题,应该将实例配置为避免自动重启。

    为什么不持久化的主服务器自动重启非常危险呢?
    为了更好的理解这个问题,看下面这个失败的例子,其中主服务器和从服务器中数据库都被删除了。

    设置节点A为主服务器,关闭持久化,节点B和C从节点A复制数据。
    这时出现了一个崩溃,但Redis具有自动重启系统,重启了进程,因为关闭了持久化,节点重启后只有一个空的数据集。
    节点B和C从节点A进行复制,现在节点A是空的,所以节点B和C上的复制数据也会被删除。
    当在高可用系统中使用Redis Sentinel,关闭了主服务器的持久化,并且允许自动重启,这种情况是很危险的。
    比如主服务器可能在很短的时间就完成了重启,以至于Sentinel都无法检测到这次失败,那么上面说的这种失败的情况就发生了。

    如果数据比较重要,并且在使用主从复制时关闭了主服务器持久化功能的场景中,都应该禁止实例自动重启。

    Redis主从复制是如何工作的

    如果设置了一个从服务器,在连接时它发送了一个SYNC命令,不管它是第一次连接还是再次连接都没有关系。

    然后主服务器开始后台存储,并且开始缓存新连接进来的修改数据的命令。当后台存储完成后,主服务器把数据文件发送到从服务器,
    从服务器将其保存在磁盘上,然后加载到内存中。然后主服务器把刚才缓存的命令发送到从服务器。这是作为命令流来完成的,并且
    和Redis协议本身格式相同。

    你可以通过telnet自己尝试一下。在Redis服务器工作时连接到Redis端口,发送SYNC命令,会看到一个批量的传输,并且主服务器接收
    的每一个命令都会通过telnet会话重新发送一遍。

    当主从服务器之间的连接由于某些原因断开时,从服务器可以自动进行重连接。当有多个从服务器同时请求同步时,主服务器只进行一个后台存储。

    当连接断开又重新连上之后,一般都会进行一个完整的重新同步,但是从Redis2.8开始,只重新同步一部分也可以。

    部分重新同步

    从Redis 2.8开始,如果遭遇连接断开,重新连接之后可以从中断处继续进行复制,而不必重新同步。

    它的工作原理是这样:
    主服务器端为复制流维护一个内存缓冲区(in-memory backlog)。主从服务器都维护一个复制偏移量(replication offset)和master run id ,
    当连接断开时,从服务器会重新连接上主服务器,然后请求继续复制,假如主从服务器的两个master run id相同,并且指定的偏移量在内存缓冲
    区中还有效,复制就会从上次中断的点开始继续。如果其中一个条件不满足,就会进行完全重新同步(在2.8版本之前就是直接进行完全重新同步)。
    因为主运行id不保存在磁盘中,如果从服务器重启了的话就只能进行完全同步了。

    部分重新同步这个新特性内部使用PSYNC命令,旧的实现中使用SYNC命令。Redis2.8版本可以检测出它所连接的服务器是否支持PSYNC命令,不支持的
    话使用SYNC命令。

    无磁盘复制

    通常来讲,一个完全重新同步需要在磁盘上创建一个RDB文件,然后加载这个文件以便为从服务器发送数据。

    如果使用比较低速的磁盘,这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。
    使用这种设置时,子进程直接将RDB通过网络发送给从服务器,不使用磁盘作为中间存储。

    配置

    主从复制的配置十分简单:把下面这行加入到从服务器的配置文件中即可。
    slaveof 192.168.1.1 6379

    当然你需要把其中的192.168.1.1 6379替换为你自己的主服务器IP(或者主机名hostname)和端口。另外你可以调用SLAVEOF命令,
    主服务器就会开始与从服务器同步。

    关于部分重新同步,还有一些针对复制内存缓冲区的优化参数。查看Redis介质中的Redis.conf示例获得更多信息。

    使用repl-diskless-sync配置参数来启动无磁盘复制。使用repl-diskless-sync-delay 参数来配置传输开始的延迟时间,以便等待
    更多的从服务器连接上来。查看Redis介质中的Redis.conf示例获得更多信息。

    只读从服务器

    从Redis 2.6开始,从服务器支持只读模式,并且是默认模式。这个行为是由Redis.conf文件中的slave-read-only 参数控制的,
    可以在运行中通过CONFIG SET来启用或者禁用。

    只读的从服务器会拒绝所有写命令,所以对从服务器不会有误写操作。但这不表示可以把从服务器实例暴露在危险的网络环境下,
    因为像DEBUG或者CONFIG这样的管理命令还是可以运行的。不过你可以通过使用rename-command命令来为这些命令改名来增加安全性。

    你可能想知道为什么只读限制还可以被还原,使得从服务器还可以进行写操作。虽然当主从服务器进行重新同步或者从服务器重启后,
    这些写操作都会失效,还是有一些使用场景会想从服务器中写入临时数据的,但将来这个特性可能会被去掉。

    限制有N个以上从服务器才允许写入

    从Redis 2.8版本开始,可以配置主服务器连接N个以上从服务器才允许对主服务器进行写操作。但是,因为Redis使用的是异步主从复制,
    没办法确保从服务器确实收到了要写入的数据,所以还是有一定的数据丢失的可能性。

    这一特性的工作原理如下:
    1)从服务器每秒钟ping一次主服务器,确认处理的复制流数量。
    2)主服务器记住每个从服务器最近一次ping的时间。
    3)用户可以配置最少要有N个服务器有小于M秒的确认延迟。
    4)如果有N个以上从服务器,并且确认延迟小于M秒,主服务器接受写操作。

    还可以把这看做是CAP原则(一致性,可用性,分区容错性)不严格的一致性实现,虽然不能百分百确保一致性,但至少保证了丢失的数据不会超过M秒内的数据量。

    如果条件不满足,主服务器会拒绝写操作并返回一个错误。
    1)min-slaves-to-write(最小从服务器数)
    2)min-slaves-max-lag(从服务器最大确认延迟)

    ====== 通过redis实现服务器崩溃等数据恢复 ======
    由于redis存储在内存中且提供一般编程语言常用的数据结构存储类型,所以经常被用于做服务器崩溃宕机的数据恢复处理。服务器可以在某些指定过程中将需要保存的数据以json对象等方式存储到redis中,也就是我们常说的快照,当服务器运行时读取redis来判断是否有待需要恢复数据继续处理的业务。当一次业务处理结束后再删除redis的数据即可。redis提供两种将内存数据导出到硬盘实现数据备份的方法:

    1)RDB方式(默认)
    RDB方式的持久化是通过快照(snapshotting)完成的,当符合一定条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上。进行快照的条件可以由用户在配置文件中自定义,由两个参数构成:时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。RDB是redis默认采用的持久化方式,在配置文件中已经预置了3个条件:
    save 900 1 #900秒内有至少1个键被更改则进行快照
    save 300 10 #300秒内有至少10个键被更改则进行快照
    save 60 10000 #60秒内有至少10000个键被更改则进行快照

    可以存在多个条件,条件之间是"或"的关系,只要满足其中一个条件,就会进行快照。 如果想要禁用自动快照,只需要将所有的save参数删除即可。
    Redis默认会将快照文件存储在当前目录(可CONFIG GET dir来查看)的dump.rdb文件中,可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。

    Redis实现快照的过程

    • Redis使用fork函数复制一份当前进程(父进程)的副本(子进程);
    • 父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件;
    • 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此一次快照操作完成。
    • 在执行fork的时候操作系统(类Unix操作系统)会使用写时复制(copy-on-write)策略,即fork函数发生的一刻父子进程共享同一内存数据,当父进程要更改其中某片数据时(如执行一个写命令 ),操作系统会将该片数据复制一份以保证子进程的数据不受影响,所以新的RDB文件存储的是执行fork一刻的内存数据。

    Redis在进行快照的过程中不会修改RDB文件,只有快照结束后才会将旧的文件替换成新的,也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实 现Redis数据库备份。RDB文件是经过压缩(可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式,所以占用的空间会小于内存中的数据大小,更加利于传输。

    除了自动快照,还可以手动发送SAVE或BGSAVE命令让Redis执行快照,两个命令的区别在于,前者是由主进程进行快照操作,会阻塞住其他请求,后者会通过fork子进程进行快照操作。 Redis启动后会读取RDB快照文件,将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同,这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内 存中需要花费20~30秒钟。 通过RDB方式实现持久化,一旦Redis异常退出,就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合,通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失,则可以考虑使用AOF方式进行持久化。

    2)AOF方式
    默认情况下Redis没有开启AOF(append only file)方式的持久化,可以在redis.conf中通过appendonly参数开启:
    appendonly yes
    在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中,载入的速度相较RDB会慢一些

    开启AOF持久化后每执行一条会更改Redis中的数据的命令,Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的,默认的文件名是appendonly.aof,可以通过appendfilename参数修改:
    appendfilename appendonly.aof
    配置redis自动重写AOF文件的条件

    auto-aof-rewrite-percentage 100 # 当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF文件大小为依据

    auto-aof-rewrite-min-size 64mb # 允许重写的最小AOF文件大小
    配置写入AOF文件后,要求系统刷新硬盘缓存的机制

    appendfsync always # 每次执行写入都会执行同步,最安全也最慢

    appendfsync everysec # 每秒执行一次同步操作

    appendfsync no # 不主动进行同步操作,而是完全交由操作系统来做(即每30秒一次),最快也最不安全

    Redis允许同时开启AOF和RDB,既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据,因为AOF方式的持久化可能丢失的数据更少

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

    2019-03-15 17:41:46
    Redis主从复制原理Redis主从复制原理使用场景配置复制原理参考 Redis主从复制原理 使用场景 数据冗余。作为数据的热备份 故障恢复。主节点有问题,可以切换到从节点服务。 负载均衡。 读写分离的。 配置 master: ...

    Redis主从复制原理

    使用场景

    1. 数据冗余。作为数据的热备份
    2. 故障恢复。主节点有问题,可以切换到从节点服务。
    3. 负载均衡。 读写分离的。

    配置

    master:
    打开/etc/redis/redis.conf,把“bind 127.0.0.1”改成“bind 0.0.0.0”,绑定多个监听IP
    slave:
    bind 192.168.1.101(本机IP)
    slaveof 192.168.1.100 6379 (映射到主服务器上)

    复制原理

    主从刚开始连接的时候,进行全量同步。全量同步之后,进行增量同步。如果slave机器宕机之后,重启又会进行一次全量同步。

    在这里插入图片描述

    1. 从服务器连接主服务器,发送SYNC命令。
    2. 主服务收到SYNC命令之后,开始执行BGSAVE命令生成快照。并使用缓冲区记录之后执行的命令。
    3. 主服务执行完BGSAVE命令后,向所有从服务发送快照文件。
    4. 从收到快照之后,载入快照。
    5. 主发完快照后,向从发送缓冲区中写命令。
    6. 从载入完快照后,执行来自主缓冲区的内容。

    参考

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

    2021-04-01 19:43:04
    Redis 主从复制 主从复制的概念 就是将一台 redis 服务器的数据,复制到其他的 redis 服务器,前者为主节点(master/leader),后者称为从节点(slave/follower),数据的复制是单向的,只能从主节点到从节点,一般 ...

    Redis 主从复制

    主从复制的概念

    就是将一台 redis 服务器的数据,复制到其他的 redis 服务器,前者为主节点(master/leader),后者称为从节点(slave/follower),数据的复制是单向的,只能从主节点到从节点,一般 master 以写为主,slave 以读为主。

    Redis 全量同步和增量同步

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

    • 全量同步
      Redis全量复制一般发生在 Slave 初始化阶段,这时 Slave 需要将 Master 上的所有数据都复制一份

    具体步骤如下:

    1. 从服务器连接主服务器,发送 SYNC 同步命令;
    2. 主服务器接收到 SYNC 命名后,开始执行 BGSAVE 命令生成 RDB 文件并使用缓冲区记录此后执行的所有写命令;
    3. 主服务器 BGSAVE 执行完后,向所有从服务器发送 RDB 快照文件,并在发送期间继续记录被执行的写命令;
    4. 从服务器收到 RDB 快照文件后丢弃所有旧数据,内存载入收到的 RDB 快照文件;
    5. 主服务器将 RDB 快照文件发送完毕后,开始向从服务器发送缓冲区中的写命令;
    6. 从服务器完成对 RDB 快照文件的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令

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

    • 增量同步

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

    Redis主从复制策略

    Redis 主从服务器刚刚连接的时候,会进行全量同步;全同步结束后,再进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。

    主从复制的作用

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

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

    负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写功能,由从节点提供读功能,分担服务器负载,尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高 Redis 服务器的并发量

    高可用(HA)基石:主从复制还是哨兵和集群能够实施的基础

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

    2019-07-09 20:55:17
    前言: Redis持久化保证了即使redis服务重启也不会丢失数据,因为redis服务重启后会将硬盘上...为了分担压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制根据是否全量分为全量...

    前言:
    Redis持久化保证了即使redis服务重启也不会丢失数据,因为redis服务重启后会将硬盘上的数据回复到内存中,但redis的服务器的硬盘坏了咋办呢,数据就丢失了,所以就引入了主从复制从而避免单点故障。
    Redis虽然读取的速度极快,但是也会产生压力特别大的情况。为了分担压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制根据是否全量分为全量同步与增量同步。下图为级联结构:
    在这里插入图片描述
    Redis主从复制的特点:
    1、同一个master可以拥有多个slave。
    2、master下的slave还可以接受同一架构中其它slave的连接与同步请求,实现数据的级联复制,即master->slave->slave模式;
    3 、master以非阻塞的方式同步数据至slave,这将意味着master会继续处理client的读写请求;
    4、slave端同步数据也可以修改为非阻塞的方式,当slave在执行新的同步时,它仍可以用旧的数据信息来提供查询
    5、redis的主从复制具有可扩展性,即多个slave专门提供只读查询与数据的冗余,master端专门提供写操作,实现读写分离;
    6、通过配置禁用master数据持久化机制,将其数据持久化操作交给slave完成,避免在master中要有独立的进程来完成此操作。

    全量同步:
      Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下:

    1)从服务器连接主服务器,发送SYNC命令;

    2)主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;

    3)主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;

    4)从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;

    5)主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;

    6)从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;
      在这里插入图片描述

    完成上面几个步骤后就完成了从服务器数据初始化的所有操作,从服务器此时可以接收来自用户的读请求。
    备注:
    如果master和slave之间的连接出现断开,slave可以自动重连到master。根据版本的不同,断连后同步的方式也不同:
    2.8之前:重连成功之后,一次全量同步操作将被自动执行。
    2.8之后:重连成功之后,进行部分同步操作。

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

    master持久化功能关闭时,将带来复制的安全性:
    当我们部署redis主从复制的时候,一般都会强烈建议把master的持久化开关打开。即使为了避免持久化带来的延迟影响,不把持久化开关打开,那么也应该把master配置为不会自动启动。因为master异常刷新后再重启是非常危险的,会导致slave中的数据会被清空。
    假设我们有一个redis节点A,设置为master,并且关闭持久化功能,另外两个节点B和C是它的slave,并从A复制数据。
    如果A节点崩溃了导致所有的数据都丢失了,它会重启系统来重启进程。但是由于持久化功能被关闭了,所以即使它重启了,它的数据集也是空的。
    而B和C依然会通过replication机制从A复制数据,所以B和C会从A那里复制到一份空的数据集,并用这份空的数据集将自己本身的非空的数据集替换掉。于是就相当于丢失了所有的数据。
    即使使用一些工具,比如说sentinel来监控master-slaves集群,也会发生上述的情形,因为master可能崩溃后迅速恢复。速度太快而导致sentinel无法察觉到一个failure的发生。

    redis2.8之后主从复制的过程:
    在redis2.8之前从redis每次同步都会从主redis中复制全部的数据,如果从redis是新创建的,则从主redis中复制全部的数据这是没有问题的,但是,如果当从redis停止运行,再启动时可能只有少部分数据和主redis不同步,此时启动redis仍然会从主redis复制全部数据,这样的性能肯定没有只复制那一小部分不同步的数据高。
    部分复制
    在这里插入图片描述
    从机连接主机后,会主动发起 PSYNC(部分同步)命令,从机会提供 master的runid(机器标识,随机生成的一个串) 和 offset(数据偏移量,如果offset主从不一致则说明数据不同步),主机验证 runid 和 offset 是否有效, runid 相当于主机身份验证码,用来验证从机上一次连接的主机,如果runid验证未通过则,则进行全同步,如果验证通过则说明曾经同步过,根据offset同步部分数据。

    部分复制的工作原理:
    主服务器端为复制流维护一个内存缓冲区。主从服务器都维护一个复制偏移量(replication offset)和master run id ,当连接断开时,从服务器会重新连接上主服务器,然后请求继续复制,假如主从服务器的两个master run id相同,并且指定的偏移量在内存缓冲区中还有效,复制就会从上次中断的点开始继续。如果其中一个条件不满足,就会进行完全重新同步。因为主运行id不保存在磁盘中,如果从服务器重启了的话就只能进行完全同步了。

    无磁盘的复制:
    通常一个同步需要在磁盘上创建一个RDB文件,然后再重新加载这个文件来进行与slave数据同步。由于磁盘的读写是非常慢的,这对于redis master是一个非常有压力的操作,在2.8.18尝试使用无磁盘的复制,在这个设置里,进程直接把RDB 发送到slaves,而不需要使用磁盘来做中间的存储。

    主从切换:
    万一主机挂了怎么办,这是个麻烦事情,所以redis提供了一个sentinel(哨兵),以此来实现主从切换的功能,类似与zookeeper。
    我们配置两个sentinel进程:

    vim sentinel.conf 
        port 26379
        sentinel monitor mymaster 127.0.0.1 6000 2
        sentinel auth-pass mymaster 123456
    
    vim sentinel.conf
        port 26479
        sentinel monitor mymaster 127.0.0.1 6000 2
        sentinel auth-pass mymaster 123456
    

    启动sentinel服务:
    redis-server sentinel.conf --sentinel

    查看日志:

    [7014] 11 Jan 19:42:30.918 # +monitor master mymaster 127.0.0.1 6000 quorum 2
    [7014] 11 Jan 19:42:30.923 * +slave slave 127.0.0.1:6002 127.0.0.1 6002 @ mymaster 127.0.0.1 6000
    [7014] 11 Jan 19:42:30.925 * +slave slave 127.0.0.1:6001 127.0.0.1 6002 @ mymaster 127.0.0.1 6000
    
    

    从对应的日志观察到,一个master服务,两个slave服务
    我们现在来kill master进程

    [root@localhost slave1]# ps -ef|grep redis
    
    root      6960     1  0 19:29 ?        00:00:02 redis-server *:6000    
    
    root      6968     1  0 19:30 ?        00:00:01 redis-server *:6001     
    
    root      6975     1  0 19:30 ?        00:00:01 redis-server *:6002     
    
    root      7014  6570  0 19:42 pts/0    00:00:01 redis-server *:26479                 
    
    root      7017  6789  0 19:42 pts/5    00:00:01 redis-server *:26379                 
    
    root      7021  6729  0 19:46 pts/3    00:00:00 grep redis
    
    [root@localhost slave1]# kill -9 6960
    

    我们观察日志:

    [7014] 11 Jan 19:43:41.463 # +sdown master mymaster 127.0.0.1 6000
    
    [7014] 11 Jan 19:46:42.379 # +switch-master mymaster 127.0.0.1 6000 127.0.0.1 6001
    

    master切换了,当6000端口的这个服务重启的时候,他会变成6001端口服务的slave。
    因为sentinel在切换master的时候,把对应的sentinel.conf和redis.conf文件的配置修改。
    期间我们还需要关注的一个问题:sentinel服务本身也不是万能的,也会宕机,所以我们还得部署sentinel集群,像我这样多启动几个sentinel。

    sentinel monitor mymaster 127.0.0.1 6000 2  这个后面的数字2,是指当有两个及以上的sentinel服务检测到master宕机,才会去执行主从切换的功能。
    

    参考:https://blog.csdn.net/weixin_37672169/article/details/80216211

    展开全文
  • 主要给大家介绍了关于redis主从复制原理的相关资料,文中通过示例代码介绍的非常详细,对大家学习或者使用redis具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧
  • 【Redis】redis主从复制原理

    千次阅读 2020-02-09 21:52:50
    【Redis】redis主从复制原理
  • Redis主从复制原理总结 和Mysql主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis...

空空如也

空空如也

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

redis主从复制原理

redis 订阅