WO2015180070A1 - 一种用于分布式存储系统的数据缓存方法及装置 - Google Patents

Abstract

本发明涉及一种用于分布式存储系统的数据缓存方法，包括如下步骤：名称节点上载配置文件到其内存中并解析所述配置文件；得到配置文件中关于缓存的信息，所述信息包括缓存路径、缓存方式、副本数量以及取消缓存的条件；名称节点在与各个数据节点握手时将该数据节点涉及的缓存信息传输给所述数据节点；所述数据节点取出其涉及的缓存数据并按照其接收到的缓存信息存储在该数据节点的内存中；完成数据缓存后，数据节点在下一次握手时通知所述名称节点。本发明还涉及一种实现上述方法的装置。实施本发明的用于分布式存储系统的数据缓存方法及装置，具有以下有益效果：其结构简单、内部的数据交换较少。

Description

一种用于分布式存储系统的数据緩存方法及装置

技术领域

本发明涉及分布式存储系统， 更具体地说， 涉及一种用于分布式存储系统 的数据緩存方法及装置。

背景技术

当前， 对于信息的存储和处理方式在不断演变。 海量数据的存储和计算无 法在单个计算机上完成， 分布式存储和计算系统逐渐成为主流。 在使用分布式 存储系统时， 往往需要一款优秀的分布式文件系统来对存储进行管理。 分布式 文件系统（ Distributed File System )是指文件系统管理的物理存储资源不一定直 接连接在本地节点上， 而是通过计算机网络与节点相连。 分布式文件系统的设 计基于客户机 /服务器模式。一个典型的网络可能包括多个供多用户访问的服务 器。 另外， 对等特性允许一些系统扮演客户机和服务器的双重角色。 近年来诞 生了许多优秀的分布式文件系统， 诸如 Google的 GFS、 openStack的 swift以及 Hadoop 的 HDFS等等， 都是优秀的分布式文件系统实现方式。 例如， Hadoop 的分布式文件系统。 HDFS在最开始是作为 Apache Nutch搜索引擎项目的基础 架构而开发的。 HDFS是 Apache Hadoop Core项目的一部分。 它和现有的分布 式文件系统有很多共同点。 但同时， 它和其他的分布式文件系统的区别也是很 明显的。 HDFS是一个高度容错性的系统， 适合部署在廉价的机器上。 HDFS能 提供高吞吐量的数据访问，非常适合大规模数据集上的应用。 HDFS放宽了一部 分 P0SIX约束， 来实现流式读取文件系统数据的目的。 作为一个日趋成熟的分 布式文件系统， HDFS是构建海量数据存储平台最佳选择之一。 例如， 在视频存 储领域， 使用 H DFS作为存储平台， 有显著优点。

一般来讲， 在分布式存储系统中， 使用緩存来对系统各个环节的加速随处 可见。 从广义角度来说， 任何数据流经过的地方都可以添加緩存， 因此可以在 客户端添加緩存、 使用 CDN緩存、 代理服务器緩存以及分布式存储数据节点 的緩存。 在分布式文件系统内部添加緩存， 又可以根据不同的需要分为不同类 型的緩存设计。 针对位置不同， 可以将緩存加入到元数据服务器、 数据节点服 务器； 根据物理材质不同， 可以使用磁盘、 闪存、 内存作为不同级别的緩存工 具； 根据作用不同， 可以对元数据緩存、 检索记录緩存、 文件列表緩存、 数据 内容緩存等等。

例如，有人提出了一种带有分布式緩存结构的 HDFS系统，叫做 HDCache。

HDCache基于 HDFS添加了一套緩存系统， 在 HDFS上层设计和实现一套緩存体 系， 针对实时云端大规模的快速存取提供更好的服务。 HDCache将一套分布式 緩存机制引入整个系统， 以松輛合的模式整合在一起， 便于管理、 部署、 替换 和升级， 而不会给 HDFS本身带来任何隐患。 HDCache的设计按照传统的 C/S架 构， 在客户端提供了一个动态连接库， 所有使用 HDCache的应用程序需要在自 己的客户端集成动态连接库； 在服务器端， 每一台部署 HDCache System的服 务器都会运行一个守护进程。 在 HDCache中， 其缺陷为： 需要在客户端集成緩 存框架动态连接库， 内部集成緩存代码库， 使得客户端更庞大， 也更容易出现 软件协调故障， 对客户体验会造成影响； 此外， 该系统在 HDFS外层添加緩存 代理服务器， 对 HDFS本身并没有改进， 而是构建于其上的緩存服务。 这并不 能解决 HDFS本身磁盘读取速度低的瓶颈， 只是在外层用緩存作为保护。 从实 现角度来说， 这套系统是从应用角度来给出一个解决方案， 并没有改善 HDFS 本身的存取性能。

