GFS 论文阅读
本文最后更新于：2 年前
相关背景
单机文件系统我们见得已经很多，像 xfs，ext4 等等都已经是很出名的单机文件系统。然而，单机文件系统的容量始终是有限的，随着数据量的不断增大，就算对单机不断的 scale up 也会逐渐达到上限。因此，支持 scale out 的分布式文件系统是技术的必然。作为世界上数据量可能最多的公司，Google 在 21 世纪初就已经遇到了这个挑战，随之其开发了 GFS 这个创时代的分布式文件系统并将该成果发表在了 2003 年的 SOSP 会议上，之后随着 MapReduce 和 BigTable 论文的发表，Google 的三架马车整整齐齐，掀开了大数据时代的帷幕，引领工业界开始了辉煌的 NoSQL 运动。
之后，MapReduce 和 BigTable 或多或少都被新时代的大数据技术栈替代和压榨，只有 GFS 在大规模分布式文件系统领域鲜有敌手，只有某些针对不同场景的优化竞品而已，例如针对海量小文件做了优化的 HayStack/F4。总之，即使在 2021 年的今天，学习 GFS 的设计思想也是十分有意义的。
PS：云改变了分布式文件系统的走向，S3 等正在以成本低，可托管等特性挑战着 HDFS 的地位，例如新起之秀 JuiceFS。他们支持可横向扩展的 TiKV 作为元数据存储，在大数据量下的扩展性上相比 HDFS 有着更优雅的解决方案。
要解决的问题
实现一个高可用，可扩展，高性能，低成本，可容错的大规模分布式文件系统，同时为用户提供近可能简单的文件读写接口并屏蔽底层的复杂实现细节。
介绍
本来打算好好的写一篇博客总结一下自己时隔两年后再读 GFS 的理解，但是偶然看到了一篇写的很详细且有作者想法的 博客，因此就没必要浪费时间自己再写一遍了，感兴趣的可以去详读这篇博客。
对于博客中所述，有一处有关 chunk version 的地方我个人不太认同，原文如下：
Master 节点在接受到修改请求时，会找此 file 文件最后一个 chunk 的 up-to-date 版本（最新版本），最新版本号应当等于 Master 节点的版本号；
什么叫最新版本。chunk 使用一个 chunk version 进行版本管理（分布式环境下普遍使用版本号进行管理，比如 Lamport 逻辑时钟）。一个修改涉及 3 个 chunk 的修改，如果某一个 chunk 因为网络原因没能够修改成功，那么其 chunk version 就会落后于其他两个 chunk，此 chunk 会被认为是过时的。
Master 在选择好 primary 节点后递增当前 chunk 的 chunk version，并通过 Master 的持久化机制持久化；
通过 Primary 与其他 chunkserver，发送修改此 chunk 的版本号的通知，而节点接收到次通知后会修改版本号，然后持久化；
Primary 然后开始选择 file 最后一个文件的 chunk 的末尾 offset 开始写入数据，写入后将此消息转发给其他 chunkserver，它们也对相同的 chunk 在 offset 处写入数据；
博客作者认为 Master 维护 chunk version 的步骤是先递增当前 chunk 的 chunk version 再本地持久化，然后通知 Primary。个人认为这样不妥，因为一旦 Master 在持久化完 chunk version 和通知到 Primary 之间挂了，在 Master 重启之后，其会与所有 chunkserver 进行心跳来获取这些 chunkserver 拥有的 chunk 和其 chunk version，接着 Matser 会发现该 chunk 的所有 chunk version 都小于其从磁盘恢复的该 chunk 的 chunk version，从而认为真正持有最新 chunk version 的 chunkserver 还未恢复，进而不为该 chunk 提供服务。
因此我认为，Master 维护 chunk version 的步骤应该是先递增当前 chunk 的 chunk version 并通知 Primary，得到确切回复后再本地持久化，这样一旦 Master 在期间挂了，其恢复之后会发现 chunkserver 心跳上来的消息中，该 chunk 的 chunk version 大于本地磁盘恢复的 chunk version，从而认为 chunkserver 的 chunk version 最新并更新且持久化本地的 chunk version，进而能够提供服务，这样就与论文中的描述自恰了。
除以上一点外，其他的细节个人觉得博客都讲的很正确很 make sense 了~
总结
- 优秀的设计往往很简单
- 很难设计出一个满足所有业务场景的系统，针对不同的场景会有不同的解决方案
- 设计系统时就需要考虑到系统的瓶颈在何处（磁盘，网络，CPU）
- 单节点的性能即使不高也没太大问题，扩展性更重要