兄弟,用大白话给你讲小白都能看懂的分布式系统容错架构【石杉的架构笔记】

欢迎关注微信公众号:石杉的架构笔记(id:shishan100) ​ ​ ​ 个人新课《C2C 电商系统微服务架构120天实战训练营》在公众号儒猿技术窝上线了,感兴趣的同窗,能够点击下方连接了解详情: ​ 《C2C 电商系统微服务架构120天实战训练营》面试

目录

(1)TB级数据放在一台机器上:难啊!redis

(2)到底啥是分布式存储?算法

(3)那啥又是分布式存储系统呢?数据库

(4)天哪!某台机器宕机了咋办?性能优化

(5)Master节点如何感知到数据副本消失?服务器

(6)如何复制副本保持足够副本数量微信

(7)删除多余副本又该怎么作呢?markdown

(8)全文总结架构

“ 这篇文章,咱们将用很是浅显易懂的语言,跟你们聊聊大规模分布式系统的容错架构设计。虽然定位是有“分布式”、“容错架构”等看起来略显复杂的字眼,可是我们仍是按照老规矩:大白话 + 手绘数张彩图,逐步递进,让每一个同窗都能看懂这种复杂架构的设计思想。并发

一、TB级数据放在一台机器上:难啊!

我们就用分布式存储系统举例,来聊一下容错架构的设计。

首先,咱们来瞧瞧,到底啥是分布式存储系统呢?

其实特别的简单,我们就用数据库里的一张表来举例。

好比你手头有个数据库,数据库里有一张特别大的表,里面有几十亿,甚至上百亿的数据。

更进一步说,假设这一张表的数据量多达几十个TB,甚至上百个TB,这时你以为咋样?

固然是心里感到恐慌和无助了,由于若是你用MySQL之类的数据库,单台数据库服务器上的磁盘可能都不够放这一张表的数据!

我们就来看看下面的这张图,来感觉一下。

二、到底啥是分布式存储?

因此,假如你手头有一个超大的数据集,几百TB!那你仍是别考虑传统的数据库技术来存放了。

由于用一台数据库服务器可能根本都放不下,因此咱们考虑一下分布式存储技术?对了!这才是解决这个问题的办法。

我们彻底能够搞多台机器嘛!好比搞20台机器,每台机器上就放1/20的数据。

举个例子,好比总共20TB的数据,在每台机器上只要把1TB就能够了,1TB应该还好吧?每台机器均可以轻松加愉快的放下这么多数据了。

因此说,把一个超大的数据集拆分红多片,给放到多台机器上去,这就是所谓的分布式存储。

我们再看看下面的图。

三、那么啥又是分布式存储系统呢?

那分布式存储系统是啥呢?

分布式存储系统,固然就是负责把一个超大数据集拆分红多块,而后放到多台机器上来存储,接着统一管理这些分散在多台机器上存储的数据的一套系统。

好比说经典的hadoop就是这类系统,而后fastdfs也是相似的。

若是你能够脑洞打开,从思想本质共通的层面出发,那你会发现,其实相似elasticsearch、redis cluster等等系统,他本质都是如此。

这些都是基于分布式的系统架构,把超大数据拆分红多片给你存放在多台机器上。

我们这篇文章是从分布式系统架构层面出发,不拘泥于任何一种技术,因此姑且能够设定:这套分布式存储系统,有两种进程。

一个进程是Master节点,就在一台机器上,负责统一管控分散在多台机器上的数据。

另一批进程叫作Slave节点,每台机器上都有一个Slave节点,负责管理那台机器上的数据,跟Master节点进行通讯。

我们看看下面的图,经过图再来直观的看看上面的描述。

四、天哪!某台机器宕机了咋办?

这个时候又有一个问题了,那么万一上面那20台机器上,其中1台机器宕机了咋整呢?

这就尴尬了,兄弟,这会致使原本完整的一份20TB的数据,最后有19TB还在了,有1TB的数据就搞丢了,由于那台机器宕机了啊。

因此说你固然不能容许这种状况的发生,这个时候就必须作一个数据副本的策略。

