您好、欢迎来到现金彩票网!
当前位置:2019欢乐棋牌 > 主从复制 >

浅谈Redis主从复制

发布时间:2019-06-15 22:50 来源:未知 编辑:admin

  Redis是一个开源的,遵守BSD许可协议的key/value缓存系统,并由其高效的响应速度以及丰富的数据结构而闻名。Redis在京东的使用也是非常普遍的,包括很多关键业务上的使用,由于Redis官方集群还未发布,在使用Redis的过程中需要面对Redis的单点问题,京东采用的是一种比较通用的解决方案即由主从备份再加相应的主从切换(在一些场景下可能进行读写分离),使主Redis出现失效的时候可以快速的切换到从Redis上。但Redis目前存在的一个问题是主从复制在遇到网络不稳定的情况下,Slave和Master断开(包括闪断)会导致Master需要将内存中的数据全部重新生成rdb文件(快照文件),然后传输给Slave。Slave接收完Master传递过来的rdb文件以后会将自身的内存清空,把rdb文件重新加载到内存中。这种方式效率比较低下,尤其是在数据量大的情况下,毕竟网络闪断未必丢数据或者说丢的数据只是少部分,但却要为此付出将整个内存数据都重新传输一次的代价。如果能够将闪断过程的更新数据传递给Slave,那么就不需要将Master内存中的所有数据都传递给Slave了。Redis作者在2.8的候选版(以下简称Redis2.8)中已经将这个部分复制的思路实现了。

  那么Redis2.4.16的全量复制与Redis2.8的部分复制是如何实现的呢?如下图所示,这5个状态是Slave在主从复制过程涉及到的几个状态,其中REDIS_REPL_NONE是Redis启动时候默认的状态。图1-2所示的四个状态表示站在Master的角度来看,Slave所处于的状态,因为Slave在Master端看来就是一个特殊的client(同理Master在Slave端看来也是一个特殊的client)。

  在上述状态转图中存在的最大问题在于任何网络闪断都会导致Slave与Master重连,然后重新进入快照过程,需要花费较长的时间重新传输rdb文件,而Slave在接收完rdb文件以后试图将rdb文件恢复到内存的过程中是不能服务的(除info命令外)。所以提供部分复制至少可以做到在网络闪断且更新命令不太多的情景下能够尽量的避免全量复制的方案就显得尤为重要。

  庆幸的是Redis2.8中里已经能够做到在网络闪断的情况下,Slave重新连接上Master以后,仅仅只传输闪断期间的更新命令。在Redis2.8中redisServer结构中增加了一个成员:

  该runid是由一个getRandomHexChars()函数生成的每次不同的一个唯一标识,不同Redis实例之间该runid是不同的,同一个Redis重启以后,其runid和之前的runid也是不同的。

  Slave与Master完全同步以后,maste的更新命令会被存到repl_backlog中,同时不断更新偏移量等相关变量。这些更新命令不断地被发送到Slave端,Slave也随之更改自己记录的偏移量。当期间再次有网络断开的情况,Slave会根据记录的runid和reploff向Master请求部分复制,Master检查Slave请求的偏移量对应的内容是否还在repl_backlog中,即比较repl_backlog_off和Slave传递过来的reploff的值的差是否小于等于repl_backlog中实际数据的长度,如果满足条件则将这部分内容发送给Slave,部分复制完成。否则让Slave进行全量复制。

  Redis2.8之前的版本没有提供部分复制功能,当出现网络闪断的情况会导致主从之间的全量复制。Redis2.8增加了部分复制功能,在处理网络闪断的情况下是非常有效的,这也是出Redis集群之前需要提供的基本保证。默认1Mb的repl_backlog在访问量大的情况下可能效果未必理想,这个可以通过更改配置文件中的repl-backlog-size的值实现repl_backlog的大小的调整。还有repl_backlog在没有Slave的情况下过多久再释放的时间阈值也可以通过配置文件中的repl-backlog-ttl进行调整。

  每日头条、业界资讯、热点资讯、八卦爆料,全天跟踪微博播报。各种爆料、内幕、花边、资讯一网打尽。百万互联网粉丝互动参与,TechWeb官方微博期待您的关注。

http://api-crypt.com/zhucongfuzhi/26.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有