从谷歌 GFS 架构设计聊开去

【这是一猿小讲的第  62  篇原创分享】

伟人说:“人多力量大。”

尼古拉斯赵四说:“没有什么事,是一顿饭解决不了的!!!如果有,那就两顿。”

研发说:“需求太多,人手不够。”

专家说:“人手不够,那就协调资源,攒人头。”

释义:一人拾柴火不旺,众人拾柴火焰高。一人难挑千斤担,众人能移万座山。

运维说:“一台机器不够;一个服务扛不住压力。”

专家说:“一台机器不够,那就多申请几台;一个服务扛不住压力,那就多部署几个。”

释义:一箭易断,十箭难折。一根线容易断,万根线能拉船。

从事互联网开发时间久了,参加大大小小的会议,时不时总会讨论或争执类似“人手不够、机器不够、服务扛不住”等一类的资源问题,但是到最后解决方案,貌似都是进行资源协调。如果人手不够,就协调资源攒人头;如果机器不够,就协调资源加几台;如果一个服务扛不住压力,那就协调资源多部署几个。

所有的一切都离不开: 攒、加 ... ... ,总之就是考虑如何从 1 到 N 。

拜读 GFS 的论文,熟读 N 篇系列文章,静下来想想 GFS 架构设计,多少都透了着一丝“众人拾柴火焰高、人多就是力量大”的想法,接下来就一起对 GFS 认识认识。

认识

到底是个啥? GFS 是一个把大量廉价的普通机器,聚在一起,充分让每台廉价的机器发挥光和热,具有高可用、高性能、高可靠、可扩展的分布式文件系统。

解剖

善于发现美。 如上图所示,GFS 架构的参与角色,主要分为 GFS master(主服务器)、GFS chunkserver(块存储服务器)、GFS client(客户端)。

我们姑且认为 GFS master 是古代的皇上,统筹全局,运筹帷幄。主要负责掌控管理所有的文件系统的元数据,包括 文件和块的命名空间,从文件到块的映射,每个块所在的节点位置 (说白了,要维护哪个文件存在哪些文件服务器上的元数据信息);并且定期通过心跳机制与每一个 GFS chunkserver 通信,向其发送指令并收集其状态。

我们姑且认为 GFS chunkserver 是宰相,因为宰相肚子里面能撑船,主要提供 chunks 数据块的存储服务,以文件的形式存储于 chunkserver 上,能够海纳百川,有容乃大。

我们姑且认为 GFS client 是使者,对外提供一套类似传统文件系统的 API 接口,对内主要与皇帝通信来获取元数据;然后直接和宰相交互来进行所有的数据操作。

好奇

背后如何运转? 懵懂 GFS 架构设计的参与角色主要有皇上、诸多宰相、诸多使者构成,但是他们之间是如何协作运转的呢?

我要写入一个文件, GFS 架构背后流转是咋回事?如上图所示,主要分为 7 大步骤进行。

第一步:GFS client 向 GFS master 查询待写入的 chunk 的 GFS chunkserver(宰相)信息;

释义:使者请求皇上要发起写数据操作,皇上会告诉使者找哪几个宰相去办理。

第二步:GFS master 返回 GFS chunkserver 列表,其中返回的 chunkserver 分为 1 主 2 从;

释义: 皇上告诉使者去找  Primary 主宰相 + AB 两个从宰相(主宰相有话语权,从宰相听从主宰相的命令)。

第三步:GFS client 将数据发送至 GFS chunkserver,chunkserver 会缓存这些数据,此时数据并不落盘;

释义: 使者把数据发送给所有宰相,宰相先把数据缓存一下,并不塞到肚子里。

第四步:GFS client 向主 GFS chunkserver 发起同步写入请求;

释义: 使者告诉 Primary 主宰相可以把数据吞到肚子里了;

第五步:主 GFS chunkserver 将数据写入本地磁盘并通知其他从 GFS chunkserver 将数据数据落盘;

释义: Primary 主宰相开始把数据吞到肚子里,并通知 AB 两个从宰相将数据吞到肚子里;

第六步:主 GFS chunkserver 等待所有从 GFS chunkserver 的数据处理响应;

释义: Primary 主宰相等待 AB 两个从宰相数据处理响应结果;

第七步:主 GFS chunkserver 给 GFS 客户端返回数据写入成功响应。

释义: Primary 主宰相告诉使者本次的数据写入成功了。

结论:想要谁存找皇上;数据存储找宰相;1主两从存三份。

我要读取一个文件, GFS 架构背后又是怎么流转的呢?懵懂了写文件的运转流程,那读文件的流转就相对简单了不少。

第一步:GFS client 从本地缓存,看文件存储在哪些 chunk-server 上;

使者从自己缓存中找找文件是由哪些宰相负责;

第二步:如果 GFS client 本地缓存没有找到,就向 GFS master 查询文件所在位置;

使者从自己缓存中找不到文件是由哪些宰相负责,就请求皇上查询有哪些宰相负责存储;

第三步:GFS master 返回 GFS chunkserver 列表给 GFS client;

皇上返回存储文件的宰相列表给使者;

第四步:从返回的 chunk-server 里读文件,返回给 GFS client。

使者找离自己最近的宰相发出读请求,然后宰相内容返回给使者。

结论:要最快查缓存;缓存没有找皇上;数据就找近宰相。

反思

架构这么设计为什么? 是不是在耍流氓!

GFS master 为什么是单点? 简单就是美!

GFS chunk 块大小为什么选择 64M 呢?

GFS 的高可用、高性能、高可靠是怎么保证的?

最后,再多说两句。 谷哥“三驾马车”的出现,才真正把我们带入了大数据时代,而 GFS 作为其中一架宝车,能够把大量廉价的普通机器,聚在一起,充分让每台廉价的机器发挥光和热,不但降低了运营成本,而且经受了业界实际生产的考验,本次只是 GFS 管中窥豹,只见得其中一斑,GFS 背后还有很多值得我们学习的地方,慢慢去体会。

好了, 如果感觉这篇文章有点意思,请多多分享转发吧。

推荐阅读:

从经典的一道菜“京酱肉丝”聊懂集群分布式

数据是啥?数据都去哪儿了?

妈妈再也不用担心,我学不会大数据 flink 啦

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章