Google文件系统
Google文件系统（英语：Google File System，缩写为GFS或GoogleFS），一种专有分布式文件系统，由Google公司开发，运行于Linux平台上。
尽管Google在2003年公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。
2013年，Google公布了Colossus项目，作为下一代的Google文件系统。
设计
GFS专门为Google的核心数据即页面搜索的存储进行了优化。数据使用大到若干G字节的大文件持续存储，而这些文件极少被删除、覆盖或者减小；通常只是进行添加或读取操作。它也是针对Google的计算机集群进行的设计和优化，这些节点是由廉价的“常用”计算机组成，这就意味着必须防止单个节点的高损害率和随之带来的数据丢失。其它设计理念包括高数据吞吐率，甚至这带来了访问反应期变差。
节点分为两类：主节点和Chunkservers。Chunkservers存储数据文件，这些单个的文件象常见的文件系统中的簇或者扇区那样被分成固定大小的数据块（这也是名字的由来）。每个数据块有一个唯一的64位标签，维护从文件到组成的数据块的逻辑映射。每个数据块在网络上复制一个固定数量的次数，缺省次数是3次，对于常用文件如可执行文件的次数要更多。
主服务器通常并不存储实际的大块数据，而是存储与大块数据相关的元数据，这样的数据如映射表格将64位标签映射到大块数据位置及其组成的文件、大块数据副本位置、哪个进程正在读写特定的大数据块或者追踪复制大块数据的“快照”（通常在主服务器的激发下，当由于节点失败的时候，一个大数据块的副本数目降到了设定的数目下）。所有这些元数据通过主服务器周期性地接收从每个数据块服务器来的更新（“心跳消息”）保持最新状态。
操作的允许授权是通过限时的、倒计时“租期”系统来处理的，主服务器授权一个进程在有限的时间段内访问数据块，在这段时间内主服务器不会授权其它任何进程访问数据块。被更改的chunkserver——总是主要的数据块存储器，然后将更改复制到其它的chunkserver上。这些变化直到所有的chunkserver确认才存储起来，这样就保证了操作的完整性和原子性。
访问大数据块的程序首先查询主服务器得到所要数据块的位置，如果大数据块没有进行操作（没有重要的租约），主服务器回答大数据块的位置，然后程序就可以直接与chunkserver进行联系接收数据（类似于Kazaa和它的超级节点）。
意见
只能有一个主服务器——代码不允许存在多个主服务器。
这看起来是限制系统可扩展性和可靠性的一个缺陷，因为系统的最大存储容量和正常工作时间受制于主服务器的容量和正常工作时间，也因为它要将所有的元数据进行编制，并且因为几乎所有的动作和请求都经过它；但是Google的工程师们辩解说事实并不是这样。
元数据是非常紧凑的，仅仅只有数K到数M的大小，并且主服务器通常是网络上性能最好的节点之一；至于可靠性，通常有一个“影子”主服务器制作主服务器的镜像，一旦主服务器失败它将接替工作。
另外，主服务器极少成为瓶颈，因为客户端仅仅获取元数据然后将它们缓存起来；随后的交互工作是直接与chunkservers进行。
同样，使用单个的主服务器可以大幅度地降低软件的复杂性，如果有多个的主服务器，软件将变得复杂以能够保证数据完整性、自动操作、负载均衡和安全性。
GFS 的总结
GFS的架构，体现了很多经典的设计实践：
简化系统角色，单点master降低系统复杂度
不管是文件还是服务，均通过“冗余+故障自动转移”保证高可用
由于存在单点master，GFS将“降低与单点master的交互”作为性能优化核心
通过写日志，原子修改，checksum，快速监控快速恢复等方式保证可靠性与完整性
通过串行化保证多个副本数据的一致性
控制流与数据流分离，提高性能
拓展阅读
参考资料
| [GFS架构启示 | Google File System](https://mp.weixin.qq.com/s/eQ6BwLU9Twi_O9_99Ltviw) |
