GFS
GFS包含两个组件，Master和Chunk Server。 Master负责管理元数据信息，DataServer负责数据文件的存储。
元数据服务器：Master
HDFS采用中心节点Master存储系统的元数据信息。Master维护了文件及chunk命名空间、文件到chunk之间的映射、chunk副本的位置信息。其中chunk副本的位置信息不需要持久化，可以通过ChunkServer汇报获取。
元数据大小
为了减小元数据信息，GFS限制每个文件大小最小为64MB。同时限制每个文件的元数据大小仅为64字节，仅用于存储块对应的ChunkServerID。文件Chunk块的元数据如文件大小、磁盘位移都交由Chunk Server管理。最大限度减小元数据大小。
那么我们可以得到1PB数据的Chunk元信息不超过:
1PB / 64MB * 64 = 1GB
这样保证了内存不会成为GFS的瓶颈
数据的读写流程
数据读取
- 客户端向Master请求文件对应的数据服务器位置
- Master返回文件对应的ChunkServer版本号以及ChunkServer地址
- 客户端向ChunkServer发送文件读取请求。
- ChunkServer返回结果。
如果每次请求都需经由Master节点，那么Master的压力极大，单个Master很难处理海量并发请求。
GFS采用客户端缓存机制，在请求某个文件后，将记录该文件对应ChunkServer地址，下次再请求时，无需经过Master。
但有一种可能，在下次请求之前该文件的位置由于迁移等原因发生了变化，为了避免客户端读取到错误信息，Master节点同时反悔了版本号。每次请求时客户端会带着ChunkServer的版本信息，如果ChunkServer发生了迁移，版本号将发生变化，此时ChunkServer将拒绝该请求。
客户端此时将重新请求Master节点，获取新的文件地址信息。
数据写入
写入时，客户端首先仍将请求Master节点，接着向三台服务器发送写数据请求。写数据分为两部：
- 服务器将文件数据缓存在内存中。
- 将缓存在内存中的数据写入磁盘。
以上两个步骤，客户端需要确保三台服务器同时完成，如果之间发生错误，此次操作都将失败。
##容错
文件错误
对于每个文件Chunk将其切分成多个block，每个block64KB。在写入数据时，以block为单位计算checksum存储在block数据段之前。
检查错误包含两种方法：
- 在读取数据时，检查读取的文件内容和checksum是否符合。
如果不符合，说明文件内容出错，或者checksum出错。不管哪种错误都说明block存在问题。 - 后端线程定时扫描
当数据服务器发现文件出现错误时，会通知元数据服务器，请求从其它节点恢复文件。元数据服务器收到请求后，将告知它其它节点的地址。数据服务器拿到该地址后，将像其它数据节点发送数据请求。
数据服务器出错
当数据服务器出错时，该服务器上的所有文件都将不可用。为了确保不因为单机故障而导致而导致部分文件不可读，采用写多份的办法，将文件存储在多个区域。对于每个文件HDFS默认写3份，并且推荐其中两台主机在一个机房，第三台机器在另外机房从而确保容灾。
元数据服务器定时与数据服务器发送心跳，维护数据服务器的可用状态。当该数据服务器超过指定时间仍然未恢复时，将开启恢复流程。读取该服务器上所有的数据文件的元数据信息，将数据文件重新分配到其它节点。
元数据服务器出错
Master采用主从双节点，主节点在收到元数据变更请求后会将操作日志复制到从节点。并由分布式协调系统Chubby监听主节点状态，自动实现现主从切换。
其它
数据热点
每次对文件进行数据操作时，数据服务器会记录文件的操作频率，并在与Master发送心跳时汇报该信息。
Master汇总所有数据服务器的访问信息以及服务器的负载信息。当发现某个节点或者文件访问过热时，会开启迁移流程。将某些文件从一个服务器迁移到其它服务器，避免服务器过载。
延迟删除
用户删除文件后，GFS并立即删除该文件，而是在元数据中将文件改名为一个隐藏的名字，并且包含一个删除的时间戳。
Master定时检查，如果发现文件删除超过一段时间，那么可把文件从内存元数据中删除，以后ChunkServer和Master的心跳信息中，每一个ChunkServer都将报告子集的chunk集合，Master会告知chunk已经不存在，Chunk会释放这些副本。垃圾回收一般在负载较低时执行，比如凌晨1点。
#讨论
- 单Master的设计是可行的，不仅简化了系统，而且能够好地实现一致性。
- 基于性能考虑，提出了追加一致性，而不允许修改，通过租约减少Master的负载，通过流水线复制多个副本减少延迟。通过写时复制BTREE，保存元数据。