Redis主从模式(二)---拓扑结构及复制过程

目录

一, Redis主从模式下的复制拓扑结构

1.1 一主一从结构

1.2 一主多从结构

1.3 树形主从结构

二, 主从复制过程

2.1 主从复制建立复制流程图

2.2 数据同步(psyc)

1.replicationid/replid (复制id)

2.offset(偏移量)

2.3 psync运行流程

2.4 全量复制

2.5 部分复制

2.5 复制积压缓冲区

2.6 实时复制

---

Redis主从模式(一)----搭建主从结构并演示:

Redis主从模式(一)----搭建主从结构并演示-CSDN博客

一, Redis主从模式下的复制拓扑结构

Redis 的复制拓扑结构可以⽀持单层或多层复制关系，根据拓扑复杂性可以分为以下三种：⼀主⼀ 从、⼀主多从、树状主从结构.

1.1 一主一从结构

一主一从结构是最简单的复制拓扑结构,用于主节点出现宕机时从节点提供故障转移支持(哨兵章节会详细讲解),如图所示:

 一主一从的这种结构很大程度上解决了读命令并发量较高的情况,当写命令并发量较高且需要持久化时,可以只在从节点上开启AOF(这样写IO的操作都交给了从节点,减少了主节点写命令的并发量),这样既可以保证数据安全性的同时也避免了持久化对主节点的性能干扰.

缺点:主节点一旦挂了,不能让它自动重启,如果自动重启,需要回复数据,此时没有AOF文件,主节点就会默认丢失了数据,从节点进行复制操作也会把从节点的数据给删除了.

1.2 一主多从结构

一主多从结构(星形结构)使得应用端可以利用多个从节点实现读写分离(实际开发中,往往读请求远远超过写请求),增加从节点可以降低读请求的并发量,如图所示:

 一主多从结构对于读比较大的场景,可以把读命令负载均衡到不同的从节点上来分担压力,同时一些耗时的读命令可以指定一台专门的从节点执行,避免破坏整体的稳定性.

缺点:对于写并发量较高的场景,多个从节点会导致主节点写命令的多次发送从而加重主节点的负载,随着从节点个数的增加,同步一条数据就需要传输很多次.

1.3 树形主从结构

树形主从结构(分层结构)使得从节点不但可以复制主节点数据,同时可以作为其他从节点的主节点继续向下层复制,通过引入复制中间层,可以有效降低系统按负载和需要传送给从节点的数据量,如图所示:

数据写⼊节点 A 之后会同步给 B 和 C 节点,B 节点进⼀步把数据同步给 D 和 E 节点,当主节点需要挂载等多个从节点时为了避免对主节点的性能⼲扰,可以采⽤这种拓扑结构,主节点就不需要那么高的网络带宽了.

缺点:一旦数据进行修改,同步延时会更久.

二, 主从复制过程

2.1 主从复制建立复制流程图

 1.保存主节点(master)信息

开始配置主从同步关系之后,从节点只保存主节点的地址信息,此时建⽴复制流程还没有开始,在从节点 6380 执⾏ info replication 可以看到如下信息：

master_host: 127.0.0.1
master_port: 6379
master_link_status: down

 从统计信息可以看出,主节点的ip和port被保存下来,但是主节点的连接状态是下线状态.

2.主从建立连接

从节点（slave）内部通过每秒运⾏的定时任务维护复制相关逻辑,当定时任务发现存在新的主节点后,会尝试与主节点建⽴基于 TCP 的⽹络连接,如果从节点⽆法建⽴连接,定时任务会⽆限重试直 到连接成功或者⽤⼾停⽌主从复制.

3.发送ping命令

连接建⽴成功之后,从节点通过 ping 命令确认主节点在应⽤层上是⼯作良好的,如果 ping 命令的结果 pong 回复超时,从节点会断开 TCP 连接,等待定时任务下次重新建⽴连接.

4.权限验证

如果主节点设置了 requirepass 参数,则需要密码验证,从节点通过配置 masterauth 参数来设置密码,如果验证失败,则从节点的复制将会停⽌.

5.同步数据集

对于⾸次建⽴复制的场景,主节点会把当前持有的所有数据全部发送给从节点,这步操作基本是耗时最⻓的,所以⼜划分称两种情况:全量同步和部分同步.

6.命令持续复制

