26 redis 中 replication/cluster 集群中的主从复制

前言

我们这里首先来看?redis?这边实现比较复杂的?replication集群模式?

我们这里主要关注的是 redis?这边的主从同步的相关实现

这边相对比较简单,?我们直接基于?cluster集群模式 进行调试

?

?

主从命令同步复制

比如这里 master 是?redis_7002, slave 是?redis_7005

然后?这里是 master?这边直接同步?相关命令到各个 slave?

?

然后这里是在 server.call:3765 进行命令存储到?backlog, aof, 以及同步发送到?slave?

命令真实执行是在?server.call:3675 的?cmd->proc->proc(c)

?

然后?redis_7005 这边拿到命令之后,?开始执行, 这个执行过程就和客户端这边发送执行命令一样?

?

?

全量同步

整个流程分为两个 part, 一个是请求方,?就是?slave, 一个是提供方,?是?master?

slave 这边连接到?master?之后,?slave 发送?SYNC?命令到?master?

master 通知客户端需要全量同步, 然后?master?这边后台去?dump?内存快照文件

slave 这边等待?master?这边?dump?内存快照文件,?并通过网络传递过来?

master 这边?dump?内存快照文件生成之后,?会向?slave?这边进行传输

slave 这边拿到?master?的?dump?的内存快照信息,?将其持久化到 临时文件,?完成之后重命名为?dump.rdb, 然后清空当前数据库,?然后?加载 dump.rdb?文件进行一个快照的数据恢复?

我们这里?一边一边的看, 先看?slave, 再看?master?

?

slave 的处理

这个是?slave?这边启动的时候?就会进行的一个操作

这里?syncWithMaster 根据?server.repl_state 这边同步的处理了几个?slave?和?master?的交互,?分为了几个不同的阶段?REPL_STATE_CONNECT, REPL_STATE_CONNECTING, REPL_STATE_RECEIVE_PING_REPLY, REPL_STATE_SEND_HANDSHAKE 等等?

比如这里会?发送 ping?给?master, 然后等待?master?这边回复信息?

在发送?masterauth 等相关信息,?REPLCONF 等相关信息?

?

后面和全量同步相关比较重要的流程就是?发送?SYNC?相关命令?

?

然后?slave?这边会收到?master?这边的?FULLRESYNC?的通知?

?

然后就是后面?slave?这边创建临时文件,?然后准备接受?master?这边?后台持久化 rdb?文件之后传递给?slave?这边,?之后的处理交给?readSyncBulkPayload

?

接受服务器这边传输过来的 rdb?文件的相关信息,?持久化到?上面创建的临时文件 repl_transfer_tmpfile

?

然后就是 清空 slave?本地数据库,?然后重命名?临时文件 为?dump.rdb

然后加载?dump.rdb 到?slave?本地数据库?

?

触发上面?syncWithMaster 的地方,?从上下文是可以看到是?serverCron 注册了一个定时任务,?100ms 跑一次,?跑的任务是?clusterCron 相关,?里面包含了这里的?connectWithMaster

所以节点的上下线?是可以再 100ms 左右感知到的?

?

客户端这边相关日志如下,?基本上是?syncWithMaster + readSyncBulkPayload 这两部分中输出的?

前面两行是 connectWithMaster 中输出的连接?master?的相关日志?

后面的是?slave?这边向?master?发送 PING, master 进行回复?

后面的是?slave?这边发送?SYNC?指令,?询问是否可以增量同步,?master 这边回复?只能全量同步

然后是?slave?这边接收到了?master?的?dump.rdb?的数据信息,?合计210字节,?清空?slave?的数据库,?从?dump.rdb 中加载数据到?slave?的数据库,?最终同步成功?

?

?

master 的处理

需要全量同步的有几个场景?

场景1?是?slave 未传递同步偏移,?或者偏移传递错误?

场景2?是?master 和?slave?两边的?replyid 对不上?

场景3?是?slave 这边传递的偏移不在?master?这边数据同步的偏移区间内, 偏移错误?或者 落后的太多

?

然后就是?master?这边处理全量同步的大头了?

场景1?如果是已经在进行?dump 内存快照文件,?则等待即可?

场景2?如果是已经在?dump?内存快照,?并且通过?tcp 直接传输数据,?则只能等待操作完成?

场景3?master 可以?dump?内存快照,?或者直接通过 tcp?传输数据,?

?

处理如下,?通过?startBgsaveForReplication 进行逻辑上的分发?

是?dump?内存快照文件,?还是?dump内存快照直接通过 tcp?传输数据?

?

然后这里就是?fork?出子进程,?让子进程?来 dump?内存快照,?并保存到目标文件?

?

然后 master?这边有定时任务在定时检查?子进程是否完成, 周期为?1秒?

如果完成了,?则向?slave?这边传输?dump?的内存快照的数据?

?

master 这边日志如下?

slave 这边发送过来了?PSYNC 的请求?

然后?master?这边判断?replyid,?replyid2 匹配不上,?然后开始进行?全量同步?

然后?master?开始进行 dump?内存快照,?fork 子进程?来生成 dump.rdb

master dump 内存快照生成完成之后,?发送数据到?slave, 之后记录?成功日志

?

?

基于?backlog 的增量同步

master 这边添加增量命令到?backlog

命令到 server.call:3765 的时候,?会将命令添加到?backlog 队列?

其中存储的数据就是?具体的执行命令,?存储在了一个数据中, 比如这里的?“set name4 jerry17”, 会将其存储为?一个长度为3的数组,?元素分别为?[“set”, “name4”, “jerry17”]

?

具体的复制命令到 backlog?中的相关处理如下,?可以简单理解为一个?memcpy 进去,?然后更新?索引 repl_backlog_idx

?

?

slave 这边长时间和?master?失联,?重新连接之后发送?PSYNC?增量同步请求

clusterCron 为定时任务,?定时扫描集群的状态,?如果失联了,?则重新建立连接?

同样是在?syncWithMaster 的代码中, 这里传入了?replyid 和?offset?到?master?

?

?

master 这边获取增量的命令响应给客户端

比如这里传输了?134 字节的命令数据到客户端, 我们?再来看一下 详细的命令信息

?

从响应的字符串信息中可以看到,?传输了?“select 0”, “set name4 jerry18”, “set name4 jerry19”, “set name4 jerry20” 四条命令,?其中?“select 0” 是?redis?自己增加的,?然后?其他的几个命令是 客户端这边交互产生的

?

?

slave 这边收到命令之后执行

客户端这边接收到这一批次的命令之后,?依次进行执行?“select 0”, “set name4 jerry18”, “set name4 jerry19”, “set name4 jerry20” 进而实现了增量的同步?

?

?

完

?

?

?