这是我参与「第四届青训营 」笔记创作活动的第6天，就大项目的相关内容进行了一些资料查阅和分析。
简易分布式存储系统实现
基本框架
我们小组讨论并查阅了一些资料最终准备以GFS作为核心框架来进行项目的实现。
GFS一共包括了三个部分：
- master
- client
- datanode
其中master负责控制元数据，以及元数据的管理，client作为客户端直接和用户进行交互，而datanode则负责存储文件数据，GFS的存储方式为将文件分成若干个chunk来实现。以下是对于GFS论文的分析引用。
Chunk的大小是关键的设计参数之一。我们选择了64MB，这个尺寸远远大于一般文件系统的Block size。每个Chunk的副本都以普通Linux文件的形式保存在Chunk服务器上，只有在需要的时候才扩大。 惰性空间分配策略避免了因内部碎片造成的空间浪费，内部碎片或许是对选择这么大的Chunk尺寸最具争议一点。
单一的Master节点的策略大大简化了我们的设计。单一的Master节点可以通过全局的信息精确定位 Chunk的位置以及进行复制决策。另外，我们必须减少对Master节点的读写，避免Master节点成为系统的瓶颈。客户端并不通过Master节点读写文件数据。
高可用性
目前我们讨论的框架还未能实现高可用性，不过参考GFS可以从master服务器的复制触发实现该功能。以下是对于GFS论文的分析引用。
为了保证Master服务器的可靠性，Master服务器的状态也要复制。Master服务器所有的操作日志和 checkpoint文件都被复制到多台机器上。对Master服务器状态的修改操作能够提交成功的前提是，操作日志写入到Master服务器的备节点和本机的磁盘。简单说来，一个Master服务进程负责所有的修改操作，包括后台的服务，比如垃圾回收等改变系统内部状态活动。当它失效的时，几乎可以立刻重新启动。 如果Master进程所在的机器或者磁盘失效了，处于GFS系统外部的监控进程会在其它的存有完整操作日志的机器上启动一个新的Master进程。客户端使用规范的名字访问Master(比如gfs-test)节点，这个名字 类似DNS别名，因此也就可以在Master进程转到别的机器上执行时，通过更改别名的实际指向访问新的 Master节点。
