Google文件系统（三）

译自The Google File System

做者：Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung

2.7 一致性模型

GFS支持弱一致性模型。这种模型可以很好地支撑高度分布式应用，同时实现相对简单容易。本节讨论GFS的一致性保障机制及其对应用程序的意义。

2.7.1 GFS一致性保障机制

文件命名空间的修改（如文件建立）是原子性的，仅由Master节点控制：命名空间锁保证了原子性和正确性；Master节点的操做日志定义了操做的全局顺序。

数据修改后，文件区域的状态取决于操做的类型、成功与否、以及是否存在同步修改。 表1列出了各类操做的结果。若是全部客户端不管从各个副本读取的数据都是同样的，则视其文件区域为一致。若是修改文件数据后，文件区域是一致的，且客户端可以看到所有写入操做的内容，则该区域为“已定义”区域。若是一个数据修改操做成功执行且没有受到同时执行的其它写入操做的干扰，则影响的区域就是已定义区域（隐含了一致性）：全部的客户端均可以看到写入的内容。并行修改操做成功完成以后，区域处于未定义的一致状态：全部的客户端能够看到一样的数据，但没法读取任何一次写入操做写入的数据。一般状况下，文件区域内包含了来自多个修改操做的数据片断。修改操做失败会致使区域处于不一致状态（同时也是未定义状态）：不一样的客户在不一样的时间会看到不一样的数据。后文将介绍应用如何区分已定义区域和未定义区域。应用程序不须要进一步细分未定义区域的类型。

数据修改操做分为写入和追加两种。写入操做把数据写在应用程序指定的文件位置上。即使存在多个并行修改操做，记录追加操做能够至少把数据原子性地追加到文件中一次，可是追加位置取决于GFS。GFS给客户端返回一个位置信息，标记了包含写入记录的已定义区域的起点。另外，GFS可能会在文件中间插入填充数据或者重复记录。通常认为，这些数据占据的文件区域是不一致的，且这类数据一般比用户数据小不少。

完成一系列成功修改操做以后，GFS确保被修改的文件区域是已定义的，且包含最后一次修改操做写入的数据。GFS 经过如下措施确保上述行为：（a）按照一样的顺序对数据块的全部副本进行修改操做，（b）经过数据块版本号检测副本是否因其所在的数据块服务器宕机错过了修改操做，最终致使其失效。失效的副本不会再进行任何修改操做，Master服务器也再也不将该数据块副本的位置信息返回给客户端。这些副本一经发现，便会被垃圾收集系统回收。

因为数据块的位置信息会被客户端缓存，因此在信息刷新前，客户端有可能从失效的副本读取数据。在缓存的超时时间和文件下一次被打开的时间之间存在时间窗，文件再次被打开后会清除缓存中与该文件有关的全部数据块的位置信息。并且，因为咱们的大多数文件只进行追加操做，所以失效的副本一般返回提早结束的数据块而不是过时的数据。当读取程序尝试从新联系Master服务器时，便会马上获得数据块最新的位置信息。

即便在修改操做成功执行很长时间以后，组件的失效也可能损坏或删除数据。GFS经过Master服务器和全部数据块服务器的按期通讯定位失效的数据块服务器，并使用校验和来校验数据是否损坏。一旦发现问题，要尽快利用有效副本恢复数据。若是在GFS检测到并采起措施以前（通常只须要几分钟），数据块的全部副本已经所有丢失，该数据块便彻底没法恢复了。不过在这种状况下，数据块也只是不可用了，而不是损坏了：应用程序会收到明确的错误信息而非损坏的数据。

2.7.2 应用程序的实现

结合一些简单的技术，GFS应用程序的弱一致性模型还能实现其它功能，包括：尽可能采用追加写入而不是覆盖，Checkpoint，自验证写入，自标识记录。

在实际应用中，咱们全部的应用程序都尽可能采用追加而非覆盖的方式对文件进行写入操做。一般状况下，应用程序从头至尾写入数据，生成了一个文件。写入全部数据以后，应用程序自动将文件更名为永久保存的文件名；或者周期性地进行Checkpoint，记录成功写入的数据数量。Checkpoint文件可能包含程序级别的校验和。读取程序仅校验并处理上个Checkpoint以后产生的文件区域，这些文件区域为已定义状态。这个方法知足了咱们除一致性和并发处理以外的需求。追加写入比随机写入效率更高，且可以更快地从应用程序失效中恢复。Checkpoint可以让写入程序不断从新开始，而且能够防止读取程序处理已经被成功写入但从应用程序的角度来看还没有写入完成的数据。

