搜索引擎背后到底隐藏了什么不为人知的的秘密---GFS-CSDN博客

本文链接：https://blog.csdn.net/ZYZ_123BlueEye/article/details/119342192

搜索功能大家肯定都接触过，在浏览器上查询资料、在淘宝上找漂亮衣服、微信搜索去找资源等等，现在的我们都已经习惯了搜索功能的存在，可是在如今的社会，所有的事物都在互联网上连接起来，随着社会的不断发展，新鲜事物不断涌出，海量的数据不断累积，从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 Architecture
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上其他副本的修改执行顺序。大概的执行逻辑如下：
Write Control and Data Flow

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服务器链推送。