The Google File System 翻译和理解( 四 ) _生活百科

2.7 一致性模型GFS 采用弱一致性模型，能很好的支持分布式应用，同时实现上比较简单。我们在这里将讨论 GFS 的一致性保障机制以及其对于应用的意义。我们也将着重描述了 GFS 如何维持这些一致性保障机制，但将一些细节留在了其它章节。
2.7.1 GFS的一致性保障机制文件命名空间修改（如，创建文件）是原子性的。它们仅由主节点进行处理：命名空间锁保障了操作的原子性和正确性；主节点操作日志定义了这些操作的全局排序。
下图是经过修改后的文件区域状态表：

文章插图
一个文件区域（region）在一个数据修改后的状态依赖于该修改的类型、成功或失败、以及是否为同步的修改。表1 总结了一次修改后的结果。

如果所有的客户端无论从哪些副本读取数据，得到的数据都是相同的，则这个文件区域为一致的 consistent 。
在一个文件数据修改后，如果它是一致的，则这个区域已定义 defined ，客户端将看到被写入的全部内容。
当一个修改完全没有受到并发写入操作的影响并成功时，那么影响到的区域已定义（隐含一致性） consistent interspersed undefined：所有的客户端将总会看到修改已经写入的内容。

已定义的一定一致
并发成功的修改使区域处于一致，但未定义状态 consistent but undefined：所有的客户端将看到相同的数据，但是它可能不能反映出任意一个修改已写入的内容。
- 通常，它是由一些来自多个修改操作的、混合的数据碎片组成的。
一致的未必已定义，因为数据一致，但有些操作可能未成功或成功了一半
一个失败的修改会造成区域的不一致性（因此也没有被定义）inconsistent：不同的客户端在不同的时间可能会看到不同的数据。

我们将在后面描述我们的应用如何区分已定义和未定义的区域。这些应用程序不需要更深入的区分不同种类的未定义区域间的区别。
数据修改操作可能是写入 write 或记录追加 append 操作。一个写操作会将数据写入到应用指定的文件位置。偏移位置将被返回给客户端，并标明包含这个记录的已定义区间的开始位置。

如果有多个并发修改操作，一个记录追加操作会将数据（记录）至少一次的原子性的追加到文件，而具体的偏移量是由GFS选定的。
一个通常的追加操作仅仅是将数据追加到客户端认为是当前文件结尾的位置。

此外。GFS 能够在文件中插入数据或复制记录，这种情况下这些数据占据的文件区域被认为为非一致性的，但数量通常比用户数据总量要小很多。
在一系列成功的修改操作后，被修改的文件区域被保证为是已定义的，并且包含了最后一次修改操作写入的数据。GFS通过以下步骤完成上面行为：

在所有副本上按相同的顺序执行一个块上的修改操作（3.1）
使用版本号来检测并复制过期文件（4.5）
- 这种过期可能是由于块服务器宕机而造成了部分修改丢失引起的。过期的副本不会再涉及修改操作，主节点也不会将该副本返回给客户端。它们会尽快的进行垃圾回收操作。

因为客户端缓存了块位置信息，它们可能会在位置信息更新前直接访问到一个过期的副本。这个问题出现的窗口是受缓存条目的超时时间和下一次文件的打开时间限制的，下一次文件打开时才会对这个文件的所有块信息的缓存进行清理。此外，由于大多数文件都是只能追加的，一个过期的副本经常会返回一个因过早结束而缺失数据的块，而不是过期的数据。当一个读客户端再次向主节点查询时，它将会立即获得块的当前位置信息。
【The Google File System 翻译和理解】在一个修改操作成功执行完一段时间后，组件的失效依然能损坏或删除数据。