素未谋面之人啊，很高兴您能点开这篇文章。这是我依据论文《GFS》-- google分布式文件系统写就的第一篇文章。我在阅读的过程中，产生出了许多疑惑，伴随而产生的是更多的不曾了解的作为前提的知识点，更重要的是，看后根本无法有效记住。针对这些问题，便有了这一篇阶段性总结的文章。我将采用一张图的形式，花费3-5分钟，讲透一个功能模块。希望你和我一样，看完能够有所收获。
现在，先来让我们认识图中的各大组件。不过，我们的第一课，只需要记住加粗部分，便能理解这篇文章。
GFS组件
Master
Master具有三项重要任务：
- 存储整个文件系统的元数据[metadata]信息,包括：命名空间[namespace]、访问权限[access control]、文件-数据块的映射关系 以及 数据块的位置信息[chunk location]
- 负责整个系统的维护和调度。如：数据块的管理、垃圾回收和数据块在不同chunkServer之间的迁移(负载均衡以及副本制作)。
- 与系统中的每一个chunkServer建立心跳连接，并通过此连接进行数据交换和状态收集。
数据块服务[ChunkServer] 和 数据块[Chunk]
数据块服务[chunkServer]负责数据块[chunk]的存储和写入。一个大文件，会按固定大小被拆分为多个数据块[chunk]，分散到不同的部署有chunkServer的机器上。此外，为了容灾性，每个数据块[chunk]也都有数个(默认3个)副本在不同的chunkServer上。客户端读取任意一个副本都是没有差别的。 在数据块[chunk]的创建过程中，master会给它分配一个64-bit的全局唯一ID，小名块句柄[chunk handle]
客户端[Client]
GFS 系统对外提供的一套标准的文件操作API，以供其他app使用。具体功能是 与Master和ChunkServer建立连接，进行通信，实现文件操作的相关功能
数据读取流程
- 因为每个数据块的大小都是固定的，客户端便可将一个标准的文件操作参数(文件名[file name]，偏移量[offset]) 转换为该文件的第x块[chunk index]。
- 发送带有(file name,chunk index) 的请求给Master，得到相应的回复报文(chunk handle,chunk locations)。
- 客户端挑一个距离最近的chunkServer建立通信。请求报文包括-- 块句柄和操作字节范围(chunk handle,byte range)
- 最后，chunkServer响应报文，返回对应位置的数据(chunk data)
加餐部分
基础部分到此结束，下文是个人的一些思考和疑问，我称之为“加餐”。因为，为了面试，上面的知识点足够了。可要是为了学习，当然是多多益善。
🎁整个系统是如何保证高性能、低延迟的？ 🗝系统对提高性能做了如下的努力：
- 将元数据信息存入了Master的内存中。
- 为了减少client-master之间的交互，客户端每次请求Master，得到的结果也会自己缓存一份。
- clinet-chunkServer之间频繁的数据交换，使用的是长连接，可以降低短连接带来的握手时间消耗。
🎁为什么要使用句柄来操作文件 🗝master为了整体系统的可靠性，会制作副本并移动数据块的存储位置。master自身的(对无效数据块的)垃圾回收，也会移动数据块的存储位置。而使用句柄，则可以屏蔽这层改动。
🎁数据块的大小设置对整体性能有何影响? 🗝最基础的一点：数据块越大，代表着存储的数据量越多。那么：
- 对其随机访问的速率也就越慢，相应的对顺序访问的速率越快。
- 放入缓存的代价太大，因此需考虑其他方案。相反，如果一定要放入缓存，则只能将块大小改小。
- 数据块越小，越容易产生存储碎片，就需要额外花时间去整理；而块越大，一次申请就能用许久，不易产生碎片。