又如， 有人提出了一种在不需要管理节点的情况下， 在松輛合的 VOD系统 中有效的使用分布式緩存的方法， 并提出了一种新的緩存算法， 叫做 SCC ( Scalable and Cooperative Caching ) 。 SCC算法分为两个方面： 一个是调度层 次的算法， 它设计了一套价值模型来评估服务器的处理模式； 另一个是緩存技 术的实现。 但是， 这种方法依然存在几个问题： 在分布式存储系统里， 当集群 数量很大的时候， SCC并没有在緩存一致性方面提出有效策略； 其次， 数量很 大时， 每一个节点需要存储其他节点的全部文件元数据信息， 大量的内部数据 交换， 对系统本身的会造成很大影响。

发明内容

本发明要解决的技术问题在于， 针对现有技术的上述结构复杂、 可能存在 许多内部数据交换的缺陷， 提供一种结构简单、 内部数据交换较小的一种用于 分布式存储系统的数据緩存方法及装置。

本发明解决其技术问题所釆用的技术方案是： 构造一种用于分布式存储系 统的数据緩存方法， 所述分布式存储系统包括多个用于存储数据的数据节点和 与所述多个数据节点通过网络连接的并管理所述多个数据节点的名称节点， 所 述方法包括如下步骤：

A )名称节点上载配置文件到其内存中并解析所述配置文件；

B )得到配置文件中关于緩存的信息， 所述信息包括緩存路径、 緩存 方式、 副本数量以及取消緩存的条件；

C )名称节点在与各个数据节点握手时将该数据节点涉及的緩存信息 传输给所述数据节点；

D ) 所述数据节点取出其涉及的緩存数据并按照其接收到的緩存信息 存储在该数据节点的内存中； 完成数据緩存后， 数据节点在下一次握手时通知 所述名称节点。

更进一步地， 还包括如下步骤：

E )客户端发出读请求到所述名称节点， 所述名称节点查找其要求的 数据是有緩存，如有，返回緩存位置到客户端；如无，按照正常的读请求处理；

F )客户端向数据节点发送数据读请求， 数据节点在收到所述数据读 请求后查找本地緩存列表，如有，直接由其内存发送数据给所述客户端；如无， 读取其磁盘取得数据并发送给所述客户端， 同时通知所述名称节点緩存异常。

更进一步地， 所述配置文件是由客户端定义并传输给所述名称节点的； 所 述配置文件在所述名称节点上被转换为一个緩存策略文件， 所述緩存策略文件 中包括多个表示緩存文件的对象； 所述名称节点通过周期性的扫描线程在每个 周期上取得并替换其内存中的緩存策略文件。

更进一步地， 所述步骤 B )进一步包括：

B1 )取得所述緩存策略文件中的一个对象；

B2 )判断所述对象指向的路径是一个还是一个目录，如果是一个文件， 执行步骤 B3 ); 如果是一个目录， 将其解析为多个文件后执行步骤 B3 );

B3 )构建一个表示所述緩存文件的元数据，所述元数据包括文件描述、 文件所包括的所有数据块描述、 緩存份数及緩存周期； 其中， 所述数据块描述 包括其緩存路径、 其所在数据节点在所述名称节点上的描述、 块序号、 块长度 及其数据块状态标志； B4 )重复上述步骤 Bl ) -B3 )直到处理完所述緩存策略文件中的所有 对象。

更进一步地， 所述步骤 B ) 中还包括如下步骤：

将处理每个所述对象得到的元数据中所有数据块描述中的数据块緩存 路径集合在一起， 得到本次扫描需要緩存数据块列表。

更进一步地， 所述步骤 C ) 中进一步包括：

C1 )有所述本次扫描需要緩存数据块列表中取出设定个数的数据块緩 存路径；

C2 )按照所述緩存路径指向的数据节点， 在与该数据节点握手时将所 述数据块緩存路径发送到该数据节点。

更进一步地， 所述步骤 D )进一步包括：

D1 )取得本次握手时得到的所有数据块緩存路径， 并依次按照每个数 据块緩存路径读取该数据块， 并将其在该数据节点的内存中緩存； 如未找到数 据块或内存空间有限不能緩存， 则标记该数据块緩存失败并处理下一个数据块 緩存路径；

