redis主从复制原理详解(Redis主从复制原理)

为什么要主从同步

下面图1是redis单实例场景图示,图2是redis主从实例场景图示。实践过程中,相比单实例,主从实例有三个优点

  1. 从库可提供读服务(read),可扩展服务读的能力(需要考虑主从复制过程中的数据时延问题)
  2. 提高服务可用性,在主库不可用的情况下,可把从库切为主库
  3. 防止数据丢失,在主库因为磁盘等原因导致数据丢失时,从库的数据可继续使用
redis主从复制原理详解(Redis主从复制原理)

图1、单实例场景

redis主从复制原理详解(Redis主从复制原理)

图2、主从场景

主从同步方案

那怎么进行主从复制呢?主要是快照同步和增量同步配合进行,下面详细介绍

快照同步

redis主从复制原理详解(Redis主从复制原理)

快照同步

快照同步步骤

  1. 当前时刻主库数据bgsave持久化到磁盘存储下来(rdb)
  2. rdb文件网络传输到从库
  3. 从库基于rdb文件恢复到从库服务

增量同步

redis主从复制原理详解(Redis主从复制原理)

增量同步

增量同步步骤

  1. 主库有写入和修改命令,写入到定长buffer(定长buffer是指这个buffer的长度可配置,但是一旦超过长度,会把之前的数据进行覆盖,类似buffer圆环机制)
  2. 定长buffer数据增量同步到从库,从库反馈当前同步的偏移位(主库根据偏移位确定是继续增量同步,还是重试,还是走快照同步)

同步场景说明

  1. 新加的从库,走快照同步;快照同步之后,基于快照时刻开始进行增量同步
  2. 增量同步时,如果偏移位没有变化,还是之前的位置,表明这次同步未成功,则主库需要进行同步重试
  3. 增量同步时,如果由于网络问题,一直没成功,偏移位很早,数据已经没有在buffer中,则需要再走一次快照同步(buffer长度设置较为关键,避免出现频繁快照同步)

主从哨兵机制 Sentinel

主从实例部署之后,如果主库不能提供服务(宕机等),从库切到主库,以达到持续提供服务。但是从上面图示看,还是人工运维的阶段,恢复时长取决于运维同学什么时候进行切换,比如晚上凌晨或者节假日可能就不一定及时,方案上也不优雅。

redis提供了哨兵机制来解决这个问题,哨兵机制系统自动切换

redis主从复制原理详解(Redis主从复制原理)

Sentinel机制

说明

  1. 这里Sentinel集群起到redis主从监控检测和主从切换的作用,发现主库挂掉之后,把从库中最优的节点提升为主库,原主库降为从库
  2. client读写请求故障后,向Sentinel发起请求(获取最小主从信息),更新本地的主从实例地址
  3. 这里Sentinel集群多台机器,也是为了保证哨兵的高可用

消息丢失

当主库挂掉,最优从库节点可能还有一部分数据没从主库同步过来,就被提升到主库,可能会存在消息丢失的情况。如果主从时延比较大,丢失的更多(架构选型上需要考虑这块)。

redis调优配置上也支持一些配置

## 最少有几个从库进行了成功同步,否则主库禁写

min-slaves-to-write=1

## 这里是对成功同步标准定义,时延在多少秒以内算成功

min-slaves-max-lag=10

附件(图片稿)

https://github.com/dasen-li/doc (yEd 3.21.1 )

    

使用无须实名的阿里云国际版,添加 微信:ksuyun  备注:快速云

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 cloud@ksuyun.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.hanjifoods.com/20613.html