关于我们
热线电话?/div>

互联网大会

当前位置:主页 > 互联网大会 >

Redis面试热点工程架构篇之数据同步

发布时间:2020-10-26

前面用了3篇文章介绍了一些底层完结和工程架构相关的问题,鉴于Redis的热门问题仍是比较多的,因而今日持续来看工程架构相关的问题,感兴趣的能够先回忆一下之前的3篇文章,如下:

|Redis面试热门之底层完结篇

|Redis面试热门之底层完结篇

经过本文你将了解到以下内容:

Redis的数据同步机制

耐久化和数据同步的联系、Redis散布式存储的CAP挑选、Redis数据同步仿制和异步仿制、全量仿制和增量仿制的原理、无盘仿制等。

Q:谈谈你对Redis数据同步的了解吧!

了解耐久化和数据同步的联系,需求从单点毛病和高可用两个视点来剖析:

假定咱们现在只要一台作为缓存的Redis机器,经过耐久化将热门数据写到磁盘,某时刻该Redis单点机器发作毛病宕机,此期间缓存失效,主存储服务将接受一切的恳求压力倍增,监控程序将宕机Redis机器拉起。

重启之后,该机器能够Load磁盘RDB数据进行快速康复,康复的时刻取决于数据量的多少,一般秒级到分钟级不等,康复完结保证之前的热门数据还在,这样存储体系的CacheMiss就会下降,有用下降了缓存击穿的影响。

在单点Redis中耐久化机制十分有用,只写 文字简略让咱们睡着,我画了张图 :

作为一个高可用的缓存体系单点宕机是不答应的,因而就呈现了主从架构,对主节点的数据进行多个备份,假设主节点挂点,能够马上切换状况最好的从节点为主节点,对外供给写服务,而且其他从节点向新主节点同步数据,保证整个Redis缓存体系的高可用。

如图展现了一个一主两从读写别离的Redis体系主节点毛病搬迁的进程,整个进程并没有中止正常作业,大大提高了体系的高可用:

从上面的两点剖析能够得出个小定论:

耐久化让单点毛病不再可怕,数据同步为高可用插上翅膀。

咱们了解了数据同步对Redis的重要作用,接下来持续看数据同步的完结原理和进程、重难点等细节问题吧!

对散布式存储有了解的读者必定知道CAP理论,说来惭愧笔者在2018年3月份换作业的时分,去Face 旷视科技面后端开发岗位时就遇到了CAP理论,除了CAP理论问题之外其他问题都在射程内,所以终究仍是拿了Offer。

可是形象很深T大结业的面试官说前面的问题答得都不错,为啥CAP问题答得这么菜…其实我其时只知道CAP理论就像高富帅相同,不那么简略到达...细节不清楚...各位吃瓜读者,笔者前面说这个小事情的意图是想表达:CAP理论关于了解散布式存储十分重要,下回你们面试被问到CAP别怪我没提示。

在理论核算机科学中,CAP定理又被称作 布鲁尔定理Brewer's theorem ,这个定理起源于加州大学伯克利分校的核算机科学家埃里克 布鲁尔在2000年的散布式核算原理研讨会PODC上提出的一个 猜测 。

在2002年麻省理工学院的赛斯 吉尔伯特和南希 林奇宣布了布鲁尔 猜测的证明 ,使之成为一个 定理 。它指出关于一个散布式核算体系来说,不可能一同满意以下三点:

来看一张阮一峰大佬画的图:

举个简略的比方,阐明一下CP和AP的兼容性:

CP和AP问题

了解CP和AP的关键在于分区容忍性P,网络分区在散布式存储中再往常不过了,即便机器在一个机房,也不可能全都在一个机架或一台交换机。

这样在局域网就会呈现网络颤动,笔者做过1年多DPI关于网络传输中最深入的三个名词: 丢包、乱序、重传 。所以 咱们看来惊涛骇浪的网络,在服务器来说可能是风大浪急 ,一不小心就不通了,所以当网络呈现断开时,这时就呈现了网络分区问题。

关于Redis数据同步而言,假定从结点和主结点在两个机架上,某时刻发作网络断开,假设此刻Redis读写别离,那么从结点的数据必定无法与主持续同步数据。在这种状况下,假设持续在从结点读取数据就形成数据不共同问题,假设强制保证数据共同从结点就无法供给服务形成不可用问题,然后看出在P的影响下C和A无法统筹。

其他几种状况就不深入了,从上面咱们能够得出定论: 当Redis多台机器散布在不同的网络中,假设呈现网络毛病,那么数据共同性和服务可用性无法统筹,Redis体系对此有必要做出挑选,事实上Redis挑选了可用性,或许说Redis挑选了别的一种终究共同性。

终究共同性

