1.GFS的架构
先来对这张图，也就是读取流程做一下解释。
<1>client在把应用程序要读写的文件根据文件名和偏移量，根据chunk的大小转换成文件的chunk index；
<2>client将filename和chunk index发送给master，master通过查找，返回相应的chunk handle（chunk标识/chunk句柄）和位置；
<3>client使用filename和chunk handle最为key，缓存这些数据；
<4>client向相应的chunkserver发起请求，发送的信息是chunk handle和byte range（字节范围）；
<5>client对该chunk的后续读取操作中，client不会与master交互，除非client本身的cache信息过期了，或者这个文件重新打开了。
（1）GFS的组成
GFS由一个master（元数据服务器），多个chunkserver（块服务器），多个client（客户端）组成。
（2）master
<1>master负责管理所有文件系统的元数据（包括namespace，访问控制信息，文件到chunk的映射，当前chunk的位置信息等），同时掌握整个系统内的chunkserver情况。
<2>master控制系统级别的活动。包括有：chunk的分配和管理、孤点chunk的垃圾回收机制、chunk在chunkserver之间的移动。
<3>master和chunkserver之间通过心跳包传递信息和状态。
思考：为什么设计单个master?
<1>单个master简化了设计，master可以基于全局角度管理chunk的存放；
<2>单个master保证了数据的一致性。
单个master的缺点：
单个master，很容易造成读写是系统的瓶颈，因此，必须尽量减少master的读写操作，避免它成为瓶颈。client不会通过master做数据的读写，client和master交互，只是得到chunk index和chunk的存储位置，并在client缓存这些信息，在后续操作中都使用这些信息。只有client缓存的信息过期了或者这个文件重新打开了，client才会和master重新交互以获取新的信息。GFS对master进行远程备份，当master宕机时，通过operator log，简单可靠的恢复master的状态。
master的特点：
master在启动时和chunkserver加入集群时，向每一个chunkserver询问他的chunk信息，master非持久化保存chunk的位置信息。
原因有二：
(1)减少master和chunkserver的同步；
(2)chunk的位置信息只有chunkserver有义务知道，master可以定期访问chunkserver获取最新的位置信息。
（3）chunkserver
GFS下，每一个文件都拆成固定大小的chunk(块)。每一个块都由master根据块创建的时间产生一个全局唯一的以后不会改变的64位的chunkhandle标志。chunkserver在本地磁盘用Linux文件系统保存块，并根据chunk handle和byte range，通过Liunx文件系统读写这些块的数据。出于可靠性考虑，每一个块都会在不同的chunkserver上保存，默认备份3份。
思考：为什么每块的大小是64M？
<1>减少client和master的通讯的需求；
<2>降低了master需要保存的元数据的数量，允许将元数据的保存在内存中；
<3>64M是一个经验值，大文件切割成64M能保证最大额传输效率。
GFS下，如果是小型文件，切块后可能只有一个或者两个chunk块，保存这些块的chunkserver在大量客户端访问时就会成为焦点，可以通过增加备份数量来解决这个问题。但是这个问题不用担心，因为GFS是处理超大文件的。