D2 )在下一次握手时返回所述名称节点所有数据块的緩存结果。

本发明还涉及一种实现上述方法的装置， 所述分布式存储系统包括多个用 于存储数据的数据节点和与所述多个数据节点通过网络连接的并管理所述多 个数据节点的名称节点， 所述装置包括：

配置文件解析模块： 用于在名称节点上载配置文件到其内存中并解析 所述配置文件；

緩存信息取得模块： 用于得到配置文件中关于緩存的信息， 所述信息 包括緩存路径、 緩存方式、 副本数量以及取消緩存的条件；

緩存信息发送模块： 用于使名称节点在与各个数据节点握手时将该数 据节点涉及的緩存信息传输给所述数据节点；

緩存实现模块： 用于使所述数据节点取出其涉及的緩存数据并按照其 接收到的緩存信息存储在该数据节点的内存中； 完成数据緩存后， 数据节点在 下一次握手时通知所述名称节点。

更进一步地， 还包括： 读请求模块： 用于使客户端发出读请求到所述名称节点， 所述名称节 点查找其要求的数据是有緩存， 如有， 返回緩存位置到客户端； 如无， 按照正 常的读请求处理；

緩存查找模块： 用于使客户端向数据节点发送数据读请求， 数据节点 在收到所述数据读请求后查找本地緩存列表， 如有， 直接由其内存发送数据给 所述客户端； 如无， 读取其磁盘取得数据并发送给所述客户端， 同时通知所述 名称节点緩存异常。

更进一步地， 所述緩存信息取得模块还包括：

对象取得单元： 用于取得所述緩存策略文件中的一个对象；

路径判断单元： 用于判断所述对象指向的路径是一个还是一个目录， 如果是一个文件， 调用元数据形成单元； 如果是一个目录， 将其解析为多个文 件后调用元数据形成单元；

元数据形成单元： 用于构建一个表示所述緩存文件的元数据， 所述元 数据包括文件描述、 文件所包括的所有数据块描述、 緩存份数及緩存周期； 其 中， 所述数据块描述包括其緩存路径、 其所在数据节点在所述名称节点上的描 述、 块序号、 块长度及其数据块状态标志；

对象判断单元： 用于判断是否处理完所述緩存策略文件中的所有对象； 数据块列表形成单元： 用于将处理每个所述对象得到的元数据中所有 数据块描述中的数据块緩存路径集合在一起， 得到本次扫描需要緩存数据块列 表。

实施本发明的用于分布式存储系统的数据緩存方法及装置， 具有以下有益 效果： 由于实用配置文件确定了需要緩存的文件的参数， 并在名称节点将配置 文件解析， 得到表示緩存文件的元数据； 在名称节点和数据节点握手时， 将上 述元数据中表示数据块的相关参数传输到数据节点， 数据节点将这些参数指示 的数据块由磁盘读出并緩存在该数据节点的内存中。 这样， 既没有对 HDFS本 身的结构做出修改， 又解决了相关数据緩存的问题。 因此其结构简单、 内部的 数据交换较少。

附图说明

图 1是本发明用于分布式存储系统的数据緩存方法及装置实施例中緩存方 法的流程图；

图 2是所述实施例中名称节点上处理配置文件部分的逻辑结构示意图； 图 3是所述实施例中緩存数据块的状态转换示意图；

图 4是所述实施例中的装置结构示意图。

具体实施方式

下面将结合附图对本发明实施例作进一步说明。

如图 1 所示， 在本发明分布式存储系统的数据緩存方法及装置实施例中， 其方法包括如下步骤：

