GFS（Google File System）的设计目的是使得大规模的普通廉价机能够完成对大量数据的处理操作。
设计预期：
1.由于使用的是普通廉价设备，组件失效成为常态事件。
2.由于处理的文件规模巨大，系统将适当存储大文件。
3.读：1）大规模流式读取。
2）小规模随机读取。
4.写：采用大规模的、顺序的、数据追加方式（append）。
5.定义能够实现并行追加操作的明确语义。
6.高带宽比低延迟重要。实现大批量数据的快速处理。
架构：
master节点：两台master服务器（储存元数据），管理所有文件系统元数据及系统级别上的活动。
chunkserver：管理和储存的linux文件形式的chunk（源文件被分割成多个固定大小的chunk），为保证可靠性，使用三个副本。
应用链接client，代码实现：GFS的API接口，应用程序与master、chunkserver通信，数据的读写操作。
单一master节点：
master节点起到简化全局定位的作用，对文件数据的具体操作交互发生在client和chunkserver之间：
1.client根据文件名和字节偏移根据chunk大小计算chunk索引，把文件名和chunk索引发给master。
2.master根据收到的文件名和chunk索引，在元数据中查找对应chunk handle和chunk副本位置，并答复给client。
3.client就近选择一个chunk副本，发送含有chunk handle和字节范围的请求信息。
4.chunkserver向client返回chunk数据。
Chunk的大小的确定：64MB
64MB远大于一般文件系统的Block size
优点：
1.减少client和master节点的通信，一次获取，多次读写。
2.与chunkserver保持长时链接减少网络负载。
3.减少master节点元数据量。
缺点：
小文件chunk数量很少，chunkserver或成为访问热点导致系统局部过载。
（解决方案？允许客户端从其他客户端获取数据）
元数据：
master服务器在内存中储存三种类型的元数据：
1.文件和chunk的命名空间
2.文件盒chunk的对应关系
3.每个chunk副本的存放地址
前两种元数据会以操作日志的形式在操作系统的日志文件（本地磁盘）和远程master服务器中备份。
操作日志：
元数据唯一的持久化储存记录，是master服务器在灾难恢复时的依据。
在日志文件积累到一定量时，做一次checkpoint，生成的checkpoint文件及后续日志将作为下次master恢复时的直接依据。
chunk位置信息则不会被长时保存。
master服务器获取最新chunk信息的方式：
1.master服务器启动时，master服务器会向chunk服务器轮询chunk信息。
2.master服务器通过周期性心跳信息监控chunk服务器状态，定期轮询。
一致模型：
一致性即master，chunkserver，chunk副本，客户端各处数据一致。主要解决修改文件可能引起的不一致问题。
（背景：
GFS设计中强调减少master的工作量
修改命名空间为原子操作
文件修改操作：
1.改写Overwrite（指定位置）
2.追加Append（文件尾部）,这也是受推崇的修改方式，过期数据优于错误数据）
租约（lease）机制：
为减少master的负担，（在前面曾经提到master在联系了client和chunkserver之后就歇了，由client和chunkserver直接通信，也是出于此考虑）同时又要对写入操作进行管理，这里master选取了主chunk作为代理来管理对chunk的修改（建立操作序列），用lease来设定主chunk的工作时间。
理一遍：
1.client询问master主chunk及其副本信息。
2.master返回主chunk及其副本信息。
3.client向所有副本推送文件数据。
4.client确认副本收到，向主chunk发送写请求。主chunk建立操作序列。
5.主chunk将操作序列发送给二级副本，二级副本按序列执行操作。
6.二级副本回复主chunk报告操作完毕。
7.主chunk回复client副本操作情况。
写操作数量过大时，会被分解，可能会跟其他client的操作打乱，但所有副本的执行序列都是一样的，所以可以保证副本的一致性。
谨慎的，放图：
总结了顺序或并发，写入或追加的各种操作所能组合的情况，用以严格区分文件的一致性水平。
然而。。。这一条路毕竟漫长，我们边走边谈