Redis挑选了终究共同性,也便是不保证主从数据在任何时刻都是共同的,而且Redis主从同步默许是异步的,亲爱的盆友们不要晕!不要蒙圈!

我来一下解说 同步仿制和异步仿制 :

一图胜千言,看赤色的数字就知道同步仿制和异步仿制的区别了:

Redis挑选异步仿制能够防止客户端的等候,更契合实际要求,不过这个仿制方法能够修正,依据自己需求而定吧。

从从仿制

假定Redis高可用体系中有一主四从,假设四个从一同向主节点进行数据同步,主节点的压力会比较大,考虑到Redis的终究共同性,因而Redis后续推出了从从仿制,然后将单层仿制结构演进为多层仿制结构,笔者画了个图看下:

全量仿制是从结点由于毛病康复或许新增加从结点时呈现的初始化阶段的数据仿制,这种仿制是将主节点的数据悉数同步到从结点来完结的,所以本钱大但又不可防止。

增量仿制是主从结点正常作业之后的每个时刻进行的数据仿制方法,涓涓细流同步数据,这种同步方法又轻又快,长处的确不少,不过假设没有全量仿制打下根底增量仿制也没戏,所以二者不是对立存在而是相互依存的。

Redis的全量仿制进程首要分三个阶段:

学习参阅1的一张图表,写的很好,我就不再重复画图了:

考虑一个多从 并发全量仿制问题 :

假设此刻有多个从结点一同向主结点建议全量同步恳求会怎样?

Redis主结点是个聪明又诚笃的家伙,比方现在有3个从结点A/B/C连续向主节点建议SYNC全量同步恳求。

再考虑一个 快照仿制循环问题 :

主节点履行bgsave是比较耗时且耗内存的操作,期间从结点也阅历装载旧数据- 开释内存- 装载新数据的进程,内存先升后降再升的动态进程,然后知道不管主节点履行快照仍是从结点装载数据都是需求时刻和资源的。

抛开对功能的影响,试想假设主节点快照时刻是1分钟,在期间有1w条新指令到来,这些新指令都将写到缓冲区,假设缓冲区比较小只要8k,那么在快照完结之后,主节点缓冲区也只要8k指令丢掉了2k指令,那么此刻从结点进行全量同步就缺失了数据,是一次过错的全量同步。

无法之下,从结点会再次建议SYNC指令,然后堕入循环,因而缓冲区巨细的设置很重要,二话不说再来一张图:

增量仿制进程略微简略一些,可是十分有用,试想杂乱的网络环境下,并不是每次断开都无法康复,假设每次断开康复后就要进行全量仿制,那岂不是要把主节点搞死,所以增量仿制算是对杂乱网络环境下数据仿制进程的一个优化,答应一段时刻的落后,终究追上就行。

增量仿制是个 典型的生产者-顾客模型 ,运用定长环形数组来完结,假设buffer满了那么新数据将掩盖老数据,因而从结点在仿制数据的一同向主节点反应自己的偏移量,然后保证数据不缺失。

这个进程十分好了解,kakfa这种MQ也是这样的,所以在合理设置buffer巨细的前提下,理论上从的消费才能是大于主的生产才能的,大部分只要在网络断开时刻过长时会呈现buffer被掩盖,从结点消费滞后的状况,此刻只能进行全量仿制了。

了解无盘仿制之前先看下什么是有盘仿制呢?

所谓盘是指磁盘,可能是机械磁盘或许SSD,可是不管哪一种比较内存都更慢,咱们都知道IO操作在服务端的耗时是占大头的,因而关于全量仿制这种高IO耗时的操作来说,特别当服务并发比较大且还在进行其他操作时对Redis服务自身的影响是比较大大,之前的形式时这样的:

在Redis2.8.18版别之后,开发了无盘仿制,也便是防止了生成的RDB文件落盘再加载再网络传输的进程,而是流式的遍历发送进程,主节点一边遍历内存数据,一边将数据序列化发送给从结点,从结点没有改变,依然将数据顺次存储到本地磁盘,完结传输之后进行内存加载,可见无盘仿制是对IO更友爱。

时刻原因只能写这么多了, 和咱们一同学习不是把桶填满而是把火点着 。

回忆一下:本文首要叙述了耐久化和数据同步的联系、Redis散布式存储的CAP挑选、Redis数据同步仿制和异步仿制、全量仿制和增量仿制的原理、无盘仿制等,信任耐性的读者必定会有所收成的。

最终能够考虑一个问题:

Redis的数据同步依然会呈现数据丢掉的状况,比方主节点往缓冲区写了10k条操作指令,此刻主挂掉了,从结点只消费了9k操作指令,那么切主之后从结点的数据就丢掉了1k,即便旧主节点康复也只能作为从节点向新主节点建议全量仿制,那么咱们该怎么优化这种状况呢?