GFS第一讲--整体架构及数据读取流程

139 阅读4分钟

素未谋面之人啊,很高兴您能点开这篇文章。这是我依据论文《GFS》-- google分布式文件系统写就的第一篇文章。我在阅读的过程中,产生出了许多疑惑,伴随而产生的是更多的不曾了解的作为前提的知识点,更重要的是,看后根本无法有效记住。针对这些问题,便有了这一篇阶段性总结的文章。我将采用一张图的形式,花费3-5分钟,讲透一个功能模块。希望你和我一样,看完能够有所收获。

GFS-1.PNG

现在,先来让我们认识图中的各大组件。不过,我们的第一课,只需要记住加粗部分,便能理解这篇文章。

GFS组件

Master

Master具有三项重要任务:

  1. 存储整个文件系统的元数据[metadata]信息,包括:命名空间[namespace]、访问权限[access control]、文件-数据块的映射关系 以及 数据块的位置信息[chunk location]
  2. 负责整个系统的维护和调度。如:数据块的管理、垃圾回收和数据块在不同chunkServer之间的迁移(负载均衡以及副本制作)。
  3. 与系统中的每一个chunkServer建立心跳连接,并通过此连接进行数据交换和状态收集。

数据块服务[ChunkServer] 和 数据块[Chunk]

数据块服务[chunkServer]负责数据块[chunk]的存储和写入。一个大文件,会按固定大小被拆分为多个数据块[chunk],分散到不同的部署有chunkServer的机器上。此外,为了容灾性,每个数据块[chunk]也都有数个(默认3个)副本在不同的chunkServer上。客户端读取任意一个副本都是没有差别的。 在数据块[chunk]的创建过程中,master会给它分配一个64-bit的全局唯一ID,小名块句柄[chunk handle]

客户端[Client]

GFS 系统对外提供的一套标准的文件操作API,以供其他app使用。具体功能是 与Master和ChunkServer建立连接,进行通信,实现文件操作的相关功能

数据读取流程

  1. 因为每个数据块的大小都是固定的,客户端便可将一个标准的文件操作参数(文件名[file name],偏移量[offset]) 转换为该文件的第x块[chunk index]。
  2. 发送带有(file name,chunk index) 的请求给Master,得到相应的回复报文(chunk handle,chunk locations)。
  3. 客户端挑一个距离最近的chunkServer建立通信。请求报文包括-- 块句柄和操作字节范围(chunk handle,byte range)
  4. 最后,chunkServer响应报文,返回对应位置的数据(chunk data)

加餐部分

基础部分到此结束,下文是个人的一些思考和疑问,我称之为“加餐”。因为,为了面试,上面的知识点足够了。可要是为了学习,当然是多多益善。

🎁整个系统是如何保证高性能、低延迟的? 🗝系统对提高性能做了如下的努力:

  1. 将元数据信息存入了Master的内存中。
  2. 为了减少client-master之间的交互,客户端每次请求Master,得到的结果也会自己缓存一份。
  3. clinet-chunkServer之间频繁的数据交换,使用的是长连接,可以降低短连接带来的握手时间消耗。

🎁为什么要使用句柄来操作文件 🗝master为了整体系统的可靠性,会制作副本并移动数据块的存储位置。master自身的(对无效数据块的)垃圾回收,也会移动数据块的存储位置。而使用句柄,则可以屏蔽这层改动。

🎁数据块的大小设置对整体性能有何影响? 🗝最基础的一点:数据块越大,代表着存储的数据量越多。那么:

  • 对其随机访问的速率也就越慢,相应的对顺序访问的速率越快。
  • 放入缓存的代价太大,因此需考虑其他方案。相反,如果一定要放入缓存,则只能将块大小改小。
  • 数据块越小,越容易产生存储碎片,就需要额外花时间去整理;而块越大,一次申请就能用许久,不易产生碎片。