QFS的整体架构

1 架构图

图 1 QFS架构图

         看过GFS paper的人一眼就能认出这个图，这种架构正是源自于GFS，只是模块名称换了一些名字而已。

2 各模块简介

     QFS系统由三部分组成，分别是metaserver（相当于GFS master）、chunkserver（相当于GFS chunkserver）和client library（相当于GFS client）：

        metaserver：元数据服务器，使用B+树存储分布式文件系统的全局文件系统命名空间，一个QFS中仅有一个metaserver。

        chunkserver：chunkserver是存储文件数据的，在一个QFS中，有一系列的chunkserver，数据一般都是存储在底层的文件系统（如Linux的ext3、ext4）。一个大文件被切分成许多固定大小（QFS中是64M）的文件块block，称为chunk。为了容灾，每一个chunk都会有一定数量的数据副本（默认为3份），每一个chunk副本都会被存在不同的chunkserver上。

        client lib：提供文件系统访问的API，这些API都是类posix的，实际的应用中需要往QFS读写数据时，必须调用这些API。

3 文件读写流程简介

文件系统顾名思义就是用来存储文件管理文件的，那么QFS中是怎么实现文件读写的呢？

假设，有一个20M的文件要存储在QFS中，文件名是test1，存储路径是/file目录下。

写流程如下：

（1）client调用QFS client lib的相关接口，发送RPC给metaserver；

（2）metaserver在命名空间中给/file/test1分配一个fileid、chunkid，并将文件名（/file/test1）与fileid和chunkid的对应关系保存在B+树中，然后从chunkserver列表中，根据一定的负载均衡策略分配3个chunkserver（假设chunk副本数是3），返回给client；

（3）client开始向chunkserver写实际的文件数据。

这里有几个问题：

（1）为什么QFS需要自己的命名空间，命名空间实际是什么样的？

（2）为什么要有fileid、chunkid？

（3）对于client来说，client只知道metaserver的ip，chunkserver完全是透明的。写数据的具体流程，以及多个副本间的数据一致性怎么保证？

这些问题暂时先留着，之后的博文中会有详细的解答。

读流程：

·（1）client向metaserver发送读/file/test1的RPC；

 （2）metaserver根据文件名，在B+树中找到对应的fileid、chunkid，然后根据chunkid找到哪些chunkserver保存有文件数据，然后将这些chunkserver列表返回给client；

（3）client从具体的chunkserver读取文件。

大概的读写交互流程就是这样的，但是具体的实现以及细节上的处理，都还是比较复杂的，其中也有一些很值得学习的算法，之后将会一一道来。