步骤 S11 上载配置文件到其内存并解析： 在本实施例中， 分布式存储系统 包括多个用于存储数据的数据节点 （Data Node,DN )和与所述多个数据节点 通过网络连接的并管理所述多个数据节点的名称节点（Name Node,NN ) ， 客 户端通过上述名称节点取得上述数据节点上存储的数据。 在现有技术中， 在没 有緩存的情况下， 客户端向名称节点提出读请求， 告知该名称节点需要读出的 文件； 名称节点查找到该文件的存储位置， 并将该位置返回提出读请求的客户 端； 该客户端得到这些信息后， 再向存储有该文件 （或组成该文件的数据块） 的数据节点提出读请求， 这些收到请求的数据节点读出文件或数据块， 并返回 给该客户端， 以完成数据或文件的取得。 在本实施例中， 当完成指定文件的緩 存后， 读取该文件的步骤大致上还是相同的。 只不过在文件被緩存的情况下， 名称节点返回给客户端的不是文件的存储位置而是緩存的位置， 数据节点也不 是直接去读取文件而是在查找到緩存目录的情况下直接将緩存的文件发送给 客户端。这样，在最大程度不增加内部数据传输的情况下，实现了文件的緩存， 提高了取得文件的速度， 改善了用户的体验。 当然， 在本实施例中， 首先还是 要实现文件的緩存， 这些緩存的文件是由客户编写的配置文件指定的。 具体说 来， 就是把所有数据节点 （DN ) 的内存整合成为一个内存池， 通过配置的方 式暴露给客户端， 使得客户端可以通过配置文件对 HDFS存储的数据进行緩存 定制化。 HDFS本身是一个 Master/Slave结构， 所有的请求都需要 NN(Namenode 名称节点)来负责处理，这样就给数据的统一处理提供了方便，可以在存储的同 时指定是否緩存， 对于读取数据而言， 从 DN的内存读取显然比从磁盘读取要 快捷的多， 使得整个系统更加高效。 在本实施例中， 客户在客户端根据需求编 写配置文件， 配置文件使用 xml来编写， 可以指定的参数包括： 緩存路径、 緩 存周期、 緩存份数（根据文件的使用频度可调节） 、 緩存替换策略、 緩存清理 策略等。 编写好的配置文件可以传输给名称节点或由名称节点读取配置文件， 由于 HDFS的配置信息并不大， 完全读入内存不会影响系统性能， 因此， 在本 实施釆用简单的 DOM (文档对象模型）来解析配置信息， 之后构造合理的数据 结构保存信息， 并构造一系列工作线程， 保证整个机制可以顺利工作。

步骤 S12得到元数据， 并将其中表示数据块的描述列表： 在本步骤中,数 据节点将其内存中的配置文件解析，并构建合理的数据结构保存，并供给下一个 流程使用处理。 在实现上， 通过设置在数据节点上的 HDFS的 API定义一个对 象,即 CachePolicy,在该对象中保存从配置信息里读取的文件路径、緩存份数、 替换策略、 声明周期等内容。 同样地， 通过 HDFS的 API调用或定义一个周期 性的扫描线程 ConfigMonitor,从 HDFS 自身的配置文件 hdfs-site.xml读取扫描 周期 （该扫描周期是自定义的）， 按照上述周期的设定， 每周期读取一次配置 信息。 无论是新增的路径、 修改了生命周期、 緩存个数或者替换策略等， 都需 要生成新的 CachePolicy; 另外， 考虑到某些路径本身可能没有改变， 但其上存 放的文件可能有增加或者删除的变化， 因此即使某个路径的所有参数没有发生 改变， 也依然构造 CachePolicy对象。

在本步骤中， 在数据节点上， 通过 CacheMangaer对緩存进行管理。 CacheMangaer运行于一个 Facade模式， 集合了所有相关的数据结构和线程， 处 理所有和緩存相关的事务。 在本实施例中， 对每个需要緩存的文件以及每个文 件存储在各数据节点上的数据块分别进行描述。 这些描述表示了文件或数据块 的緩存参数。 这些描述被保存在名称节点上形成列表， 同时， 在名称节点和相 关的数据节点握手时发送到数据节点， 即使不进行緩存， 名称节点和数据节点 的握手也是要进行的， 所以， 这些对文件或数据块的描述的发送并没有增加该 HDFS系统内部的数据传输量或增加得不多。 每一个需要被緩存的文件都有对 应的一个元数据表示 CacheFile,它包含文件的 INodeFile(文件元数据的描述 )、 所有的緩存数据块以及从 CachePolicy得到的緩存份数、 生命周期等。 作为一个 常识， 一个文件在 HDFS中是被分割为多个数据块的。 其中， 每一个数据块也 对应 着一个描述对 象 CachedBlock， 它 包含该数据块所在 的 DND(DatanodeDescriptor数据节点在名称节点的描述)， 从 block ( HDFS自带的 数据块对象）得到的块序号、 块长度、 块代号等信息； 此外， 数据块的描述对 象还包括四个状态标志： isSend, isCached, willDelete, isDeleted, 这些标志位分 别表示该数据块的状态分别是已经发送、 已经緩存、 等待删除和已经删除四个 状态。 这些状态代表了一个緩存块的整个活动周期。 关于被緩存的数据块的状 态转换， 请参见图 3。

总之， 在本步骤中， 名称节点对于其内存中的配置文件的处理过程为： 取 得所述緩存策略文件中的一个对象（或配置文件中对于一个緩存文件描述的参 数或参数集）； 之后， 判断该对象指向的路径是一个文件还是一个目录（即判 断该路径指向的位置上是一个文件还是一个目录或文件夹）， 如果是一个文件， 则构建表示该文件的元数据； 如果是一个目录， 将其解析为多个文件后再分别 构建表示各文件的元数据。

而构建一个表示文件的元数据的方法大致是相同的。 对于不同文件而言， 仅仅是构建出来的元数据的参数不同而已。 在本实施例中， 元数据包括文件描 述、 文件所包括的所有数据块描述、 緩存份数及緩存周期； 其中， 所述数据块 描述包括其緩存路径、 其所在数据节点在所述名称节点上的描述、 块序号、 块 长度及其数据块状态标志； 也就是说， 元数据中不仅仅包括对文件的描述， 还 包括对组成文件的所有数据块的描述。 由于一个文件在 HDFS中又多个数据块 组成， 且这些数据块可能不是存储在同一个数据节点中的， 所以， 对于元数据 而言， 其中的数据块描述是元数据中非常重要的一个部分或是关键的一个部分。

在本实施例中， 一个配置文件中可能包括对多个文件的緩存参数， 因此， 一个配置文件被处理后可能产生多个对象。 上面所述的步骤是对一个对象的处 理， 当有多个对象时， 依次分别按照上述步骤对每个对象进行处理， 直到处理 完所述緩存策略文件中的所有对象。

在本实施例中， 名称节点中处理上述配置文件的部分的内部逻辑结构如图 2所示， 由图 2可以看出， 在緩存的构建过程中， 使用 TriggerMonitor线程周期性 的从 ConfigMonitor线程中读取 CachePolicy对象，然后将一个 CachePolicy指定的 路径解析，如果指定路径是一个文件，那么一个 CachePolicy对应一个 CacheFile; 如果指定路径是一个目录， 那么一个 CachePolicy就解析为多个 CacheFile。 在 CacheMangaer中有两个关于 CacheFile的列表，一个保存着当前全部处于緩存状 态的文件集合， 另一个则保存着本次扫描需要处理的文件集合。 TriggerMonitor 线程读取对象 CachePolicy后会创建一系列的 CacheFile, 通过和之前 history的对 比， 把未出现过的新的 CacheFile同时添加到两个文件集合； 把更新过的 CacheFile (也就是已经被緩存模块记录， 但策略有所改变）在全部緩存文件集 合中更新状态，并由此更新全部相关的 CachedBlock的状态， 同时添加到本次緩 存列表； 将没有任何改动的文件（因为从 CachePolicy读取的是全部路径下的文 件，必然有重复的）忽略掉。另外需要提及的是，在生成緩存文件对象 CacheFile 的时候， 所生成的緩存数据块 CachedBlock—方面添加到了 CacheFile里， 另一 方面也添加到了一个专有的数据集合 waitingPool里面， 这个数据结构专门用来 保存所有需要緩存的数据块， 它实际上是一个优先级队列； 在本实施例中， 认 为緩存份数从 1到 3优先级依次递减， 也就是緩存份数越少， 优先级越高。

步骤 S13 取出表中设定数量个描述并在握手时发给数据节点：在本步骤中， 由于在上述步骤中， TriggerMonitor将緩存路径上的文件全部读出， 并处理 成为 CacheFile和 CachedBlock, 下一步的工作就交由 CacheMonitor处理。 这 个线程的主要作用是将 waitingPool里面的尚未緩存的数据块标记发送添加到 DND里面，等待下次名称节点向数据节点传递命令的时候，将这些块的緩存命 令发送到相应的数据节点。 这个线程（CacheMonitor )会周期性的读取指定个 数（maxCachedNum )的数据块， 调用 DND的添加方法， 添加到其相应的队列 里。 在 DND里面， 每次构建命令发送到相应的数据节点以后， 就从 DND里删 除这些已经发送的块信息， 也就是说， 这些数据块实际上存在于 waitingPool 和 cachedPool, 送入并存储在 DND里面只是标记。 无论数据节点端否成功緩 存这些数据块， DND是不去管理的。

步骤 S14对指定的数据块在其内存中执行緩存： 在本步骤中，在数据节点 中， 通过 heartBeat (握手程序或心跳连接）收到名称节点的命令后， 该数据节 点会扫描本地的 FSDataSet找到对应的块， 在内存中创建其緩存备份。 如果未 找到这个块， 则直接调用创建的 RPC (远程过程调用）方法 reportBadCache() 来告诉名称节点未找到这个块， 名称节点检查緩存份数， 如果只有 1份， 那么 查找该块的其他 DND并继续尝试緩存， 同时调用 HDFS其他原生线程做数据 修复工作； 上述 1份指的是緩存的份数。 而原有 HDFS每个数据块默认是保存 3份的， 每一份都写在不同的 DN磁盘上， 所以对应在 NN里面的 DND有 3 个。 即如果目的是要緩存某个数据块 1次， 而第一次 NN找到一个 DND， 但对 应的 DN无法进行緩存，那么查找该数据块的另外一个 DND，再发送给对应的 DN进行緩存处理， 直到 3个 DND都尝试过， 还没有緩存成功， 则表示该数据 块在緩存系统中已经损坏。

如果 NN收到三份不能緩存一个数据块的报告， 则表示该数据块块彻底损 坏， 则这个数据块所在文件也就损坏了， 那么直接删除之。 如果找到这个块， 磁盘空间不足无法緩存， 那么同样报告给名称节点， 选择该块的下一个 DND 进行尝试； 如果成功緩存， 上报名称节点成功标志， 名称节点修改这个块的状 态及相应管理工作。

步骤 S15 记录执行緩存的情况： 在本步骤中，数据节点釆取如上所述的方 法保存数据块緩存的情况。

步骤 S16再次握手时将执行情况返回： 在本步骤中，数据节点在其与名称 节点再次握手的时候， 将存储的上次握手收到的数据块緩存指令的执行结果发 送回名称节点， 如果一个数据块緩存成功， 则需要判断其所在文件的其他数据 块是否緩存成功。 只有在构成一个文件的所有数据块緩存成功时， 才能确定其 文件緩存成功， 并开始修改该文件的状态； 如果 1个数据块没有緩存成功， 则 需要按照步骤 S14中的方法处理或修复该数据块。

在本实施例中， 数据緩存后还包括将其读出的步骤。 当客户端申请读取文 件时， 其首先向名称节点发送读请求， 名称节点收到这个请求后， 首先检查緩 存列表是否包含此文件， 若包含， 直接对其内部的 CachedBlock[]进行包装， 返 回给客户端一组数据块位置信息 （这一组数据块组成了请求读出的文件）， 这 个过程对客户端是透明的； 如果不存在这个緩存文件， 那么按照正常的数据读 取流程（即现有技术中不使用緩存的 HDFS 系统中读取文件的流程）。 在客户 端获得数据块的具体位置后， 直接向该位置所在的数据节点 DN发送读请求， 要求读取数据。 DN收到请求后， 会检查该数据块是否存在于緩存列表中， 如 果存在， 则直接返回内存文件实现数据读取； 否则调用正常读取流程从磁盘读 取， 整个过程对于客户端同样是透明的。 在本实施例中， 在 NN和 DN端都对緩存数据块进行了描述， 因此需要一 定的机制来保证整个流程顺畅的进行。 在 NN端的核心 CacheMananer中， 包 含了大量的处理 DN端反馈信息的方法， 对于数据块成功緩存、 失败緩存、 内 存不足、 找不到块等都进行了相应的处理。 同时还使用了两个线程， 一个 ClearMonitor用来定时清理过期的緩存文件；一个 HandleMonitor用来定时的检 查一个文件是否緩存成功。 只有当一个文件緩存成功， 才开始对其进行緩存倒 计时； 而判断一个文件是否緩存成功， 依据就是其下属的所有数据块都緩存成 功， 则可以认定这个文件緩存成功。

值得一提的是， 在本实施例中， 上述所有的线程或进程或实现某种功能的 函数或功能模块， 都是通过 HDFS的 API调用或定义的， 因此对于本实施例而 言， 并没有对现有的 HDFS结构做出改变， 相反， 仅仅是在现有 HDFS的基础 上增加了一些功能模块即实现了数据的緩存， 利用了闲置的数据节点的内存， 改善了数据读出的速度。

此外， 在本实施例中， 还涉及一种用于分布式存储系统的数据緩存装置， 其中， 分布式存储系统包括多个用于存储数据的数据节点和与多个数据节点通 过网络连接的并管理这些多个数据节点的名称节点； 如图 4所示， 该装置包括 配置文件解析模块 41、 緩存信息取得模块 42、 緩存信息发送模块 43、 緩存实 现模块 44、 读请求模块 45和緩存查找模块 46; 其中， 配置文件解析模块 41 用于在名称节点上载配置文件到其内存中并解析所述配置文件； 緩存信息取得 模块 42用于得到配置文件中关于緩存的信息， 所述信息包括緩存路径、 緩存 方式、 副本数量以及取消緩存的条件； 緩存信息发送模块 43 用于使名称节点 在与各个数据节点握手时将该数据节点涉及的緩存信息传输给所述数据节点； 緩存实现模块 44用于使所述数据节点取出其涉及的緩存数据并按照其接收到 的緩存信息存储在该数据节点的内存中； 完成数据緩存后， 数据节点在下一次 握手时通知所述名称节点； 读请求模块 45用于使客户端发出读请求到所述名 称节点， 所述名称节点查找其要求的数据是有緩存， 如有， 返回緩存位置到客 户端； 如无， 按照正常的读请求处理； 緩存查找模块 46用于使客户端向数据 节点发送数据读请求， 数据节点在收到所述数据读请求后查找本地緩存列表， 如有， 直接由其内存发送数据给所述客户端； 如无， 读取其磁盘取得数据并发 送给所述客户端， 同时通知所述名称节点緩存异常。

在本实施例中， 上述緩存信息取得模块 42还包括对象取得单元 421、路径 判断单元 422、 元数据形成单元 423、 对象判断单元 424和数据块列表形成单 元 425; 其中， 对象取得单元 421用于取得所述緩存策略文件中的一个对象； 路径判断单元 422用于判断所述对象指向的路径是一个还是一个目录， 如果是 一个文件， 调用元数据形成单元； 如果是一个目录， 将其解析为多个文件后调 用元数据形成单元； 元数据形成单元 423用于构建一个表示所述緩存文件的元 数据， 所述元数据包括文件描述、 文件所包括的所有数据块描述、 緩存份数及 緩存周期； 其中， 所述数据块描述包括其緩存路径、 其所在数据节点在所述名 称节点上的描述、 块序号、 块长度及其数据块状态标志； 对象判断单元 424用 于判断是否处理完所述緩存策略文件中的所有对象； 数据块列表形成单元 425 用于将处理每个所述对象得到的元数据中所有数据块描述中的数据块緩存路 径集合在一起， 得到本次扫描需要緩存数据块列表。

但并不能因此而理解为对本发明专利范围的限制。 应当指出的是， 对于本领域 的普通技术人员来说， 在不脱离本发明构思的前提下， 还可以做出若干变形和 改进， 这些都属于本发明的保护范围。 因此， 本发明专利的保护范围应以所附 权利要求为准。

Claims

权利要求书

1、 一种用于分布式存储系统的数据緩存方法， 所述分布式存储系统包括 多个用于存储数据的数据节点和与所述多个数据节点通过网络连接的并管理 所述多个数据节点的名称节点， 其特征在于， 所述方法包括如下步骤：

A )名称节点上载配置文件到其内存中并解析所述配置文件；

B )得到配置文件中关于緩存的信息， 所述信息包括緩存路径、 緩存 方式、 副本数量以及取消緩存的条件；

C )名称节点在与各个数据节点握手时将该数据节点涉及的緩存信息 传输给所述数据节点；

