阅读GFS的一点总结

        这是我第一次阅读学术论文，文章中充斥的一些学术名词给个人阅读带来了一些困难，由于此前没有接触过这方面的内容，在同窗的帮助下，查阅了一些资料，终于对GFS有了一点认识，写出这一些感悟，文章措辞不严谨之处，但愿谅解。

        提到分布式系统，就算是外行人的我都知道Google的三驾马车，GFS正是之一。GFS是一个大型的分布式文件系统，它为Google 的云计算提供海量的存储，成为全部核心技术的底层。GFS将整个系统的节点分为三类：Client（客户端）、Master（主服务器）和Chunk Server（数据块服务器）。Client是GFS提供给应用程序的访问接口，它是一组专用接口，以库文件的形式提供。应用程序直接调用这些库函数，并与该库连接在一块儿。Master是GFS的管理节点，在逻辑上只有一个，它保存系统的元数据，负责整个文件系统的管理，是GFS文件系统中的核心。Chunk Server负责具体的存储工做。数据以文件的形式存储在Chunk Server上，Chunk Server的个数能够有多个，它的数目直接决定了GFS的规模。GFS将文件按照固定大小进行分块，默认是64MB，每一块称为一个Chunk，每一个Chunk都有一个对应的索引号，且是惟一不变的。

      与传统的分布式系统同样，GFS 一样追求高性能、高可靠性、高可用性，但同时 Google 基于自身的生产环境、技术环境，有一些自身独有的特色。首先，组件失效是常态化的，而非意外。在 GFS 成百上千的集群中，随时随地均可能发生故障致使机器没法恢复，因此，有必定的容灾、自动恢复能力是必需要整合在 GFS 中的。其次，文件巨大，GB 级别的数据很是广泛。第三，绝大多数文件的写操做都是追加，而非修改，一般的文件场景是顺序写，且顺序读。第四，应用程序和文件系统 API 的协同设计提升了整个系统的灵活性。

      一个GFS集群由一个master和大量的chunkserver构成，并被许多Client访问，只要资源和可靠性容许，chunkserver和client能够运行在同一个机器上。与每一个应用相联的GFS客户代码实现了文件系统的API并与master和chunkserver通讯以表明应用程序读和写数据 。client与master的交换只限于对metadata的操做，全部数据方面的通讯都直接和chunkserver联系 。client和chunkserver都不缓存文件数据,因为数据太多没法缓存。不缓存数据简化了客户程序和整个系统，由于没必要考虑缓存的一致性问题，但用户缓存metadata。Chunkserver 也没必要缓存文件，由于块是做为本地文件存储的。只有一个master也极大的简化了设计并使得master能够根据全局状况做出先进的块放置和复制决定。可是咱们必需要将ma ster对读和写的参与减至最少，这样它才不会成为系统的瓶颈。Client历来不会从master读和写文件数据。client只是询问master它应该和哪一个chunkserver联系。client在一段限定的时间内将这些信息缓存，在后续的操做中client直接和chunkserver交互。

      当今的时代，是大数据的时代，截止到2012年,数据量已经从TB级别跃升到PB、EB乃至ZB级别，人类生产的全部印刷材料的数据量是200PB,全人类历史上说过的全部话的数据量大约是5EB，而到了2020年,全世界所产生的数据规模将达到今天的44倍，所以，能够说没有GFS就没有今天的大数据时代。

     以上就是一只菜鸡对一篇论文的简单认识，若有错误之处，但愿大佬们帮忙指正。