目录

• 背景
• 系统设计
  • 1. 系统功能
  • 2. Master组件
    • 2.1 命名空间
    • 2.2 心跳机制
    • 2.3 故障恢复和容错机制
  • 3. ChunkServer组件
    • 3.1 本地存储
    • 3.2 内存命中机制
    • 3.3 状态维护
    • 3.4 副本管理
  • 4. Client组件
    • 4.1 上传
    • 4.2 下载
    • 4.3 追加
    • 4.4 删除
    • 4.5 文件列表

本系列主要是使用Java RMI 实现一个简单的GFS（谷歌文件系统，google file system），这里介绍GFS背景以及系统的设计相关。

[为了更好的阅读以及查看其他篇章，请查看原文：https://www.cnblogs.com/maogen/p/gfs_1.html]

🧨 🧧
ʰᵅᵖᵖʸ ⁿeᵚ ʸᵉᵅʳ

家人闲坐 灯火可亲
辞旧迎新 新年可期

系统整体介绍、系统实现、演示视频以及源代码：

介绍篇：https://www.cnblogs.com/maogen/p/gfs_0.html

演示与实现篇：https://www.cnblogs.com/maogen/p/gfs_2.html

作者：晨星1032-博客园：https://www.cnblogs.com/maogen/

背景

​ 随着当代社会信息化程度的持续提升，所产生的数据呈现爆炸式增长趋势。与此同时，数据对于我们也越来越重要。在这种情况下，如何存储海量的数据，如何对服务器集群上的海量数据进行有效的管理，如何降低存储成本，以及如何使存储海量数据的服务器集群对外提供高效服务并且保证服务不中断，都是我们必须面对的问题。

​ 分布式文件系统(Distributed File System，DFS)将会很好的解决上述问题。如上图所示，分布式文件系统采用可扩展的系统结构，可以实现冗余存储、文件同步，系统容错、故障恢复等原本需要人工手动才能实现的功能，大大降低维护难度，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展，可以让我们有效存储并管理利用海量数据。

​ GFS(Google File System)是Google公司为了存储海量搜索数据而设计的专用文件系统。GFS作为一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能，可以根据系统的需要向其中添加任意数目的廉价商用计算机用于满足数据存储的需要，实现了减少运营成本的同时能够对外提供优良的服务。

​ GFS的系统架构如上图所示，它包含总控服务器，数据服务器以及客户端。GFS将文件分割成为若干个大小固定（64MB）的数据块，同时总控服务器会为这些数据块创建一个唯一标识。同一文件的所有数据块会分布于系统中的不同节点之上，为了保证数据的可靠以及可用，通过复制实现系统中包含同一数据块的多个副本，通常情况下为三个副本。

系统设计

1. 系统功能

​ 如图所示为MyGFS系统各功能模块划分的分解图。系统共有三个核心组件：Master、ChunkServer和Client。Master存储整个文佳系统的目录结构和文件元数据，并对文件元数据管理；ChunkServer为存储具体文件数据的服务器，对数据进行管理；Client是使用GFS功能的客户端。

2. Master组件

2.1 命名空间

Master命名空间包含：

1. 整个文件系统的目录结构和Chunk的基本信息；
2. 文件与Chunk的映射关系；
3. 各个Chunk备份（Replicas）的位置信息，默认为3个副本。

2.2 心跳机制

​ 心跳机制是让Master服务器了解到Chunk服务器的状态，检测Chunk服务器是否在线以及获取相关信息。

​ 如图所示，实现心跳机制可有两种方式。方式①是Chunk服务器间隔时间向Master服务器汇报自己在线以及自身信息，若在一定时间内，Master服务器一直未收到Chunk服务器传来的信息，则认为Chunk服务器掉线并进行后续步骤执行；方式②是Master服务器主动向Chunk服务器发送消息，Chunk服务器收到后将自身信息反馈给Master服务器，若一定时间内Master服务器一直未收到Chunk服务器传来的信息，则认为Chunk服务器掉线并进行后续步骤执行。

​ 本系统将使用Java RMI的lookup相关函数进行方式②检测。

2.3 故障恢复和容错机制

​ GFS系统是构建在普通的、廉价的机器上，因此故障是常态而不是意外。对发生的故障及时恢复，不能影响操作。

​ 如图为故障恢复流程，Master根据心跳机制检测ChunkServer是否掉线，若掉线则需要分配新的服务器负载均衡，并将取出该ChunkServer上对应的Chunk文件，对其进行复制；若在线则继续将该ChunkServer上的Chunk文件的Hash值对比，检测是否数据是否一致，若不一致则使用该Chunk文件的副本对其进行替换；若一致，则检测结束。

3. ChunkServer组件

3.1 本地存储

​ ChunkServer中存储Chunk的具体文件内容。GFS将每个Chunk限制为64Mb, Chunk内部又分为众多的Block。

3.2 内存命中机制

​ GFS系统是一次写入多次读取，对于读操作较多，采用内存命中，将一定大小的文件放至内存使得读取速度更快。

​ 如图所示为内存命中机制示意图，Mem工作原理要求它尽量保存最新数据，当从Disk向Mem传送一个新块，若Mem中可用位置已被占满时，则采用最近优先策略进行替换。

3.3 状态维护

​ 如图所示，ChunkServer内存上包含Chunk文件的ID和其Hash值，通过一个Thread间隔时间检测本地Chunk文件将Map更新为实际Hash值，并可以将Hash值发送给Master，由Master进行对比处理。

3.4 副本管理

​ 为保证GFS系统的数据可靠性，系统对于Chunk文件进行主副本（primary-secondary）管理。ChunkServer上的Primary负责对其Secondary进行数据操作管理，保证数据一致性。

4. Client组件

4.1 上传

​ 客户端上传功能是整个GFS系统写模型的体现。

​ 如图所示，写模型是将数据流和控制消息分开，本文采用主从推送方式（非链式推送）。Client向Master请求Chunk的副本信息和Primary Replica信息；Master回复Client相关信息；Client将数据首先推送到Primary，再由Primary推送到所有的Secondary；若全部推送成功则Primary副本所在的ChunkServer会采用回调的方式更新Master节点，Master再通知Client是否成功。

4.2 下载

​ 客户端下载功能是GFS系统读模型的体现。

​ 如图所示，读模型也是将数据流与控制消息分开。Client将需读取的文件名发送给Master，Master响应Chunk文件所在ChunkServer的相关信息；Client再去请求该ChunkServer的Chunk，获取Chunk文件流下载到本地。

4.3 追加

​ GFS系统文件修改仅支持Append追加方式。

​ 如上两图所示，GFS系统追加信息，Client首先请求Master该文件的最后一个Chunk的信息以及所在的ChunkServer位置；然后Client将追加数据流发送给ChunkServer；若追加内容大小与该最后一个Chunk剩余空间小时，可直接在后追加内容，若大于剩余空间时，将最后一个Chunk空间填满，并新建新Chunk继续上述操作判断直至追加内容全部添加进去；最后修改成功后向Master通知，确保数据一致性。

4.4 删除

​ 客户端删除相关文件时，首先将需删除的文件名发送给Master，Master会先删除命名空间里关于该文件的信息，再通知ChunkServer进行删除本地信息。

4.5 文件列表

​ 客户端展示文件列表，是向Master请求GFS系统内的所有文件列表，Master响应后Client端进行展示给用户。

系统整体介绍、系统实现、演示视频以及源代码，尽在其他篇章：

介绍篇：https://www.cnblogs.com/maogen/p/gfs_0.html

演示与实现篇：https://www.cnblogs.com/maogen/p/gfs_2.html

作者：晨星1032-博客园：https://www.cnblogs.com/maogen/