D ) 所述数据节点取出其涉及的緩存数据并按照其接收到的緩存信息 存储在该数据节点的内存中； 完成数据緩存后， 数据节点在下一次握手时通知 所述名称节点。

2、 根据权利要求 1 所述的用于分布式存储系统的数据緩存方法， 其特征 在于， 还包括如下步骤：

E )客户端发出读请求到所述名称节点， 所述名称节点查找其要求的 数据是有緩存，如有，返回緩存位置到客户端；如无，按照正常的读请求处理；

F )客户端向数据节点发送数据读请求， 数据节点在收到所述数据读 请求后查找本地緩存列表，如有，直接由其内存发送数据给所述客户端；如无， 读取其磁盘取得数据并发送给所述客户端， 同时通知所述名称节点緩存异常。

3、 根据权利要求 2所述的用于分布式存储系统的数据緩存方法， 其特征 在于， 所述配置文件是由客户端定义并传输给所述名称节点的； 所述配置文件 在所述名称节点上被转换为一个緩存策略文件， 所述緩存策略文件中包括多个 表示緩存文件的对象； 所述名称节点通过周期性的扫描线程在每个周期上取得 并替换其内存中的緩存策略文件。

4、 根据权利要求 3所述的用于分布式存储系统的数据緩存方法， 其特征 在于， 所述步骤 B )进一步包括：

