设为首页 收藏本站
查看: 709|回复: 0

[经验分享] 《Redis源码学习笔记》主从复制

[复制链接]

尚未签到

发表于 2016-12-20 08:41:41 | 显示全部楼层 |阅读模式
《Redis源码学习笔记》文章列表
由于图片较大,缩放较为模糊,请双击打开查看原图 ^_^
主从复制简单来说就是把一台redis数据库中的数据同步到另一台redis数据库,并且按照数据流向,数据的发送者我们称作master,数据的接受者我们称作slave(master/slave的划分并不是那么一定的,譬如B可以作为A的slave,但同时也可以作为C的master),下面就从slave和master的角度分别说明主从复制流程。
首先是slave端,对于slave端来说,主从复制主要经历四个阶段:
第一阶段:与master建立连接
第二阶段:向master发起同步请求(SYNC)
第三阶段:接受master发来的RDB数据
第四阶段:载入RDB文件
下面我们就通过一个图来概述在每一个阶段中,slave究竟做了些什么:
DSC0000.png
关于上图,有一点说明下:redis接收到slaveof master_host master_port命令后并没有马上与master建立连接,而是当执行服务器例行任务serverCron,发现自己正处于REDIS_REPL_CONNECT状态,这时才真正的向maser发起连接,伪代码:
def serverCron():
# 服务器处于REDIS_REPL_CONNECT状态
if redisServer.repl_state == REDIS_REPL_CONNECT:
# 向master发起连接
connectWithMaster()
# 其他例行任务(省略)...

接着我们来看下主从复制过程中,master这边的流程是如何,在具体看细节之前,我们先综合来看master这边主要做的几件事情:
DSC0001.png
看完这个图,你也许会有以下几个疑问:
1. 为什么在master发送完RDB文件后,还要定期的向slave发送PING命令?
2. 在发送完RDB文件之后,master发送的“变更”命令又是什么,有什么用?
在回答问题之前1,我们先回答问题2:
master保存RDB文件是通过一个子进程进行的,所以master依然可以处理客户端请求而不被阻塞,但这也导致了在保存RDB文件期间,“键空间”可能发生变化(譬如接收到一个客户端请求,执行"set name diaocow"命令),因此为了保证数据同步的一致性,master会在保存RDB文件期间,把接受到的这些可能变更数据库“键空间”的命令保存下来,然后放到每个slave的回复列表中,当RDB文件发送完master会发送这些回复列表中的内容,并且在这之后,如果数据库发生变更,master依然会把变更的命令追加到回复列表发送给slave,这样就可以保证master和slave数据的一致性!相关伪代码:
def processCommand(cmd, argc, argv):
# 处理命令
call(cmd, argc, argv)
# 如果该命令造成数据库键空间变化and当前redis是一个master,则同步变更命令
if redisServer.update_key_space and len(redisServer.slaves) > 0:
replicationFeedSlaves(cmd, argc, argv)
def replicationFeedSlaves(cmd, argc, argv):
# 把变更命令发送给每一个处于:REDIS_REPL_WAIT_BGSAVE_END状态的slave节点
for slave in redisServer.slaves:
if slave.replstate == REDIS_REPL_WAIT_BGSAVE_START:
continue
slave.updateNotify(cmd, argc, argv)

由于在发送完RDB文件之后,master会不定时的给slave发送“变更”命令,可能过1s,也可能过1小时,所以为了防止slave无意义等待(譬如master已经挂掉的情况),master需要定时发送“保活”命令PING,以此告诉slave:我还活着,不要中断与我的连接
现在我们就看下,当master接受到slave发送的sync同步命令后究竟发生了哪些事:
DSC0002.png
上图看似分支复杂,但我们抓住以下几点即可:
1.保存RDB文件是在一个子进程中进行的;
2.如果master已经在保存RDB文件,但是没有客户端正在等待这次BGSAVE,新添加的slave需要等到下次BGSAVE,而不能直接使用这次生成的RDB文件(原因图中已经说明)
3.master会定期检查RDB文件是否保存完毕(时间事件serverCron);
接下来我们看下,master是如何给每一个slave发送RDB文件的:
DSC0003.png
好了,至此我们已经分析完在主从复制过程中,master和slave两边分别是怎么一个处理流程;最后,我绘制了一个图,综述了主从复制这一过程(我们可以边看图,边回忆其中的具体细节):
DSC0004.png
PS:在主从复制过程中,任何一步发生错误,都会导致整个过程重头开始,所以若RDB文件很大又或是此时正处在业务高峰期,对系统性能将会有非常大的影响!
总结:
1. 了解主从复制master和slave的概念;
2. 了解主从复制执行过程,特别是其中关键的几步;
3. 了解目前主从复制过程中尚存的不足之处;

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-316696-1-1.html 上篇帖子: redis 多线程与阉割版 下篇帖子: redis(四)-pub/sub 发布/订阅
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表