每天5分钟|redis主从复制带来的问题

Posted 2021-04-07 老何漫话

我,是跑在服务器上的redis程序，也叫redis节点。

以前我一个人负责对外提供服务，日子虽然忙碌，但孤单寂寞且枯燥乏味。

自从运维搞了主从模式之后，我身边每天都很热闹，有一帮从节点跟在我屁股后面，我的英文名叫master,他们叫slave。

作为大哥，我负责读和写，而从节点小弟们只能负责读，而且他们的数据都是从我这儿同步。（毕竟是小弟嘛，干的不能比大哥多）

这种感觉，就好像我是太阳，他们是月亮和地球，都围着我转。

这天，我和几个从节点小弟们在聊天，小弟们最近心情不好，我作为大哥当然要跟他们做好辅导，毕竟大哥要有大哥的样子。

从节点小A率先发言：大哥,自从部署主从之后运维对我有些不满，说我同步数据延迟，导致前台用户注册的时候用户重复注册，我感觉很委屈。

我：主从之间同步数据需要时间，延迟肯定会有，这点不怪你。而且解决方案我也给他们了。

从节点小B一脸好奇地凑过来，微笑着说道：小A你好好讲讲呗，说说具体是啥情况，以后运维找我们论理，我们也好有个心理准备。

从节点小A：那天我正在跟主节点同步数据，并对外提供读服务。隐约听到，有开发跑过去找运维说，自己的业务逻辑是查询从库判断是否记录过用户，没有的话就把用户写到主节点，然后去我从节点查询数据，但此时数据还没有同步到我机器上，程序发现没有注册，于是又注册了一次，导致数据重复。我当时一听，心想完了，这运维水平不高，待会儿肯定定要找我麻烦，果然，还没等开发说完，他俩就携手冲到了我面前。我吓坏了，这事儿我没经验啊。

小A喝了口水，继续说道：幸好大哥及时赶过来，帮我挡住了。

从节点小B：那大哥是怎么解决的？'

看着大家一脸崇拜的表情，我假装淡定，翘着二郎腿说道：其实呢，主从复制一定会有同步延迟，不可避免。咱们主从模式主要是为了分摊服务器的负载，做读写分离，提高服务的并发，同时还能保证热备份，保证高可用。但同步延迟这样的问题，我们也只能尽量缩短主从同步的延迟时间。我给他们的方案是，如果对时间延迟要求严格，可以在这些业务里面读写都走主节点，这样就不会有这个问题啦，另外我也提出，让我这个主节点和我的从节点们都在一个局域网内，这样我们之间的连接也会更稳定，减少一些不必要的延时。

小弟们听完，纷纷鼓掌，从节点小C还顺势递过来一只烟。

我接过烟，叼在嘴里，看着小c说：小c最近怎么样，有遇到什么困难吗？

小c给我点完烟，笑道：大哥，我这儿最近还有点问题想跟您聊聊！

深吸一口烟，快活似神仙。我立马精神起来：说吧，都是自家兄弟，不必拘束，有话只管讲。

小c：大哥，我们之间同步可不可以尽量都走部分复制，少走全量复制，这样对各自性能的消耗都会小很多，也能减少延时，您觉得怎么样。

说完，小c不敢抬头，生怕我会生气。

我一听，乐了，夸赞道：你这个想法太好了，和我想的一毛一样，这是我刚写的建议书，你们过来看。

我打开了建议书，叼着烟说道：“你们看看我写的怎么样，主要列举了一下全量复制的危害！

建议书内容如下：

各位尊敬的老板，领导和运维，你们好！

关于全量复制的危害，我给你们写了一下

第一.每次bgsave我需要fork子进程，如果内存数据很大，那么，占用的内存和CPU的开销就会很大

第二.RDB文件一般都不小，因此很占用网络带宽

第二.增加了从节点清空数据的时间

第四.增加了从节点加载RDB的时间

第五.如果从节点开启了AOF，则加载完RDB后会对AOF进行一个重写，保证AOF是最新的，增加了从节点aof重写的时间

希望各位老板，领导和运维能够引起重视。

---你们的redis主节点 master

不到200个字，大家低头看了20多分钟，似乎都在思考着什么。

突然，一阵掌声打破了宁静，随即，全场掌声响起。

带头鼓掌的小C啧啧称赞：大哥字写得真好。

”这不是拍马屁的时候，我就写了这么点，大家有什么建议？“

