类Redis大容量存储-Pika主从复制原理之工做流程

类Redis大容量存储-Pika主从复制原理之工做流程

bigpyer 360云计算

女主宣言

在上一篇文章《pika主从复制原理之binlog》中介绍了主从复制binlog的元信息、日志的格式及对应的api，本篇介绍下主从复制有关的线程、全量复制过程、增量复制过程。本文一样出自小米的公司的bigpyer，感谢他的分享！
PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！

pika

pika 是 360 Web 平台部 DBA 与基础架构组合做开发的大容量类 Redis 存储，pika 的出现并非为了替代 Redis，而是 Redis 的场景补充。pika 力求在彻底兼容 Redis 协议、继承 Redis 便捷运维设计的前提下经过持久化存储的方式解决 Redis 在大容量场景下的问题，如恢复时间慢、主从同步代价高、单线程相对脆弱、承载数据较有限、内存成本高昂等。

pika主从复制原理之工做流程

线程

PikaBinlogReceiverThread: 系统启动时初始化，占用端口port+1000，做为Slave接收Master同步过来的Redis命令。

PikaHeartbeatThread: 系统启动时初始化，占用端口port+2000，做为Master接收Slave发送的ping、spci指令，对全部Slave进行存活检测。

PikaTrysyncThread: 系统启动时初始化，无角色，执行slaveof host port命令对应的后台任务包括按期检查是否须要跟某个Master创建链接、db替换、启动或关闭rsync任务等,当启动rsync服务时，占用端口port+3000。

PikaSlavepingThread: 成为某个Master的Slave后，做为Slave的一方初始化，定时向Master发送ping、spci指令，若是超时超过30秒，生成之后关闭Master的后台任务，由PikaBinlogReceiverThread来执行。

BinlogBGWorker: 系统启动时初始化，每一个BinlogBGWorker包含一个binlogbg_thread，做为Slave的后台执行模块，接收PikaBinlogReceiverThread的调度、执行具体的redis命令。

PikaBinlogSenderThread: 成为某个Slave的Master后，做为Master的一方初始化，根据slave传过来的filenum、offset消费日志，并发送到PikaBinlogReceiverThread所在的服务端口。

类图

PikaBinlogReceiverThread

PikaBinlogSenderThread

主要API描述

Thread

//初始化
int Thread::InitHandle()

//执行线程内的定时任务
void Thread::CronHandle()

//建立线程，调用RunThread()
int Thread::StartThread()

//处理逻辑入口函数
void *Thread::RunThread(void *arg)

HolyThread

virtual int InitHandle()

1. 初始化epoll监听事件，并将套接字加入server_fds

virtual void *ThreadMain()

1. 调用CronHandle，检测是否存在须要执行的定时任务，若是有则执行。
2. 若是server_fds上存在EPOLLIN事件，则接受链接请求，创建slave-master链接
3. 若是是slave-master链接上存在EPOLLIN事件，则调用in_conn->GetRequest()进行具体redis命令处理。
4. 若是是slave-master链接上存在EPOLLOUT事件，则调用in_conn->SendReply()发送应答。

   PikaBinlogReceiverThread

//执行后台任务，PikaSlavepingThread检测到应该退出或者主挂掉时，添加Kill PikaBinlogSenderThread后台任务。

void PikaBinlogReceiverThread::CronHandle()

PikaMasterConn

int PikaMasterConn::DealMessage()

1. 若是存在monitor，则将当前命令发到monitor一份(即redis的monitor命令)。
2. 生成全局日志序号serial，保证按顺序并发写入slave binlog。
3. 若是是只读，则由PikaBinlogReceiverThread完成binlog日志的追加，不然由PikaBinlogReceiverThread分配的BinlogBGWorker完成。

BinlogBGWorker

void Schedule()

1. 第一次调度时启动后台线程。
2. 经过DoBinlogBG执行具体的后台任务。

void BinlogBGWorker::DoBinlogBG(void* arg)

1. 根据解析的参数获取须要执行的命令。
2. 若是slave非只读，则获取一个全局记录锁(应该是用不到的)。
3. 记录binlog。
4. 执行命令。
5. 记录慢日志。

Slaveof流程图

slave

master

slaveof过程

1.若是是slaveof no one,中止rsync服务，删除master，replstate = PIKA_REPL_NO_CONNECT，role=master

2.若是slaveof ip port filenum offset，则将filenum以前的binlog删除，同时若是filenum存在，则将offset以前的文件内容填充空格。

3.role更新为slave，repl_state更新为PIKA_REPL_CONNECT，应答成功。
//后台任务部分

4.PikaTrysyncThread检测到repl_state==PIKA_REPL_CONNECT，在端口port+3000启动rsync服务，准备接受master的db内容。

5.slave创建与master的链接，若是有auth，则主动发送auth命令。

6.发送trysync命令，主动要求master进行数据同步。

7.若是master应答结果为kInnerReplWait，则replstate = PIKA_REPL_WAIT_DBSYNC。

8.slave会一直等待，直到db_sync_path目录下存在info文件时，用新的db替换以前的db，根据info中的filenum、offset更新slave对应的filenum、offset，重置replstate = PIKA_REPL_CONNECT

9.再次执行3-6步骤，master应答kInnerReplOk，更新replstate = PIKA_REPL_CONNECTING，停掉rsync服务，建立PikaSlavepingThread，在PikaSlavepingThread ping master成功之后更新replstate = PIKA_REPL_CONNECTED，主从同步正式创建。

trysync过程

1.根据slave的ip、port构造slave的惟一标识,stage=SLAVE_ITEM_STAGE_ONE。

2.若是master没有找到slave传过来的filenum，则执行bgsave，生成一份db镜像和info信息，经过rsync传给slave，并清理掉master的临时文件

3.根据slave的ip、port，bgsave的filenum、offset构建PikaBinlogSenderThread

4.过滤binlog中可能已经损坏的内容(什么场景可能会用到?可能主从数据不一致吗?)

5.更新role_ = PIKA_ROLE_MASTER，PikaSlavepingThread第二次存活检测时发送spci命令，主根据PikaBinlogSenderThread，更新stage=SLAVE_ITEM_STAGE_TWO，主从同步正式创建。

结语

我的认为主从复制是pika里面体量最大也是最复杂的一个模块，经过采用了相似LevelDB的WAL日志的方式，固然因为redis命令的问题，这个日志非幂等的，不是为了在启动时重放，而是解决了redis中增量复制buffer被打满的问题。
原文地址：
http://www.jianshu.com/p/d969b6f6ae42?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=qq