Redis 之深入江湖-复制原理

一.前言

　　上一篇文章redis 之复制-初入江湖中,讲了关于redis复制配置,如:如何建立配置、如何断开复制、关于链接的安全性等等,那么本篇文章将深入的去说一下关于redis复制原理,如下:

• 复制过程
• 数据同步
• 全量复制
• 部分复制
• 心跳
• 异步复制

---

二.复制过程

　　在从节点执行slaveof命令后,复制过程便开始运作,下面将会详细的讲解建立复制的完整流程,如下图所示:

　　从上图中,可以看出复制的一个大致流程:

1. 保存master(主节点)信息:从节点执行slaveof后只保存主节点的地址信息后便直接返回,这时建立复制的流程还没开始.
2. slave(从节点)内部通过每秒运行的定时任务维护复制相关逻辑,当定时任务发现存在新的主节点后,从节点会建立一个socket连接主节点.如果从节点无法建立连接,定时任务会无限重试直到连接成功,或者执行slaveof no one取消复制.
3. 发送ping命令,如果发送ping命令后(目的:1)检测主从之间网络套节字持否可用;2)检测主节点当前是否可接受处理命令),从节点没有收到主节点的pong回复或者连接超时,比如网络超时或者主节点阻塞无法响应,从节点会断开复制连接,下次定时任务会继续发起重连.
4. 权限验证.如果主节点设置了requirepass参数，那么就需要密码进行权限验证;如果验证失败,复制将终止.从节点会重新发起复制流程.
5. 同步数据集.权限验证通过后,进行数据同步,对于首次建立复制的场景,主节点会把持有的数据全部发给从节点,这个操作耗时最长.(在redis2.8版本之后,同步操作分两种情况:全量和部分,下面将会说到)
6. 命令持续复制.当主节点把当前所有数据同步给从节点后,便完成了复制的整个流程,后面主节点将持续把写命令发给从节点,以保持数据的一致性.

---

三.数据同步

　　在上面的复制整个流程中,有一个步骤是“同步数据集”,这个通过过程分为:全量复制和部分复制.

　　全量复制:一般用于初次复制场景,redis早期支持的复制功能便只有全量复制,它会把主节点的所有数据一次性发给从节点,当数据量较大时,这会给主从节点之间的各个方面带来很大的开销.

　　部分复制:用于处理在主从复制中因网络闪断等原因造成数据丢失的场景,当从节点再次连上主节点后,如果条件允许,主节点会补发之前丢失的数据给从节点.因为补发的数据远远小于全量数据,可以有效的避免复制过程中的过高开销.

　　redis的同步有2个命令,分别是:sync 和 psync,前者是 redis 2.8 之前的同步命令,后者是 redis 2.8 为了优化 sync 新设计的命令.我们会重点关注 2.8版本以后的 psync 命令.psync 命令的运行需要三个组件支持:(1)主从节点各自复制偏移量;(2)主节点复制积压缓冲区;(3)主节点运行id.

　　

　　1).主从节点的复制偏移量

　　1.参与复制的主从节点都会维护自身复制偏移量.统计信息在使用info replication命令查看中的master_repl_offset指标中.
　　2.从节点(slave)每秒钟上报自身复制偏移量给主节点,因此主节点也会保存从节点的偏移量.
　　3.从节点在接收到主节点发送的命令后,也会累加自身的偏移量.　　
　　4.通过对比主从节点的复制偏移量,可以判断主从节点数据是否一致,如下图所示.

　　

　　注:可以通过主节点的统计信息,计算出master_repl_offset-slave_offset字节量,判断主从节点复制相差的数据量,根据这个产值判定当前复制的健康度.如果主从之间复制偏移量相差较大,则可能是网络延迟或命令阻塞等原因引起的.

 

　　2).复制积压缓冲区

　　(1)复制积压缓冲区是保存在主节点上的一个固定长度的队列,默认大小为1mb.当主节点有连接的从节点(slave)被创建时,这时主节点(master)响应写命令时,不但会把命令发送给从节点,还会写入复制积压缓冲区,如下图所示.

　　(2)由于缓冲区本质上是先进先出的定长队列,所以能实现保存最近已复制数据的功能,用于部分复制和复制命令丢失的数据补救,可以通过 info replication 查看相关信息.

　　3).主节点运行id

　　(1)每个redis节点启动后都会动态分配一个40位的十六进制字符串作为运行id.

　　(2)运行id的主要作用是用来唯一识别的redis节点,比如从节点保存主节点运行id识别自己正在复制的是哪个主节点.如果只是使用ip+port的方式识别主节点,那么主节点重启变更了整体数据集(如替换rdb/aof文件),从节点再基于偏移量复制数据将是不安全的,因此当运行id变化后从节点将做全量复制.

　　(3)上面提到的是主节点重启变更,那么重启不改变运行id呢?这时可以使用 debug reload 命令重新加载rdb并保持运行id不变,从而有效避免不必要的全量复制.

 

　　注:debug reload命令会阻塞当前redis节点主线程,阻塞期间会生成本地rdb快照并清空数据之后再加载rdb文件.因此对于大量数据的主节点和无法容忍阻塞的应用场景,是要谨慎使用的.

 

　　4).psync命令

　　从节点使用psync命令完成部分复制和全量复制功能.命令格式:psync {runid} {offset},其参数含义如下:

• runid:从节点所复制主节点的运行id
• offset:当前从节点已复制的数据偏移量

 

　　psync的执行流程如下:

 

　　 流程说明:

1. slave(从节点)发送sync命令给主节点,参数runid是当前从节点保存的主节点运行id,如果没有则默认为-1.offset 是从节点保存的复制偏移量,如果是第一次复制则为 -1.
2. master(主节点)根据sync参数和自身数据的情况决定响应结果:

• 如果回复+fullresync {runid} {offset} ,那么从节点将触发全量复制流程。
• 如果回复 +continue,从节点将触发部分复制.
• 如果回复 +err,说明主节点不支持 2.8 的 psync 命令,将使用 sync 执行全量复制.

 

---

四.全量复制

　　全量复制是redis最早支持的复制方式,也是主从第一次建立复制是必须要走的流程.触发全量复制的命令是 sync 和 psync.前面已经说过，redis 2.8 之前使用 sync 只能执行全量不同, 之后同时支持全量同步和部分同步.

　　

流程如图:

 

　　流程说明:

1. 发送psync命令进行同步数据,由于是第一次进行复制,从节点还没有复制偏移量和主节点运行id,所以发送:psysc ?-1.
2. 主节点根据psysc ?-1 当前为全局复制,回复 +fullresync 响应.
3. 从节点接受主节点的响应并保存运行id和offset.
4. 主节点执行 bgsave  并保存 rdb 到本地.
5. 主节点发送rdb文件到从节点,从节点把所接收的rdb文件保存到本地,并将其作为从节点的数据文件.
6. 对于从节点接受rdb文件快照到完成期间,主节点依然响应读写命令,因此主节点会把这段时间内的数据保存到复制客户端缓冲区内,当从节点加载完rdb文件后,主节点会再把缓冲区内的数据发给从节点,保证主从之间数据一致性.
7. 从节点接受完主节点传来的全部数据后,会清空自身旧数据.
8. 从节点清空数据后开始加载rdb文件,对于较大的rdb文件,这一步还是非常耗时的.
9. 从节点成功加载完 rbd 后,如果当前节点开启了 aof,会立刻做 bgrewriteaof操作.

以上加粗的部分是整个全量同步耗时的地方.

注:

• 如果线上rdb 文件数据量在 6g左右的主节点，并且是千兆网卡，redis 的默认超时机制（60 秒）,会导致全量复制失败.可以通过调大 repl-timeout 参数来解决此问题.
• redis 虽然支持无盘复制，生成的rdb文件不保存到本地,而是直接通过网络发送给从节点,不过无盘复制还处于试验阶段,所以生产环境一定慎用。

---

 

 五.部分复制

　　部分复制主要是redis针对全量复制的过高开销,所做的一些优化.在slave(从节点)正在向master(主节点)时,如果出现网络闪断或者命令丢失等异常情况发生时,从节点会向主节点要求补发丢失的命令数据,如果主节点的复制积压缓冲区内存在这部分,则直接打给从节点,这样便可以保持主从节点复制的一致性.补发的这部分数据远远小于全量数据,所以开销很小.部分复制流程图如下:

1. 当主从节点之间网络出现中断时,如果超过repl-timeout时间,主节点会认为从节点故障并中断复制连接.
2. 主节点连接中断期间,主节点依然响应命令,但因复制连接中断命令无法发送给从节点,不过主节点内部存在复制积压缓冲区,依然可保存最近一段时间的数据,默认为1mb.
3. 当从节点网络恢复后,从节点会在此连上主节点.
4. 当主从连接恢复后,因为之前从节点保存了自身已复制的offset和运行id,所以会把把其当作psync参数发给主节点.
5. 主节点连接到psync命令后,首先核对参数runid是否一致,如果一致说明之前复制的是当前主节点,然后根据offset参数在自身复制积压缓冲区中进行查找,如果偏移量之后的数据存在缓冲区中,则想从节点发送 +continue 响应,表示进行部分复制.
6. 主节点根据偏移量吧复制积压缓冲区里数据发给从节点,以保证主从复制进入正常状态.

---

六.心跳

　　主从节点在建立复制后,他们之间维护着长连接,并且彼此发送心跳.如图:

主从心跳判断机制:

1. 主从节点彼此都有心跳检测机制,各自模拟成对方的客户端急性通信,通过 client list 命令查看复制相关客户端信息,主节点的连接状态为 flags = m,从节点的连接状态是 flags = s.
2. 主节点默认每隔10秒对从节点发送ping命令,判断从节点的存活状态和连接状态,可通过修改配置 repl-ping-slave-period 控制发送频率.
3. 从节点在主线程每隔1秒发送 replconf ack{offset} 命令,给主节点上报自身当前的复制偏移量.
4. 主节点收到 replconf 信息后,判断从节点超时时间,如果超过 repl-timeout 设置的值(默认值为60 秒),则判断从节点下线,并断开复制客户端连接.

replconf的作用:

• 实时监测主从节点的网络状态
• 上报自身的偏移量,检查复制数据是否丢失
• 实现保证从节点的数量和延迟功能,通过min-slaves-to-write,min-slaves-max-lag参数配置定义

注意:为了降低主从延迟,一般把 redis 主从节点部署在相同的机房/同城机房,避免网络延迟带来的网络分区造成的心跳中断等情况.

---

 

七.异步复制

主节点不但负责数据读写,还负责把写命令同步给从节点.写命令的发送过程是异步完成的,也就是说主节点自身处理完写命令后直接返回给客户端,并不等待从节点复制完成,如下图所示:

异步复制的流程如下:

1. 主节点接受处理命令
2. 命令处理完之后返回响应结果
3. 对于修改命令异步发送给从节点,从节点在主线程中执行复制的命令.

---

 

八.回顾

本篇文章,大略分析了下复制过程、数据同步、全量复制、部分复制、心跳、异步复制等方面的原理.

 

 

参考:《redis开发与运维》

版权声明：尊重博主原创文章，转载请注明出处 https://www.cnblogs.com/hsdy