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

[经验分享] Redis(六):Redis主从复制(1)原理

[复制链接]

尚未签到

发表于 2018-11-5 06:34:55 | 显示全部楼层 |阅读模式
  关于主从复制
  和MySQL的主从一样,这种结构主要是为了数据冗余和提示性能。Redis的主从同步是异步进行的,所以并不会影响主的处理性能。在数据持久化方面,可以把这个任务交给从服务器来做,这样可以减小主服务器的负担。
  在主从结构中,一般把从服务器设置为只读模式,这样也是为了更好的保持数据一致性。
  原理(参考《Redis设计与实现》)
  Redis主从同步有两种方式,一种是全同步部分同步,当然执行哪种同步是自动判断的无需人工干预。
  Redis的复制功能分为同步(SYNC)和命令传播(COMMAND PROPAGATE)两个操作:

  •   同步操作:将从服务器的数据库状态更新至主服务器当前所处的状态
  •   命令传播:当主服务器数据被修改后,通过命令传播使主从数据库状态一致
  旧版(Redis 2.8以前)的复制功能实现
  上面提到同步有两种方式全同步和部分同步,在旧版中只有全同步没有部分同步。同步过程如下:

  •   从服务器向主服务器发送SYNC命令
  •   主服务器收到SYNC命令后执行BGSAVE命令,在后台生成一个RDB文件,并使用缓冲区记录从现在(当BGSAVE执行的那一刻)开始执行的所有写命令。
  •   当主服务器使用BGSAVE命令执行完毕后,主服务器会将RDB文件发送给从服务器,从服务器载入这个RDB文件,将自己的数据库状态更新至主服务器执行BGSAVE那一刻的状态。
  •   主服务器将缓冲区里面记录的所有写命令发送给从服务器,从服务器执行这些命令,从而使主从数据库状态一致。
  同步完成后,主服务器的数据也会随着后期的写操作而变化,所以就需要通过命令传播功能把在主服务器上执行的写命令传递给从服务器来实现主从数据库状态一致。
  旧版复制功能的缺陷:

  •   初次复制:从服务器以前没有同步过任何主服务器,或者从服务器当前要同步的主服务器和上次同步的不同
  •   断线后复制:处在同步过程中,但因其他原因导致网络中断,进而造成复制中断,再重新恢复网络连通后的复制。
  对于初次复制整个过程没有问题,但是断线后复制则会执行全同步,这样效率比较低。因为SYNC过程很消耗资源,生成RDB会消耗CPU、内存和磁盘IO资源,发送RDB的过程会占用网络带宽,从服务器载入RDB时会阻塞服务器从而无法处理请求。
  新版(Redis 2.8及以后)的复制功能实现
  在新版中使用了PSYNC来代替SYNC执行同步任务。PSYNC有两种模式也就是上面提到的全同步和部分同步:

  •   全同步用于初次同步,执行过程和SYNC一致
  •   部分同步则重点在于同步断线期间(一定期间而非无限期间)的内容,也就是说在规定期间内执行增量部分的同步,如果超过了规定期间则执行全同步。
  部分同步的三个重要概念:

  •   主服务器的复制偏移量和从服务器的复制偏移量
  •   服务器的复制积压缓冲区
  •   服务器的运行ID
  复制偏移量:主服务器每次给从服务器传递N个字节的数据时,就将自己的复制偏移量增加N,同时从服务器收到N个字节以后,也会再自己的复制偏移量上加N,从而保持主从的复制偏移量一样,这样就可以判断主从的数据库状态是否一致。
  复制积压缓冲区:改缓冲区是一个定长的先进先出的队列,默认是1MB。主服务器把命令传递给从服务器的同时也会向自己的积压缓冲区队列写入这个命令。所以这个缓冲区里面保存了一部分最近的写命令,并且缓冲区会为队列的每个字节记录偏移量。
  当从服务器断线重新连接后,会发送PSYNC命令,同时包含自己的复制偏移量,主服务器根据这个复制偏移量来决定用何种同步方式。如果该偏移量之后的数据(偏移量+1开始的数据)仍然在复制积压缓冲区内,那么执行部分同步,否则执行全同步。
  服务器的运行ID每个Redis服务器都有一个唯一ID标识符,该ID是自动生成的一个40位十六进制字符。当初次复制时,主从服务器会保存彼此的ID,当断线后,从服务器除了向主服务器提供复制偏移量以外还需提供从服务器保存的主服务器的ID,当主服务器接受到ID后,先检查是否和自己的一样,如果一样表示从服务器请求的是一个断线后同步,再根据偏移量来决定执行全同步还是部分同步;如果该ID不是自己的ID,则表示是一个初次同步,则执行全同步。
  在新版中的命令传播,从服务器会以默认每秒的频率向主服务器发送REPLCONF_ACK,该任务会传递从服务器的复制偏移量,同时也是为了进行心跳检测。如果主服务器超过1秒都没有收到从服务器的REPLCONF_ACK,则主服务器会认为连接出现了中断。
  在主服务器的控制台输入INFOreplication可以在lag一栏看到从服务器最后一次向主服务器发送REPLCONF_ACK命令距离限制过了多少,一般该值为0或者1,超过1秒则表示有问题,如下图:
DSC0000.jpg



运维网声明 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-630796-1-1.html 上篇帖子: 细说分布式Redis架构设计和踩过的那些坑 下篇帖子: win7 安装Redis
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

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

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

扫描微信二维码查看详情

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


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


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


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



合作伙伴: 青云cloud

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