好比说,咱们彻底能够给每一台机器上的那1TB的数据作2个副本的冗余,放在别的机器上,而后呢,万一说某一台机器宕机,没事啊,由于其余机器上还有他的副本。

咱们来看看这种多副本冗余的架构设计图。

上面那个图里的浅蓝色的“1TB数据01”,表明的是20TB数据集中的第一个1TB数据分片。

图中能够看到,他就有3个副本,分别在三台机器中都有浅蓝色的方块,表明了他的三个副本。

这样的话,一份数据就有了3个副本了。其余的数据也是相似。

这个时候咱们假设有一台机器宕机了,好比下面这台机器宕机,必然会致使“1TB数据01”这个数据分片的其中一个数据副本丢失。以下图所示:

那这个时候要紧吗?没关系,由于“1TB数据01”这个数据分片,他还有另外2个副本在存活的两台机器上呢!

因此若是有人要读取数据,彻底能够从另外两台机器上随便挑一个副原本读取就能够了,数据不会丢的,没关系张,大兄弟。

五、Master节点如何感知到数据副本消失?

如今有一个问题,好比说有个兄弟要读取“1TB数据01”这个数据分片,那么他就会找Master节点,说:

“你能不能告诉我“1TB数据01”这个数据分片人在哪里啊?在哪台机器上啊?我须要读他啊!”

咱们来看看下面的图。

那么这个时候,Master节点就须要从“1TB数据01”的3个副本里选择一个出来,告诉人家说:

“兄弟,在哪台哪台机器上,有1个副本,你能够去那台机器上读“1TB数据01”的一个副本就ok了。”

可是如今的问题是,Master节点此时还不知道“1TB数据01”的副本3已经丢失了,那万一Master节点仍是通知人家去读取一个已经丢失的副本3,确定是不能够的。

因此,咱们怎么才能让Master节点知道副本3已经丢失了呢?

其实也很简单,每台机器上负责管理数据的Slave节点,都每隔几秒(好比说1秒)给Master节点发送一个心跳。

那么,一旦Master节点发现一段时间(好比说30秒内)没收到某个Slave节点发送过来的心跳,此时就会认为这个Slave节点所在机器宕机了,那台机器上的数据副本都丢失了,而后Master节点就不会告诉别人去读那个丢失的数据副本。

你们看看下面的图,一旦Slave节点宕机,Master节点收不到心跳,就会认为那台机器上的副本3就已经丢失了,此时绝对不会让别人去读那台宕机机器上的副本3。

那么此时,Master节点就能够通知人家去读“1TB数据01”的副本1或者副本2,哪一个都行,由于那两个副本其实仍是在的。

举个例子,好比能够通知客户端去读副本1,此时客户端就能够找那台机器上的Slave节点说要读取那个副本1。

整个过程以下图所示。

六、复制副本保持足够副本数量

这个时候又有另一个问题,那就是“1TB数据01”这个数据分片此时只有副本1和副本2这两个副本了,这就不足够3个副本啊。

由于咱们预设的是每一个数据分片都得有3个副本的。你们想一想,此时如何给这个数据分片增长1个副本呢?

很简单,Master节点一旦感知到某台机器宕机,就能感知到某个数据分片的副本数量不足了。

此时,就会生成一个副本复制的任务,挑选另一台机器来从有副本的机器去复制一个副本。

好比看下面的图,能够挑选第四台机器从第二台机器去复制一个副本。

可是,如今这个复制任务是有了,咱们怎么让机器4知道呢?

其实也很简单,机器4不是每秒都会发送一次心跳么?当机器4发送心跳过去的时候,Master节点就经过心跳响应把这个复制任务下发给机器4,让机器4从机器2复制一个副本好了。

一样,咱们来一张图,看看这个过程:

看上图,如今机器4上是否是又多了一个“1TB数据01”的副本3 ?那么“1TB数据01”这个数据分片是否是又变成3个副本了?

七、删除多余副本

那反过来,若是说此时机器3忽然恢复了,他上面也有一个“1TB数据01”的副本3,至关于此时“1TB数据01”就有4个副本了,副本不就多余了吗?

不要紧,一旦Master节点感知到机器3复活,会发现副本数量过多,此时会生成一个删除副本任务。