当从节点复制了主节点的所有数据之后,针对之后的修改命令,主节点会持续的把命令发送给从节点,从节点执⾏修改命令,保证主从数据的⼀致性.

2.2 数据同步(psyc)

Redis 使⽤ psync 命令完成主从数据同步,同步过程分为:全量复制和部分复制

•  全量复制:⼀般⽤于初次复制场景,Redis 早期⽀持的复制功能只有全量复制,它会把主节点全部数据⼀次性发送给从节点,当数据量较⼤时,会对主从节点和⽹络造成很⼤的开销
•  部分复制:⽤于处理在主从复制中因⽹络闪断等原因造成的数据丢失场景,当从节点再次连上主节点后,如果条件允许,主节点会补发数据给从节点,因为补发的数据远⼩于全量数据,可以有效避免全量复制的过⾼开销

1.replicationid/replid (复制id)

主节点的复制 id. 主节点重新启动, 或者从节点晋级成主节点, 都会⽣成⼀个 replicationid. (同⼀个节点, 每次重启⽣成的 replicationid 也会变化). 从节点在和主节点建⽴连接之后, 就会获取到主节点的 replicationid.

关于 master_replid 和 master_replid2

每个节点需要记录两组 master_replid,这个设定解决的问题场景是这样的: ⽐如当前有两个节点 A 和 B, A 为 master, B 为 slave. 此时 B 就会记录 A 的 master_replid. 如果⽹络出现抖动, B 以为 A 挂了, B ⾃⼰就会成为主节点. 于是 B 给⾃⼰分配了新的 master_replid. 此时就会使⽤ master_replid2 来保存之前 A 的 master_replid.

• 后续如果⽹络恢复了, B 就可以根据 master_replid2 找回之前的主节点.
• 后续如果⽹络没有恢复, B 就按照新的 master_replid ⾃成⼀派, 继续处理后续的数据.

2.offset(偏移量)

参与复制的主从节点都会维护⾃⾝复制偏移量,主节点（master）在处理完写⼊命令后,会把命令的 字节⻓度做累加记录,统计信息在 info replication 中的 master_repl_offset 指标中.

• 从节点（slave）每秒钟上报⾃⾝的复制偏移量给主节点
• 从节点在接受到主节点发送的命令后,也会累加记录⾃⾝的偏移量

replid + offset 共同标识了⼀个 "数据集". 如果两个节点, 他们的 replid 和 offset 都相同, 则这两个节点上持有的数据, 就⼀定相同.

2.3 psync运行流程

1.  从节点发送psync命令给主节点,replid和offset的默认值分别是?和-1
2. 主节点根据psync参数和自身数据情况决定响应结果
   1. 如果回复 +FULLRESYNC replid offset,则从节点需要进⾏全量复制流程
   2. 如果回复 +CONTINEU,从节点进⾏部分复制流程
   3. 如果回复 -ERR,说明 Redis 主节点版本过低,不⽀持 psync 命令,从节点可以使⽤ sync 命令进⾏全量复制

• psync ⼀般不需要⼿动执⾏. Redis 会在主从复制模式下⾃动调⽤执⾏
• sync 会阻塞 redis server 处理其他请求. psync 则不会

2.4 全量复制

全量复制是 Redis 最早⽀持的复制⽅式,也是主从第⼀次建⽴复制时必须经历的阶段,全量复制的运 ⾏流程如图所⽰:

1. 从节点发送 psync 命令给主节点进⾏数据同步,由于是第⼀次进⾏复制,从节点没有主节点的运⾏ ID 和复制偏移量,所以发送 psync ? -1;
2. 主节点根据命令,解析出要进⾏全量复制,回复 +FULLRESYNC 响应;
3. 从节点接收主节点的运⾏信息进⾏保存;
4. 主节点执⾏ bgsave 进⾏ RDB ⽂件的持久化;
5. 从节点发送 RDB ⽂件给从节点,从节点保存 RDB 数据到本地硬盘;
6. 主节点将从⽣成 RDB 到接收完成期间执⾏的写命令,写⼊缓冲区中,等从节点保存完 RDB ⽂件后,主节点再将缓冲区内的数据补发给从节点,补发的数据仍然按照 rdb 的⼆进制格式追加写⼊到收到的 rdb ⽂件中,保持主从⼀致性;
7. 从节点清空⾃⾝原有旧数据;
8. 从节点加载 RDB ⽂件得到与主节点⼀致的数据;
9. 如果从节点加载 RDB 完成之后,并且开启了 AOF 持久化功能,它会进⾏ bgrewrite 操作,得到最近的 AOF ⽂件.

