阿里云能放企业网站吗,用iis做网站,电商平台怎么运营的,抖音代运营方案计划书前言
我们这里首先来看 redis 这边实现比较复杂的 replication集群模式
我们这里主要关注的是 redis 这边的主从同步的相关实现
这边相对比较简单, 我们直接基于 cluster集群模式 进行调试 主从命令同步复制
比如这里 master 是 redis_7002, slave 是 redis_7005
然后 这…前言
我们这里首先来看 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” 进而实现了增量的同步 完