他会在机器3发送心跳的时候,下发一个删除副本的指令,让机器3删除本身本地多余的副本就能够了。这样,就能够保持副本数量只有3个。

同样的,你们来看看下面的图。

八、全文总结

好了,到这里,经过超级大白话的讲解,还有十多张图的渐进式演进说明,相信你们之前即便不了解分布式系统,都绝对能理解一个分布式系统的完整的数据容错架构是如何设计的了。

实际上,这种数据分片存储 、多副本冗余、宕机感知、自动副本迁移、多余副本删除,这套机制,对于hadoop、elasticsearch等不少系统来讲,都是相似的。

因此笔者在这里强烈建议你们,必定好好吸取一下这种分布式系统、中间件系统底层数据容错架构的思想。

这样,之后学习相似的一些技术的时候,对他们的原理、思想都会感到一种似曾相识的感受。

End

若有收获,请帮忙转发,您的鼓励是做者最大的动力,谢谢!

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码,持续关注:

石杉的架构笔记(id:shishan100)

十余年BAT架构经验倾囊相授

推荐阅读:

一、拜托!面试请不要再问我Spring Cloud底层原理

二、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问?

三、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

四、微服务架构如何保障双11狂欢下的99.99%高可用

五、兄弟,用大白话告诉你小白都能听懂的Hadoop架构原理

六、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问

七、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍

八、拜托,面试请不要再问我TCC分布式事务的实现原理!

九、【坑爹呀!】最终一致性分布式事务如何保障实际生产中99.99%高可用?

十、拜托,面试请不要再问我Redis分布式锁的实现原理!

十一、【眼前一亮!】看Hadoop底层算法如何优雅的将大规模集群性能提高10倍以上?

十二、亿级流量系统架构之如何支撑百亿级数据的存储与计算

1三、亿级流量系统架构之如何设计高容错分布式计算系统

1四、亿级流量系统架构之如何设计承载百亿流量的高性能架构

1五、亿级流量系统架构之如何设计每秒十万查询的高并发架构

1六、亿级流量系统架构之如何设计全链路99.99%高可用架构

1七、七张图完全讲清楚ZooKeeper分布式锁的实现原理

1八、大白话聊聊Java并发面试问题之volatile究竟是什么?

1九、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能?

20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解?

2一、大白话聊聊Java并发面试问题之公平锁与非公平锁是啥?

2二、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化

2三、互联网公司的面试官是如何360°无死角考察候选人的?(上篇)

2四、互联网公司面试官是如何360°无死角考察候选人的?(下篇)

2五、Java进阶面试系列之一:哥们,大家的系统架构中为何要引入消息中间件?

2六、【Java进阶面试系列之二】:哥们,那你说说系统架构引入消息中间件有什么缺点?

2七、【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer的面试经历

2八、【Java进阶面试系列之三】哥们,消息中间件在大家项目里是如何落地的?

2九、【Java进阶面试系列之四】扎心!线上服务宕机时,如何保证数据100%不丢失?

30、一次JVM FullGC的背后,竟隐藏着惊心动魄的线上生产事故!

3一、【高并发优化实践】10倍请求压力来袭,你的系统会被击垮吗?

3二、【Java进阶面试系列之五】消息中间件集群崩溃,如何保证百万生产数据不丢失?

3三、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(上)?

3四、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(中)?

3五、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(下)?

3六、亿级流量架构第二弹:你的系统真的无懈可击吗?

3七、亿级流量系统架构之如何保证百亿流量下的数据一致性(上)

3八、亿级流量系统架构之如何保证百亿流量下的数据一致性(中)?

3九、亿级流量系统架构之如何保证百亿流量下的数据一致性(下)?

40、互联网面试必杀:如何保证消息中间件全链路数据100%不丢失(1)

4一、互联网面试必杀:如何保证消息中间件全链路数据100%不丢失(2

4二、面试大杀器:消息中间件如何实现消费吞吐量的百倍优化?

4三、高并发场景下,如何保证生产者投递到消息中间件的消息不丢失?

做者:石杉的架构笔记 连接:juejin.cn/post/684490… 来源:掘金 著做权归做者全部,转载请联系做者得到受权!

相关文章
相关标签/搜索