4.1.5　讨论

从GFS的架构设计可以看出，GFS是一个具有良好可扩展性并能够在软件层面自动处理各种异常情况的系统。Google是一家很重视自动化的公司，从早期的GFS，再到Bigtable、Megastore，以及最近的Spanner,Google的分布式存储系统在这一点上一脉相承。由于Google的系统一开始能很好地解决可扩展性问题，所以后续的系统能够构建在前一个系统之上并且一步一步引入新的功能，如Bigtable在GFS之上将海量数据组织成表格形式，Megastore、Spanner又进一步在Bigtable之上融合一些关系型数据库的功能，整个解决方案完美华丽。

自动化对系统的容错能力提出了很高的要求，在设计GFS时认为节点失效是常态，通过在软件层面进行故障检测，并且通过chunk复制操作将原有故障节点的服务迁移到新的节点。系统还会根据一定的策略，如磁盘使用情况、机器负载等执行负载均衡操作。Google在软件层面的努力获得了巨大的回报，由于软件层面能够做到自动化容错，底层的硬件可以采用廉价的错误率较高的硬件，比如廉价的SATA盘，这大大降低了云服务的成本，在和其他厂商的竞争中表现出价格优势。比较典型的例子就是Google的邮箱服务，由于基础设施成本低，Gmail服务能够免费给用户提供更大的容量，令其他厂商望尘莫及。

Google的成功经验也表明了一点：单Master的设计是可行的。单Master的设计不仅简化了系统，而且能够较好地实现一致性，后面我们将要看到的绝大多数分布式存储系统都和GFS一样依赖单总控节点。然而，单Master的设计并不意味着实现GFS只是一些比较简单琐碎的工作。基于性能考虑，GFS提出了“记录至少原子性追加一次”的一致性模型，通过租约的方式将每个chunk的修改授权下放到ChunkServer从而减少Master的负载，通过流水线的方式复制多个副本以减少延时，追加流程复杂繁琐。另外，Master维护的元数据有很多，需要设计高效的数据结构，占用内存小，并且能够支持快照操作。支持写时复制的B树能够满足Master的元数据管理需求，然而，它的实现是相当复杂的。