03 | The Google File System （一）： Master的三个身份
GFS 的设计决策
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
GFS（Google文件系统）是一篇经典的分布式系统论文，强调了工程上的“简单”设计原则。该系统采用单Master架构，但Master实际上具有三种不同的身份，包括目录服务、同步复制的主节点以及异步复制的主节点。GFS根据硬件特性进行设计取舍，重视顺序读写的性能，并采用流水线式的数据传输来减少数据在网络上的传输。此外，GFS放宽了数据一致性的选择，对随机写入和追加写入的一致性没有严格保障，而是将这些任务交给了客户端。在工程实践中，GFS通过一系列工程手段提高了系统的可用性和可恢复性，包括Checkpoints和操作日志、Backup Master、外部的监控程序，以及只读的影子 Master。这些工程保障措施使得GFS在故障下具有快速恢复能力和高可用性。文章还提到了GFS的客户端缓存机制以及Master重启时重新获取chunk存放在哪些chunkserver上的元数据的问题。总的来说，GFS的设计思路为后续分布式系统的设计和实现提供了宝贵的经验和启示。
《大数据经典论文解读》，新⼈⾸单¥59
全部留言(34)
- 最新
- 精选
在路上徐老师好，MIT 6.824的GFS那一讲的讲解框架是介绍分布式存储系统的矛盾、GFS的特点、内部结构和读写操作，一般介绍HDFS的书籍也是类似的流程。不过老师从简单性、考虑硬件性能、结合业务特点三个角度来谈GFS让我有了新的启发。在老师的鼓励下，今天我试着读了《The Google File System》的一部分，花了四个小时读完了INTRODUCTION和DESIGN OVERVIEW，体会到了一点论文的精辟，希望自己能坚持下去。 回到老师的问题，GFS client会缓存chunk对应的chunkserver地址，直到缓存信息过期或者文件重新打开。这种机制是否会读到过时的数据呢？论文中是这样说的，Since clients cache chunk locations, they may read from a stale replica before that information is refreshed ... as most of our files are append-only, a stale replica usually retures a premature end of chunk rather than outdated data. 也就是说，只会读不到最新的数据，不会读到过时的数据。 论文中的2.6.2 Chunk Locations讨论了chunk location的管理机制，chunkserver启动时上报chunk location information，之后再周期性上报。之所以这么设计，主要考虑两个原因。第一，消除master和chunkserver的同步问题，第二，chunkserver真正管理了chunk，对于chunk location拥有最终的话语权。作者回复: 赞👍你真的很棒！
2021-09-26339
峰1. 为了减少master的压力，所以要缓存master上的元数据信息。应该会造成读过期数据，因为写入不可变，但支持追加写，对于追加写入的chunk的元数据，怎么同步到客户端缓存按照GFS简单性的原则怕是不想做了。 2. 每个chunkserver会上报自己拥有哪些chunk。原因的话，chunkserver必然有这个信息，如果master还持久化的话，突然冒出个数据一致性的问题得考虑，数据链路上也会更复杂。作者回复: 👍和论文里的说法基本一样。
2021-09-2414
pedromit6.824在讲GFS的时候说，GFS并没有什么理论创新，但是它一下子搞了1000多台机器的集群，对其它论文而言完全是降维打击，然后它就被会议接收了。作者回复: 是这样的，打个不一定恰当的比方，就像大家都在搞核理论的时候，Google炸了一枚核弹说核物理就是这样的。
2021-09-24213
webmin1. GFS客户端会在读取数据时，把文件其余块的元数据缓存在本地，因为是追加写已写入成功的元数据短期不会变化，再者从空间局部性的原理出发，读部分块后，大概率会要接下来读这个文件余下块，所以提前装载元数据也算是一种优化预测吧； 2. master重启后，会让chunkserver上报自己管理的chunk的meta信息，这样做可以我想是考虑到了在master关闭期间chunkserver本身会发生一些变化，比如chunkserver的主备发生切换或者因为运维需要调整了chunkserver的IP地址等吧。作者回复: 👍
2021-09-269- Geek_74dea9chunk的位置信息并不会持久化，而是在master启动的时候， 让chunk server汇报给master
作者回复: 回答正确，相信你一定仔细去看了论文。
2021-09-275 
推推。想问一下 master 如何更新 chunk server的状态和数据呢 如果有 chunk server failed了 如何建立一个新的trunk server 呢作者回复: 这部分可以读一下论文 4.3 部分，master和chunkserver之间有心跳 集群并不会“创建”新的trunk server，而是有新的硬件加入到trunk server，master可以根据策略去做rebalance。 如果有硬件下线，master也不关心如何恢复，他只会利用剩下的硬件来确保3份replica来保持可用性。
2021-09-2823
潇湘夜雨想请问下，看gfs三驾马车等论文需要啥前置知识吗，我正在学大数据相关技术与框架，对分布式不是很了解，看论文有点摸不着头脑作者回复: 潇湘夜雨同学， 你好，从我自己读论文的经验来看。读GFS，MapReduce和BigTable的论文，对于背景知识的要求不高。也比较容易读懂。 对于没有太多实际分布式系统经验的同学来说，主要的学习挑战，会在后续的Chubby，Spanner这些论文中。不过我会在里面补充足够的基础知识，让大家能够读懂这些看起来有些复杂的论文。
2021-09-261
不加y数据写入过程没有描述，老师数据写入的整体流程是什么样的？比如数据是三副本，三个副本的数据都写成功，才算是写成功吗？作者回复: 往后看05
2023-03-28归属地：广东
海滨1. 客户端应该会缓存请求过的文件对应的chunk sever的元数据信息，这部分数据占用大小很小非常适合缓存，缓存之后可以减少对master server的压力。 缓存的数据是可能过时的，我觉得主要分2种情况，一种是文件chunk对应的chunk sever变了，这个时候文件chunk一旦请求不到重新向master重新请求更新就可以了；还有一种情况数据更新了，比如文件对应的chunk数变多了，这种情况应该在chunk sever有相关机制来校验这种情况吧。 2. 还没有读过论文，我猜测应该是chunk sever主动上报的方式来使master重新拿到这个数据的吧作者回复: 👍
2021-10-02
融冰1. 客户端会缓存文件和 chunkserver 的映射，这个缓存会在时效结束或者文件被重新打开的时候失效 2. chunk 存放在什么 chunkserver 这个由 chunkserver 自己维护，master 重启的时候会跟所有 chunkserver 获取对应存储的 chunk作者回复: 👍
2021-10-012
