读操作:主库、从库都可以接收;
写操作:首先到主库执行,然后,主库将写操作同步给从库。
主从第一次同步
第一阶段,主从库间建立连接、协商同步的过程,主要是为全量复制做准备。从库和主库建立起连接,主库确认回复后,就可以开始同步了。具体来说,从库给主库发送 psync 命令,psync 命令包含了主库的 runID 和复制进度 offset 两个参数。runID,是每个 Redis 实例启动时都会自动生成的一个随机 ID,用来唯一标记这个实例。
第二阶段,主库执行 bgsave 命令,生成 RDB 文件,接着将文件发给从库。从库接收到 RDB 文件后,会先清空当前数据库,然后加载 RDB 文件。
主库将数据同步给从库的过程中,主库不会被阻塞,仍然可以正常接收请求。否则,Redis 的服务就被中断了。但是,这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性,主库会在内存中用专门的 replication buffer(缓冲区),记录 RDB 文件生成后收到的所有写操作。
第三阶段,主库会把第二阶段执行过程中新收到的写命令,再发送给从库。具体的操作是,当主库完成 RDB 文件发送后,就会把此时 replication buffer 中的修改操作发给从库,从库再重新执行这些操作。这样一来,主从库就实现同步了。
“主 - 从 - 从”模式
如果从库数量很多,而且都要和主库进行全量复制的话,就会导致主库忙于 fork 子进程生成 RDB 文件,进行数据全量同步,fork 这个操作会阻塞主线程处理正常请求,从而导致主库响应应用程序的请求速度变慢,可以通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力,以级联的方式分散到从库上
主从断了之后怎么继续同步?
首先判断自己记录的主ID与现在连接的masterID是否一样,不一样时会进行完整重同步,一样时再根据偏移量做增量复制
repl_backlog_buffer 环形缓冲区:它是为了从库断开之后,如何找到主从差异数据而设计的环形缓冲区,主库会记录自己写到的位置,从库则会记录自己已经读到的位置。主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距,把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从库,但是如果从库断开时间太久,repl_backlog_buffer环形缓冲区被主库的写命令覆盖了,那么从库连上主库后只能进行一次全量同步
replication buffer缓冲区:(从库设置的)Redis和客户端通信也好,和从库通信也好,Redis都需要给分配一个内存buffer进行数据交互(当主从库断连后,replication buffer不存在的)
主从库间的复制不使用 AOF
1、RDB文件内容是经过压缩的二进制数据(不同数据类型数据做了针对性优化),文件很小。而AOF文件记录的是每一次写操作的命令,写操作越多文件会变得很大。在主从全量数据同步时,传输RDB文件可以尽量降低对主库机器网络带宽的消耗,从库在加载RDB文件时,一是文件小,读取整个文件的速度会很快,二是因为RDB文件存储的都是二进制数据,从库直接按照RDB协议解析还原数据即可,速度会非常快,而AOF需要依次重放每个写命令,这个过程会经历冗长的处理逻辑,恢复速度相比RDB会慢得多,所以使用RDB进行主从全量同步的成本最低。
2、假设要使用AOF做全量同步,意味着必须打开AOF功能,打开AOF就要选择文件刷盘的策略,选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量同步数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景,其实是不需要开启AOF的
标签:主库,文件,主从复制,同步,Redis,RDB,从库,主从 From: https://www.cnblogs.com/yogayao/p/17466623.html