Video在线视频

这一节我们需要讲解一下

分布式文件系统的一些基本设计

那么包括

Google文件系统的一些基本设计

那么我们知道文件系统

需要提供两方面的一个功能

一个是那棵目录树的操作

包括原数据的操作

创建目录等这方面的一些工作

另外一个是

对于数据的一个读写

包括打开文件和读写文件

这方面的一些内容

大家想一下

用什么样的最简单的方式

可以达到这个一个目的

那么其实实际上呢

为了提供这个目录树的一个操作

最简单的方式可以用一提机器

去存储这棵目录树

那么在这个环境下面

我们可以这么做

就是我们找一台机器

为了保存这棵目录树

包括它上面的所有的原数据

对吧

那么这台机器只存原数据

那么所有的原数据的操作

比如说应用程序

或者用户去读写这个原数据

比如说列一个目录的时候

那可以直接跟这台机器打交道

那么这是对简单地提供

原数据的方式

那么因为我需要保存大量的

大的文件

所以在这个原数据上面

应该会有一些

关于数据路由的信息

那么可以根据这个文件名

找到具体的结点的一个位置

那么在这里面可能会有

其他的一些服务器

专门存放那些数据

那么用户可以先在这里面

找到对应的原数据

那么这里面就会告诉说

这个文件存在哪个服务器里面

那比如说在这个服务器里面

那么用户就可以直接去跟

服务器打交道就行了

那么这是一个非常简单的设计

那么在Google文件系统里面呢

它也是用了同样的设计

达到完全同样的一个目的

那么这台服务器

一般被称为是一个主服务器

也叫master服务器

那其他的服务器就被称为

是个Chunker服务器

好 这是我们自己设计出来

一个结构

那么Google文件系统的

具体结构就展现在这里

那么我们可以看到

在主服务器的上面

大概就保存了这么一些

目录树的一些信息

这是整个目录树的信息

那么所有的关于目录树的操作

都在主服务器上面

那么所有的原数据

都保存在master服务器上面

那么我们可以看一下

为了达到数据读写的目的

那么原数据大概需要保存一些

什么样的一些内容

那么第一点

目录树也就是命名空间

Namespace是必不可少的

那么用户可以在这个namespace

上面进行浏览

能够找到对应的文件

那么第二个呢

我们知道前期我们在设计的时候

一个文件因为太大了

它会分成64MB

为一个大小的一个数据块

所以这个文件

会在namespace里面出现

那这个文件

它对应的数据块

数据块就叫Chunker

它的对应关系就要保存下来

那么Chunker

会有自己的Chunker ID的号

那么这是第二件事情

那第三件事情

可能比如说设计里面

需要保存这样的一个信息

它是最重要的信息

就是Chunker里面这个数据块

保存到哪些服务器当中去

那么如果我不考虑容错的话

那么一个数据块可能只需要

保存到一个Chunker服务器

就行了

但是为了保证它的可靠性

那么让Chunker服务器

出现错误的时候

我还能够读写到这样的数据

那么可以在这里边

每一个Chunker

需要对应多个Chunker服务器

那大家想一下

有这么多原数据的内容

是不是够了

那么为了考虑这个问题呢

我们可以把整个数据读写的流程

给它走一遍

如果能走得通的话

我们就知道

这个原数据已经完全足够了

对吧

好 在Google文件系统当中

所有的应用程序

它都会被链接到

一个系统的编程库里面

那系统的编程库

实际上就是Google文件系统

那个客户端的一个编程接口

也就是它的APR

那么应用程序

根据客户端的编程接口

它想去读写某一个文件

对吧

那么如果它对于原数据

进行操作的话

那么比如说是创建一个目录

那么它只需

要跟这个master服务器

打交道就可以了

把创建目录的命令交给master

那么这个时候master

就可以做相应的一个处理

对吧

那么如果是对于数据读写的话

那么应用程序

总归要给出一个文件的名字

然后给出一个Chunk index

那么什么叫Chunk idex呢
那实际上因为我们知道

所有的文件都分成多个Chunk

64MB为一块

所以会就Chunk0 Chunk1

Chunk2
这样的一个Chunk的一个号

那么我根据Chunk的号

我就能够找到对应Chunk

在文件当中的一个数据

和对应文件的内容的一个地址

那么把这个请求信息

发给master之后呢

那么

首先master需要做什么事情

master根据

第一部分的原数据信息

可以找到它是不是

在这个名字空间里面

当然如果没有在名字空间里面

就直接返回给用户

找不到文件就行了

然后在名字空间里面

找到这个文件它对应的

所有的数据块的ID

那么这是对应的

在这里面可以找到

对应的数据块的ID

是Chunk1 Chunk2 Chunk3

然后再根据这个Chunk1 2 3

去在里面再找

所有的文件的那个Chunk

然后在这里面去找

某一个Chunk对应的它的服务器

它的Chunk服务器

host1 host2 host3

那么找到这样的话

我们就完整了分布式文件系统

最本质的工作

就是根据一个数据块

它的ID号

可以直接对应到某一个

存储的服务器当中去

那么这是与master的交互

那么master就会把这部分信息

包括它的ChunkID

Chunk也会被称为Chunk handle

然后它的Chunk所在的一个位置

返回给应用程序

那应用程序根据这个信息之后

就把这个信息再与对应的

对应的文件系统的存储服务器

就是那个Chunker服务器

进行打交道 进行通信

然后交给Chunk handle

然后看一下它的字节的范围

在什么范围

那么读作什么样的一个操作

是读操作呢 还是写操作

那么Chunker服务器

自然就会把这个数据

返回给应用程序

那么这个呢

就是整个Google文件系统的一个

工作的一个流程

那么我们可以看到

整个工作流程走完了之后呢

这么多的原数据

就已经完全足够了

能够保证可以找到对应的一个

文件的一个数据

可以对对应的Chunker服务器

进行读写

好 那么这是

Google文件系统一个非常

简单的一个结构

因为它只用一个master服务器

这样的话它会避免很多

分布式算法里面一些复杂性

那么也可以简化整个

文件系统的维护的工作

那么在这里面呢

大家可以看到

就会发现

因为对于整个系统来说

现在有一个单点的结点的问题

什么叫单点的结点的问题

就是这个master

它处于一个特殊的位置

那么处于特殊的位置的话

比如说所有的文件操作

它都要先过一下master

那么我们就得需要考虑

第一个这个master

有没有可能它成为一个

Performers的瓶颈

就是说它有没有可能性能的瓶颈

那么大家都先保证master

那么它如果工作的负荷

非常大的话

会拖慢整个文件系统

另外一个呢

这个master因为它有个单点

所以它可能会出现错误

那么fall Tlant的问题

看看就是说有没有可能

master会出现fall Tlant的问题

当然了

关于Performers和fall Tlant

那个Chunker服务器

也是有相关的问题的

那么我们看一下

关于这些分布式文件系统的

特别是Google文件系统里面的话

它是如何处理这种性能问题

和可靠性问题