追求分布式而导致产生的难点

• 追求性能—>分片
• 出现故障—>容错
• 容错—>复制副本
• 复制—>一致性
• 一致性—>低性能

GFS的目标

• 大型，快速
• 全局可用
• 分片
• 自动故障修复
  

  （其他目标）

• 单一数据中心
• 仅供内部使用
• 对大型数据连续访问

GFS

master知道每个文件对应的所有文件，维护一个chunks列表，块标识符包含该文件的连续片段，每个都是64MB。

其中master有两张表：（nv非易失性存储，v易失性存储）
①文件名——>chunk id数组，指向chunk handel(nv)
②chunk handel——>chunk数据（包括chunk服务器列表(v)、chunk版本号(nv)、主chunk(v)、过期时间(v)）

读数据的过程

①客户端向master发送文件名和偏移量（通常是偏移量除以64MB得到chunk，文件名代表首地址）
②master发生chunk handle，以及服务器列表（客户端会对获取过的数据缓存）
③客户端与chunk服务器通讯，发送偏移量

写数据的过程（记录追加）

客户端向master发送请求，想对某个文件追加，master就会发送最后一个chunk的位置（告诉主chunk和随从chunk的位置）。
客户端无需知道文件多长，只要了解偏移量和哪个chunk处追加即可。
然后客户端把数据发给主chunk和随从chunk，数据会先保存到chunk服务本地（并不立即追加到文件）当都保存好了之后，主chunk会告诉随从把输入写入chunk中相同偏移量处。都写入成功后返回确认给主chunk，然后主chunk告诉客户端写入成功。

如上图，第一次B记录写入失败，只写入了两个chunk，然后主chunk接受C数据写入的请求，而且成功，如果B数据再次请求写入，成功后就会出现图中的情况。而如果其他客户端读数据，读第一个chunk就会出现ABCB，读第三个chunk就会出现A空白CB。

问题

• 没有主chunk的情况
  master找到最新数据副本，然后把chunk副本最近的版本号更新到master所知道的最新版本号的数据。主chunk会把写入操作给其他chunk服务器，写入后，master更新本地的版本号。（如果最新版本号的chunk挂了，数据就一直获取不到，master会告诉客户端数据不可用，旧版本的chunk永远不会调用）

脑裂(split-brain)问题

由于网络分区或者什么其他原因，master无法跟主chunk联系，但是主chunk可以和随从联系的情况下，master再重新指定了一个主chunk，导致接受的数据出现问题。

租约

master给每个主chunk分配60秒过期时间，为了保证主chunk挂了，再苏醒后出现两个主chunk的情况。
如果master无法联系到主chunk，master会等一个过期时间，重新建立主chunk后，再响应客户端对这个chunk的操作请求。

二阶段提交

主chunk询问所有随从是否能写入数据（是否已经都复制成功），随从全部回复yes后，主chunk再一声令下，让所有随从和自己都写入数据。