B1 )取得所述緩存策略文件中的一个对象；

B2 )判断所述对象指向的路径是一个还是一个目录，如果是一个文件， 执行步骤 B3 ); 如果是一个目录， 将其解析为多个文件后执行步骤 B3 ); B3 )构建一个表示所述緩存文件的元数据，所述元数据包括文件描述、 文件所包括的所有数据块描述、 緩存份数及緩存周期； 其中， 所述数据块描述 包括其緩存路径、 其所在数据节点在所述名称节点上的描述、 块序号、 块长度 及其数据块状态标志；

B4 )重复上述步骤 Bl ) -B3 )直到处理完所述緩存策略文件中的所有 对象。

5、 根据权利要求 4所述的用于分布式存储系统的数据緩存方法， 其特征 在于， 所述步骤 B ) 中还包括如下步骤：

将处理每个所述对象得到的元数据中所有数据块描述中的数据块緩存 路径集合在一起， 得到本次扫描需要緩存数据块列表。

6、 根据权利要求 5所述的用于分布式存储系统的数据緩存方法， 其特征 在于， 所述步骤 C ) 中进一步包括：

C1 )有所述本次扫描需要緩存数据块列表中取出设定个数的数据块緩 存路径；

C2 )按照所述緩存路径指向的数据节点， 在与该数据节点握手时将所 述数据块緩存路径发送到该数据节点。