通过分析全量复制的所有流程,我们会发现全量复制是⼀件⾼成本的操作:主节点 bgsave 的时间,RDB 在⽹络传输的时间,从节点清空旧数据的时间,从节点加载 RDB 的时间等,所以⼀般应该尽可能避免对已经有⼤量数据集的 Redis 进⾏全量复制.

有磁盘复制 vs ⽆磁盘复制(diskless)

默认情况下,进⾏全量复制需要主节点⽣成 RDB ⽂件到主节点的磁盘中,再把磁盘上的 RDB ⽂件通过发送给从节点.

Redis 从 2.8.18 版本开始⽀持⽆磁盘复制. 主节点在执⾏ RDB ⽣成流程时,不会⽣成 RDB ⽂ 件到磁盘中了,⽽是直接把⽣成的 RDB 数据通过⽹络发送给从节点,这样就节省了⼀系列的写 硬盘和读硬盘的操作开销.

2.5 部分复制

部分复制主要是 Redis 针对全量复制的过⾼开销做出的⼀种优化措施,使⽤ psync replicationId offset 命令实现,当从节点正在复制主节点时,如果出现⽹络闪断或者命令丢失等异常情况时,从节点 会向主节点要求补发丢失的命令数据,如果主节点的复制积压缓冲区存在数据则直接发送给从节点,这样就可以保持主从节点复制的⼀致性,补发的这部分数据⼀般远远⼩于全量数据,所以开销很小,整体流程如图所⽰:

1. 当主从节点之间出现⽹络中断时,如果超过 repl-timeout 时间,主节点会认为从节点故障并终端复制连接;
2. 主从连接中断期间主节点依然响应命令,但这些复制命令都因⽹络中断⽆法及时发送给从节点,所以暂时将这些命令滞留在复制积压缓冲区中;
3. 当主从节点⽹络恢复后，从节点再次连上主节点;
4. 从节点将之前保存的 replicationId 和 复制偏移量作为 psync 的参数发送给主节点,请求进⾏部分 复制;
5. 主节点接到 psync 请求后,进⾏必要的验证,随后根据 offset 去复制积压缓冲区查找合适的数据,并响应 +CONTINUE 给从节点;
6. 主节点将需要从节点同步的数据发送给从节点,最终完成⼀致性 .

2.5 复制积压缓冲区

复制积压缓冲区是保存在主节点上的⼀个固定⻓度的队列,默认⼤⼩为 1MB,当主节点有连接的从节 点（slave）时被创建,这时主节点（master）响应写命令时,不但会把命令发送给从节点,还会写⼊ 复制积压缓冲区,如图所示:

由于缓冲区本质上是先进先出的定⻓队列,所以能实现保存最近已复制数据的功能,⽤于部分复制和 复制命令丢失的数据补救,如果当前从节点需要的数据, 已经超出了主节点的积压缓冲区的范围, 则⽆法进⾏部分复制, 只 能全量复制了.

2.6 实时复制

主从节点在建⽴复制连接后,主节点会把⾃⼰收到的 修改操作 ,通过 tcp ⻓连接的⽅式,源源不断的传输给从节点,从节点就会根据这些请求来同时修改⾃⾝的数据,从⽽保持和主节点数据的⼀致性.

另外,这样的⻓连接,需要通过⼼跳包的⽅式来维护连接状态. (这⾥的⼼跳是指应⽤层⾃⼰实现的⼼跳, ⽽不是 TCP ⾃带的⼼跳).

1. 主从节点彼此都有⼼跳检测机制,各⾃模拟成对⽅的客⼾端进⾏通信;
2. 主节点默认每隔 10 秒对从节点发送 ping 命令,判断从节点的存活性和连接状态;
3. 从节点默认每隔 1 秒向主节点发送 replconf ack {offset} 命令,给主节点上报⾃⾝当前的复制偏移量.

如果主节点发现从节点通信延迟超过 repl-timeout 配置的值（默认 60 秒),则判定从节点下线,断开复制客⼾端连接,从节点恢复连接后,⼼跳机制继续进⾏.