另一种典型的应用场景是多个应用程序同时向同一个文件追加数据进行结果合并或以生产者-消费者队列的形式进行数据追加。记录追加方式中，“至少一次追加”的特性保证了写入程序的输出。读取程序经过下面的方式处理偶然填充和重复内容。写入程序的每条记录都包含了额外信息，例如用于验证有效性的验证和。读取程序能够利用验证和识别并抛弃额外的填充数据和记录片断。若是应用不能容忍偶然的重复内容（如重复数据触发了非幂等操做），能够用记录的惟一标识符进行过滤。惟一标识符一般用于命名程序处理的实体对象，如web文档。这些记录I/O功能都在程序共享代码库中，而且适用于Google内部其它文件接口的实现。这样，相同记录序列和偶然出现的重复数据都被分发到读取程序了。

3 系统交互

设计系统时，咱们尽可能减小全部操做与Master节点的交互。所以，本节主要介绍客户端、Master服务器以及数据块服务器如何经过交互实现数据修改、原子性记录追加操做和快照功能的。

3.1 租约与修改操做的顺序

修改操做会改变数据块的内容或元数据，包括写入操做或记录追加操做等。修改操做会在数据块的全部副本上执行。咱们经过租约（lease）机制保证多个副本间修改操做顺序的一致性。Master节点为数据块的一个副本创建一份租约，咱们称该数据块为主数据块。主数据块对数据块的全部修改操做进行排序。全部副本均遵循这一顺序进行修改操做。所以，修改操做的全局顺序首先由Master节点选择的租约的顺序决定，而后由租约中主数据块分配的序列号决定。

设计租约机制的目的是为了尽可能减小Master节点的管理负担。租约的初始时效为60秒。不过，只要数据块被修改了，主数据块就能够申请延长租期。申请一般会获得Master节点的确认并收到延长时间。租约延长请求和批信息一般都是附加在Master节点与数据库服务器之间的心跳消息中。有时Master节点会试图提早取消租约（例如，Master节点想撤销对一个已被更名文件的修改操做）。即便与主数据块失去联系，Master节点仍然能够安全地在原有租约到期后与另一个数据块副本签定新的租约。

图2为写入操做的控制流程。

• 客户机向Master节点询问持有当前租约的数据块服务器以及其它副本的位置。若是尚不存在租约，则Master节点会选择其中一个副本创建租约。
• Master节点将主数据块的标识符以及其它副本的位置信息返回给客户机。户机缓存这些数据以便后续的操做。只有在主数据块不可用或主数据块回复信息告知已再也不持有租约时，客户机才须要与Master节点从新联系。
• 客户机能够按照任意顺序把数据推送到全部副本上。数据块服务器接收到数据并保存在其内部LRU缓存中，直到数据被使用或过时。因为数据流的网络传输负载很是高，经过分离数据流和控制流，能够基于网络拓扑状况对数据流进行规划，提升系统性能，不须要关注主数据块保存在哪一个数据块服务器上。
• 全部副本都确认收到数据后，客户机会向主数据块服务器发送写入请求。请求标识了此前推送到全部副本的数据。主数据块为接收到的全部操做分配连续的序列号，这些操做可能来自不一样的客户机，序列号保证操做会按顺序执行，并将操做应用到本地状态。 主数据块将写入请求传递到全部二级副本。每一个二级副本依照主数据块分配的序列号执行操做。
• 二级副本完成操做后便会回复主数据块。
• 主数据块服务器回复客户机。任何副本产生的任何错误都会返回给客户机。出现错误时，写入操做有可能在主数据块和部分二级副本上执行成功。（若是操做在主数据块上失败了，操做就不会被分配序列号，也不会被传递。）客户端的请求被确认为失败后，被修改的区域便会处于不一致状态。客户机代码会重复执行失败的操做。重复执行操做前，客户机会先尝试重复步骤（3）到步骤（7）。

若是应用程序一次写入的数据量很大或数据跨越了多个数据块，GFS客户机代码会把数据分红多个写入操做。这些操做都遵循前述控制流程，但可能会被其余客户机上同时进行的操做打断或覆盖。

所以，共享文件区域的尾部可能包含来自不一样客户机的数据片断，但因为这些分解后的写入操做在全部副本上都按照相同的顺序执行完成，所以数据块的全部副本都是一致的。这使文件区域处于一致但未定义的状态。

参考资料

1. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google File System
2. Yan Wei. The Google File System中文版

官方网站

开源地址

UAVStack已在Github上开放源码，并提供了安装部署、架构说明和用户指南等双语文档，欢迎访问-给星-拉取~~~

扫一扫下方二维码，关注一个不会让你失望的公众号