7、 根据权利要求 6所述的用于分布式存储系统的数据緩存方法， 其特征 在于， 所述步骤 D )进一步包括：

D1 )取得本次握手时得到的所有数据块緩存路径， 并依次按照每个数 据块緩存路径读取该数据块， 并将其在该数据节点的内存中緩存； 如未找到数 据块或内存空间有限不能緩存， 则标记该数据块緩存失败并处理下一个数据块 緩存路径；

D2 )在下一次握手时返回所述名称节点所有数据块的緩存结果。

8、 一种用于分布式存储系统的数据緩存装置， 所述分布式存储系统包括 多个用于存储数据的数据节点和与所述多个数据节点通过网络连接的并管理 所述多个数据节点的名称节点， 其特征在于， 所述装置包括：

配置文件解析模块： 用于在名称节点上载配置文件到其内存中并解析 所述配置文件；

緩存信息取得模块： 用于得到配置文件中关于緩存的信息， 所述信息 包括緩存路径、 緩存方式、 副本数量以及取消緩存的条件；

緩存信息发送模块： 用于使名称节点在与各个数据节点握手时将该数 据节点涉及的緩存信息传输给所述数据节点；

緩存实现模块： 用于使所述数据节点取出其涉及的緩存数据并按照其 接收到的緩存信息存储在该数据节点的内存中； 完成数据緩存后， 数据节点在 下一次握手时通知所述名称节点。

