Video在线视频

好 这一节我们继续讨论

Google文件系统的一个

特殊的一个所谓放松的一致性

那么我们前面知道

Google文件系统用一套

协议的方式

维持这个数据块的一致性

那么在Google文件系统当中

我们在讨论

它的放松的一致性之前

我们再说一下

Google文件系统

对于数据的一个修改的一个操作

另外一个操作

叫做Appand操作

那么之前我们看到

这个里面是一个write操作

那么为什么只讨论这两个操作

不讨论读的操作呢

原因很简单

就是读的操作

它不会去修改数据

所以它不会影响数据的内容

所以它不会影响一致性

所以考虑这些呢

无非就是说我们看一下

Appand操作和write操作

它的顺序的一个问题

Appand操作

它有特殊的一个地方

它是叫做Atomic appand

什么叫Atomic Appand

就是它是原子性的追加

要么我这个数据

追加到文件系统的一个末尾

要么这个数据根本就没有出现

那么这个方式

为什么需要提供呢

我们可以想一下

Google文件系统它的用户是谁

用户就是它的搜索引擎

搜索引擎的话

有一个最前端的爬从

爬从的话

从网上把数据抓下来之后

会写到Google文件系统当中去

但是爬从在写数据的时候

它其实并不关心这个数据

写到文件的哪个位置

你只要把这个数据写进去

并且写这三个副本

并且这三个副本写得完全一样

就OK了

那么至于之后呢

因为这个爬从它是不关心的

所以在这个之后的程序

它可以从头到尾去扫描

那么在这个情况下

我要提供Appand操作的话

其实在写完之后

从客户端的角度来说

他是不知道

写到具体的一个位置的

那这一件事情

对于传统的文件系统

是不可以接受的

传统文件系统

你写入的时候

你是可以通过系统调用

或者你自己经过写入的一个跟踪

你是知道文件当前的写入位置的

但是Appand你是不知道的

所以在从

文件系统功能的角度来说

那个GFS

已经提供了一些新的一些功能

跟传统文件系统

不一样的一个功能

那么我们还看到了一个

写入的一个操作

那么这两个操作

会影响整个文件系统的一致性

好 那么一致性呢

分成两个层面

那么一个叫做Consistent

那么叫做文件的三个副本

它是一致的

另外叫做明确的Defined

就是说真正反映了客户端的操作

那大家回忆一下

实际上在本期文件系统里面

你写入什么东西

只要在写入和下一次读取之间

没有新的一个

在同样的一个区域写入的话

你读的数据

就应该是你写的数据

但是在分布式文件系统当中

GFS当中却不能这样的一个保证

那么比如说

我对一个文件F

我需要写入一块数据

那么写入怎么写呢

那么我们现在写入

因为我们需要支持多个客户端

对吧

那么我用A和B这两个客户端

那么A和B这个客户端

我要做一个写入操作

那么写完操作之后

这是写入操作

那么它们都写入到

这一块区域里面去

那么最后写的内容

如果是传统文件系统的话

它要么是A 要么是B

它不可能是A和B

其他方面的一个值 对不对

但是在Google文件系统里面

不是这样的

它写完之后

它有可能既不是A 也不是B

但是这个数据呢

在三个副本当中是一样的

那么有的同学会很奇怪

怎么会出现这种情况

那么我们需要解释一下

就比较明白了

那我们看一个

特殊的一个写的操作

比如说我有一个64M

我们知道数据块的大小分成64M

那么不管是A也好 B也好

它就正好是跨了

这个数块的一个边界

所以因为我要维持

这个数据块的一个边界

这样的话

我在Google文件系统在内部

它会把一个写操作

A这个写操作

分成两个写操作

分别是A1操作和A2操作

B1操作和B2操作

那么在这个时候呢

同学可能就会比较明白了

因为在拆分完了之后

A1 B1和A2 B2

其实是没有关系的

对吧

所以在这一部分数据

有可能写完了之后

这一部分数据

是先写A1 再写B1

这一部分先写B2 再写A2

这样的话

最后的结果是B1 A2

那么既不是A

又不是B

但是这个数据在三个副本上面

按照我们前面的协议

它们是完全一样的

三个副本都是B1 A2

但是却不反映客户端的

真正的写入的操作

所以这个操作就代表是

叫做Consistnet它的noteDefined

所以下面这个表格

就给出了Google文件系统当中

放松的一致性的一个工作

那么比如说

如果有单个客户端的话

顺序写入的话

那么写入操作

肯定是一致且明确的

就是说我只有一个人写

那么写完之后

肯定是反映这个人写的操作

但是如果是并发写得话

那么肯定是一个一致的状态

如果是写成功了

这些都是写成功的情况下

那么是一个一致的状态

三个人数据副本一样

但是数据并不一定是明确的

就是不一定反映了客户端的操作

这里我们给了一个例子

那这是关于写入操作的一个

一致性的定义

另外还有一个

追加操作的一致性的定义

因为追加操作在写完之后

其实你是不知道数据的

是不是它的具体的地址的

那么追加操作写完了之后

它的数据肯定是一致的

但是不一定会反映

用户的追加操作

原因是这样

比如说我现在的文件

末尾是在这个位置

但是再加上1M

正好是在64M的边界

所以我再追加一块数据的时候呢

比如说这个数据块的

追加数据块比如说是40M

那你再追加到这1M末尾的话

可能性能会比较差

所以40M最好是追加到

一个完整的块里面

这样的话

在前面的那个块的最后的末尾

那么我可能需要补充一些

打补丁的那些数据

就是把它塞满的那些数据

那么塞满什么样的数据呢

实际上无所谓

就是说我把它塞满就行了

对吧

那么这三个数据

可能是不一致的 对吧

所以这个追加操作

是一致且明确的状态

确实反映了用户追加的操作

但是

在这些一致明确的数据中间

会夹杂着一些不一致的数据你

对吧

这个我已经解释过了

在这儿

那么对于写入的操作的话

那数据是不一致的状态

那不一致的状态

我们就不需要切分了

好 那可以看到

这个Google里面放松的一致性

那么它实际上是为了性能的考虑

所以它把一致性的条件给放松了