GFS-The Google File System初学总结

写在最前：笔者初学gfs有什么理解不当的地方，欢迎在评论区指出，不胜感激。

一.GFS简介

gfs全称Google File System，Google文件系统。是谷歌自主研发的可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。它可以给大量的用户提供总体性能较高的服务。

二.组织架构

架构

既然gfs是分布式文件系统，必然有分工合作的划分：

GFS包括

• 一个master结点（元数据服务器，管理所有chunkserver的节点，只管理，不存放数据）
• 多个chunkserver（数据服务器，真正存放数据的节点）
• 多个client（运行各种应用的客户端，可以发出写入/读出某个文件的请求）。

简要画图可以理解为：

注意的点：

• 在可靠性要求不高的场景，client和chunkserver可以位于一个结点。
• 一般一个逻辑的Master节点包括两台物理主机，即两台Master服务器（以防有一个master主机down掉了，导致整个系统瘫痪）
• 每一结点都可以是普通的Linux服务器，GFS的工作就是协调成百上千的服务器为各种应用提供服务

gfs的数据存储方式

那么，gfs的数据存储方式究竟是怎样的呢？

GFS存储的文件都被分割成固定大小的Chunk(64MB)。
在Chunk创建的时候，Master服务器会给每个Chunk分配一个不变的、全球唯一的 64位的Chunk标识。Chunkserver把Chunk以linux文件的形式保存在本地硬盘上，并且根据指定的Chunk标识和字节范围来读写块数据。

首先我们先了解一个定义：元数据
命名空间(文件和chunk的名称)、文件和Chunk的映射关系(一个文件包含哪些Chunk)、每个Chunk副本的位置信息。这三类信息都被统称为元数据。

master会持久化存储一部分元数据（存在内存中）。而文件被分割成为多个chunk之后，则被分配存储到相应的chunkserver中，写入chunkserver的磁盘。

而为了保证数据的可读性，在没有特殊指定（缺省）的情况下，我们把每个文件的chunk创建两个副本，加上原来有的，一共写入三次，只要没有三个写入都丢失，那么我们就能找到这个文件的数据。

我稍微丰富了一下架构图：

黄底的为持久化存储的数据，橙底的是只保存在内存的数据(没有回退之类的保障)。

刚刚我们说到master只会保存一部分元数据：

master保存每个Chunk副本的位置，和其他两种元数据不同的是： Master服务器不会持久保存Chunk位置信息。Master服务器在启动时，或者有新的Chunk服务器加入时，向各个Chunk服务器轮询它们所存储的Chunk的信息。后续也会定期轮询各个chunkserver获取信息。

而前两种类型的元数据（命名空间、文件和Chunk的对应关系）会被持久化存储：以记录变更日志的方式记录在操作系统的系统日志文件中，日志文件存储在本地磁盘上，同时日志会被复制到其它的远程Master服务器上。
采用保存变更日志的方式，我们能够简单可靠的更新Master服务器 的状态，并且不用担心Master服务器崩溃导致数据不一致的风险。如果mstaer服务器产生错误，我们能通过重复日志文件操作的方式来恢复master服务器。

chunk副本位置不持久化的原因和好处:

1. 因为chunkserver可能加入或者离开集群,改变路径名,崩溃,重启等.一个集群中有几百个server,这些情