9、 根据权利要求 8所述的装置， 其特征在于， 还包括：

读请求模块： 用于使客户端发出读请求到所述名称节点， 所述名称节 点查找其要求的数据是有緩存， 如有， 返回緩存位置到客户端； 如无， 按照正 常的读请求处理；

緩存查找模块： 用于使客户端向数据节点发送数据读请求， 数据节点 在收到所述数据读请求后查找本地緩存列表， 如有， 直接由其内存发送数据给 所述客户端； 如无， 读取其磁盘取得数据并发送给所述客户端， 同时通知所述 名称节点緩存异常。

10、 根据权利要求 8所述的装置， 其特征在于， 所述緩存信息取得模块还 包括：

对象取得单元： 用于取得所述緩存策略文件中的一个对象；

路径判断单元： 用于判断所述对象指向的路径是一个还是一个目录， 如果是一个文件， 调用元数据形成单元； 如果是一个目录， 将其解析为多个文 件后调用元数据形成单元；

元数据形成单元： 用于构建一个表示所述緩存文件的元数据， 所述元 数据包括文件描述、 文件所包括的所有数据块描述、 緩存份数及緩存周期； 其 中， 所述数据块描述包括其緩存路径、 其所在数据节点在所述名称节点上的描 述、 块序号、 块长度及其数据块状态标志；

对象判断单元： 用于判断是否处理完所述緩存策略文件中的所有对象； 数据块列表形成单元： 用于将处理每个所述对象得到的元数据中所有数据 块描述中的数据块緩存路径集合在一起， 得到本次扫描需要緩存数据块列表。