搜索功能大家肯定都接触过,在浏览器上查询资料、在淘宝上找漂亮衣服、微信搜索去找资源等等,现在的我们都已经习惯了搜索功能的存在,可是在如今的社会,所有的事物都在互联网上连接起来,随着社会的不断发展,新鲜事物不断涌出,海量的数据不断累积,从2G网络到5G网络,存储大小也从我们最开始认识的KB(千字节)慢慢发展到MB、GB、TB甚至PB、EB(1PB=1000TB,1EB=1000PB),面对如此之大的数据,搜索引擎怎么存储的下,甚至很快的就对客户的搜索要求做出反应呢?答案便是GFS!
GFS (Google File System)
GFS,Google公司为了存储海量搜索数据而设计的专用文件系统,是一个大规模可扩展的分布式文件系统,类似的腾讯(Tencent)的TFS,淘宝(Taobao)的TFS,都是模仿GFS来改写的适应他们自己的要求。【不懂分布式?分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器,处理更多的数据。】
通俗来讲,GFS系统把文件的存储部署在成千上万台廉价机器服务器上面,相当于把一项很大的任务要求,分解成了很多个小块,也保证快速可靠有效。举个例子,亚洲最大的腾讯数据中心机房,腾讯天津数据中心,有十万台以上的服务器,承载着腾讯里在华北地区QQ、微信、游戏、视频等核心业务。单说10万台服务器服务器可能不太直观,我假定硬盘的平均容量为4TB,每台2U服务器12个硬盘计算, 可提供总容量480万TB,或者4800PB,或者4.8EB的数据。够你存几十忆部高清大片了,了解过一些存储云的伙伴知道,一般像阿里云,百度云,腾讯云他们可以免费提供差不多一两百G的私人云空间吧,通过一些会员服务可以扩容几个T,一个数据中心这样分配下去,应该也有过亿的月薪哈哈,当然腾讯不会那么短浅,更多的存储空间去赚其他更多的钱了。
GFS那么多,服务器故障是视为常态的,但是这并不影响它的使用,GFS把机器故障视为正常现象,可以很好地处理系统故障。GFS系统通常会部署在上百台甚至上千台廉价服务器上,并会有相当多台廉价服务器上部署GFS Client来访问GFS服务,所以应用故障、操作系统bug、连接故障、网络故障、甚至机器供电故障都是经常发生的故障。GFS系统可以支持系统监控、故障检测、故障容忍和自动恢复,提供了非常高的可靠性。其次,GFS系统中的文件一般都是大文件,且文件操作大部分场景下都是附写而不是重写覆盖。一旦文件写入完成后,大部分操作都是读文件且是顺序读。
GFS框架
GFS系统包括master、多个chunkserver(chunk服务器)以及多个client。文件被切分为固定大小的小文件(chunk)。每个chunk创建时,master会分配一个64bit的全局唯一且不可修改的chunk handle来标志这个chunk。chunkserver负责将chunk存储在本地磁盘的Linux文件中,并通过chunk handle和byte range来读写chunk文件。为了提高可靠性,每个chunk都是多副本存储在多个chunkserver上,默认情况下是三副本。用户可以为不同名字空间下的文件配置不同的副本数。
GFS master是系统的元数据(数据的数据)服务器,维护的元数据包括:命令空间(GFS按层级目录管理文件)、文件到chunk的映射,chunk的位置。其中,前两者是会持久化的,而chunk的位置信息来自于Chunkserver的汇报。
GFS master还负责分布式系统的集中调度:chunk lease管理,垃圾回收,chunk迁移等重要的系统控制。master与chunkserver保持周期性的心跳,以确定chunkserver的状态。
GFS client是给应用使用的API,这些API接口与POSIX API类似。GFS Client会缓存从GFS master读取的chunk信息(即元数据),尽量减少与GFS master的交互。
单一Master节点
单一的Master节点可以通过全局的信息精确定位Chunk的位置以及进行复制决策。另外,我们必须减少对Master节点的读写,避免Master节点成为系统的瓶颈。客户端并不通过Master节点读写文件数据。反之,客户端向Master节点询问它应该联系的Chunk服务器。客户端将这些元数据信息缓存一段时间,后续的操作将直接和Chunk服务器进行数据读写操作。其实很好理解,Master它只用来做一个类似记录的目录,来对接,还有一些其他的系统控制。我知道它像什么了,像一个领导,可以把它看作管理层领导,实际干真活啥也不交给他,只是用来对接,控制管理它下属的Chunkserver就行,有啥任务直接安排给Chunkserver。
Chunk尺寸
Chunk的大小是关键的设计参数之一。默认选择是64MB,这个尺寸远远大于一般文件系统的Block size。每个Chunk的副本都以普通Linux文件的形式保存在Chunk服务器上,只有在需要的时候才扩大。惰性空间分配策略避免了因内部碎片造成的空间浪费,内部碎片或许是对选择这么大的Chunk尺寸最具争议一点。
选择较大的Chunk尺寸有几个重要的优点。首先,它减少了客户端和Master节点通讯的需求,因为只需要一次和Master节点的通信就可以获取Chunk的位置信息,之后就可以对同一个Chunk进行多次的读写操作。这种方式对降低工作负载来说效果显著,因为应用程序通常是连续读写大文件。即使是小规模的随机读取,采用较大的Chunk尺寸也带来明显的好处,客户端可以轻松的缓存一个数TB的工作数据集所有的Chunk位置信息。其次,采用较大的Chunk尺寸,客户端能够对一个块进行多次操作,这样就可以通过与Chunk服务器保持较长时间的TCP连接来减少网络负载。第三,选用较大的Chunk尺寸减少了Master节点需要保存的元数据的数量。
系统交互
数据更改主要指chunk的write(覆盖原有数据)或者append(文件尾部追加数据)操作。数据的修改会在chunk的所有副本上执行,GFS使用lease(租约)机制来保证chunk副本上修改操作的执行顺序。master将lease颁发给chunk的一个副本(replica),称之为primary,primary然后选择chunk上其他副本的修改执行顺序。大概的执行逻辑如下:
1、client向master查询chunk的primary所在的chunkserver以及其他副本的分布,如果没有primary的话,master会选择一个作为该chunk的primary。
2、master回复client primary和其他副本的分布信息。client会cache(缓存下载)返回的metadata(元数据)。
3、client将数据发送所有的副本。client可以以任意顺序执行。每个chunkserser都会在内存的LRUbuffer中记录数据。
4、当所有的副本都返回已经接收数据成功后,client会向primary发送一个写请求。primary会为每一个数据更改的请求附加一个序列号,数据更改是按照序列号的顺序执行的。
5、primary将数据更改同步到其他副本中,副本也是按照序列号执行数据更改操作。
6、primary接收到其他副本回复的数据操作完成。
7、primary返回client结果。期间发生的所有错误都会报给client。
GFS的数据流,采取数据流与控制消息分开,且采用链式推送方法,目标是最大化利用每个机器的网络带宽,避免网络瓶颈和高延迟连接,最小化推送延迟。在控制流从客户机到主Chunk、然后再到所有二级副本的同时,数据以管道的方式,顺序的沿着一个精心选择的Chunk服务器链推送。
写在最后
感兴趣的小伙伴可以阅读Google大数据三大论文—GFS了解更多,也欢迎大家留言讨论一起交流!
参考文献:
- https://www.jianshu.com/p/5b3f278f8bde
薛少佳 Google文件系统–GFS详解 - https://blog.csdn.net/weixin_45216439/article/details/91410583
Google大数据三大论文–GFS——中文翻译