小A举手说道：大哥，我建议再写一下全量复制的出现场景和规避的方案，毕竟老板他们不想要问题，他们要解决方案！

我一听，很有想法的少年，激动地说道：既然你主动提出这个建议，那么你来说说！

小A:我觉得第一种场景是不可避免的，就是我们第一次和主节点同步的时候，这时我们必须要全量同步，毕竟第一次嘛！这种就没啥好的优化方案了，只能硬着头皮全量同步了。

小A无奈的摇摇头，却听到小f在人群中大声说道：”我有办法“

小f身体强壮，胸肌发达，连语气都是那么的粗壮有力，说道：既然全量同步免不了，那就在其他方面想办法嘛。可以在凌晨这种服务器负载低的时候进行全量同步嘛。

看着大家吃惊的眼神，小f骄傲地走回了人群中。

或许是小f的发言给了小b灵感，小b说道：那我也有办法，可以控制主节点的内存空间呀，主节点的空间不能太大，比如主节点只有2g或者3g，那样每次全量的数据量就小了。

见没人补充，小a继续说道：全量复制出现的第二个场景是节点runid不匹配的时候，当主节点宕机重启之后，主节点的runid就会发生变化，如果我们从节点还存的是上一次的runid，一旦发现runid不匹配，就会发生全量复制。这种问题，我倒是有个解决的办法。

小a得意地看了我一眼，我也心领神会的回应了一个眼神，让他继续说。

小a:Redis提供了debug reload的重启方式，重启后，主节点的runid和offset都不受影响，避免了全量复制。 

我补充了一下，说”redis4.0的版本，做了这个处理，避免了重启之后全量复制的情况出现，具体的原理，我会在后面单独给大家说“

说完，再次给了小a一个继续的眼神。

小a :发生全量复制的第三个场景就是当从节点在加载rdb文件的时候，主节点会把新的写命令写到复制积压缓冲区空间这个队列里面，队列默认只有1m的数据，空间超过1m的数据的时候，后面进来的数据会把前面的踢掉，当从节点上报自己的偏移量时，主节点会检测提交的偏移量offset是否在自己的缓冲区里面，不在的话，也会发生全量复制，不过这个问题的解决方案，增大这个复制缓存空间的大小就可以降低全量复制发生的频率。

”是的，这些建议很不错，还有别的场景吗？“我问道

小d补充说：其他还有一些比如断电啊，或者从节点宕机导致从节点的偏移量和主节点相差较大，导致要全量复制。

”嗯，这些情况也会出现，不过这些还是要依赖一些客观的硬件和运维日常的维护了。“

看大家都没人继续发言，我感觉大家总结的不错，正准备做总结陈词。

平时我最疼爱的小e走到了人群中间，大声的喊道”我还有一个想法“；

大家都很好奇，小e平时就会拍马屁，还能想出啥好点子，都目不转睛地盯着他。

小e紧接着说道，”大哥作为一个主节点，服务于我们5个从节点，太辛苦了，我觉得~“

还没等小e说完，大家都开始嘘他，人群中不断传出”这家伙真是个拍马屁的好手“”这时候还在拍马屁“~~

我赶紧打断了大家的喧闹，示意小e继续。

小e说道：大哥作为主节点，每天给我们这些小弟同步数据，他的压力很大，我想，我可不可以帮大哥分担一点，你们看，以前我们是这样的。

说着，在白板上画了起来。

这种结构下，大哥每天fork进程同步数据很辛苦，还要负责客户端的写命令，负载压力本来就大，而且大哥这么疼爱我，有一次，大哥只有一个馒头，他自己没舍得吃，还给我吃~~，还没说完，小e就嚎啕大哭起来。

我最受不了别人哭了，赶紧制止了他，说道”害，这都是我做大哥应该的，你说说你想到了什么好建议，我听听“

小e哽咽着说道：大哥你看我这种结构如何？

小e又画了了起来。

我一看，觉得很不错，这种树状结构的主从结构，让我只要同步数据给一个从节点，而其他从节点只要从他那儿同步数据即可，这样很大程度上降低了我的负载压力。

我再也控制不了我自己了，激动地冲上去搂住了小e，我就知道，我没有白疼你。

其实，关于主从复制的一些坑还有很多，我就先整理了这么多，大家如果有遇到的坑点，可以下方留言，我们共同交流哈。

id:laohemanhua

看到不转发，等于白嫖！