Google File System读后感

Google File System读后感

Google File System 简称GFS，是谷歌设计并实现了的文件系统。为大量客户提供了高性能的服务。

GFS最开始的设计思路是：
1.组件失效被认为是常态事件，而不是意外事件；
2.以通常的标准衡量，我们的文件非常巨大；
3.绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式；
4.应用程序和文件系统 API 的协同设计提高了整个系统的灵活性。

由此，Google在设计中做出了如下的假设：

1.系统由许多廉价的普通组件组成，组件失效是一种常态。系统必须持续监控自身的状态，它必须将组件
失效作为一种常态，能够迅速地侦测、冗余并恢复失效的组件。
2.系统存储一定数量的大文件。我们预期会有几百万文件，文件的大小通常在 100MB 或者以上。系统也必须支持小文件，但是不需要针对小文件做专门的优化。
3.负载通常包含两种读：大型的流式读（顺序读），和小型的随机读。前者通常一次读数百KB以上，后者通常在随机位置读几个KB。
4.系统的工作负载还包括许多大规模的、顺序的、数据追加方式的写操作，系统支持小规模的随机位置写入操作，
但是可能效率不彰。
5.系统必须高效的、行为定义明确的实现多客户端并行追加数据到同一个文件里的语意。
6.高性能的稳定网络带宽远比低延迟重要。

GFS系统的节点可以分为三种角色
1.GFS Master（主控服务器）
2.GFS ChunkServer（CS，数据块服务器）
3.GFS客户端

这是GFS整体架构

由这张图我们基本可以了解到：GFS主控服务器是整个文件系统架构的核心，他保证了chunk与文件之间的映射和文件的命名空间等等。GFS存储的文件被分成了固定大小的chunk，由GFS Master也就是主控服务器分配一个全球唯一的chunk句柄，并储存三份。客户端是GFS提供给应用程序的访问接口，它是一组专用接口，以库文件的形式提供。客户端访问GFS时，首先访问主控服务器节点，获取与之进行交互的ChunkServer信息，然后直接访问ChunkServer，完成数据的存取工作。

GFS追加流程

1.客户端向主控服务器请求chunk每个副本所在的ChunkServer。
2.主控服务器返回客户端主副本和各副本所在的ChunkServer的位置信息，客户端将缓存这些信息供以后使用
3.客户端将要追加的记录发送到每一个副本。GFS中采用数据流和控制流分离的方法，从而能够基于网络拓扑结构很好地调度数据流的传输。
4.当所有副本都确认收到了数据，客户端发起一个写请求控制命令给主副本
5.主副本把写请求提交给所有的备副本
6.各备副本成功完成后应答主副本
7.主副本应答客户端，如果有副本发生错误，将出现主副本写成功但某些备副本不成功的情况，客户端将重试

Google文件系统构建在廉价服务器之上。它将服务器故障视为正常现象，通过软件的方式自动容错，在保证系统可靠性和可用性的同时，大大降低系统的成本。GFS 成功的实现了我们对存储的需求，无论是作为研究和开发的存储平台，还是作为生产系统的数据处理平台，都得到了广泛的应用。

参考文献：
1.Google File System
2.五分钟了解什么是Google文件系统