CN115328857A - 文件访问方法、装置、客户端及存储介质 - Google Patents

Abstract

本发明涉及分布式文件技术领域，提供了一种文件访问方法、装置、客户端及存储介质，所述方法包括：接收应用端发送用于访问待访问文件的文件访问请求；若文件访问请求包括文件标识，则向NFS服务端组件发送文件标识，以通过NFS服务端组件根据文件标识从存储节点访问待访问文件，文件标识包括待访问文件的文件名及文件存储地址；若文件访问请求不包括文件标识但包括文件名，则根据文件名获取文件存储地址，以通过NFS服务端组件根据文件存储地址从存储节点访问待访问文件；向应用端响应文件访问请求。本实施例有效地降低了文件访问时延，提高了文件访问性能。

Description

文件访问方法、装置、客户端及存储介质

技术领域

本发明涉及分布式文件技术领域，具体而言，涉及一种文件访问方法、装置、客户端及存储介质。

背景技术

在海量小文件存储应用领域，通常要求高吞吐量，低时延，且要求在百亿量级小文件下，仍能提供理想的访问性能，现有技术通常通过缓存热点目录/文件元数据，以提高元数据的访问性能，最终提高分布式文件系统整体的访问性能。

网络文件系统NFS(Network File System，NFS)是文件系统之上的一个网络抽象，允许远程客户端以与本地文件系统类似的方式，通过网络进行访问。现有技术的实现方式在NFS随机访问应用场景，目录/文件元数据的缓存命中率极其低下，最终导致文件访问性能下降。

发明内容

本发明的目的在于提供了一种文件访问方法、装置、客户端及存储介质，其能够提高文件访问的性能。

为了实现上述目的，本发明实施例采用的技术方案如下：

第一方面，本发明实施例提供一种文件访问方法，应用于网络文件系统NFS客户端，所述NFS客户端与应用端及分布式文件系统中的存储节点均通信连接，所述存储节点运行有NFS服务端组件，所述方法包括：

接收所述应用端发送用于访问待访问文件的文件访问请求；

若所述文件访问请求包括文件标识，则向所述NFS服务端组件发送所述文件标识，以通过所述NFS服务端组件根据所述文件标识从所述存储节点访问所述待访问文件，所述文件标识包括所述待访问文件的文件名及文件存储地址；

若所述文件访问请求不包括所述文件标识但包括文件名，则根据所述文件名获取所述文件存储地址，以通过所述NFS服务端组件根据所述文件存储地址从所述存储节点访问所述待访问文件；

向所述应用端响应所述文件访问请求。

可选地，所述存储节点还运行有元数据管理组件，所述根据所述文件名获取所述文件存储地址的步骤包括：

若所述NFS客户端存储有与所述文件名对应的文件标识，则从所述文件标识中获取所述文件存储地址；

若所述NFS客户端未存储有与所述文件名对应的文件标识，则根据所述文件名向所述元数据管理组件查询所述文件存储地址。

可选地，所述方法还包括：

根据所述文件名及所述文件存储地址生成所述文件标识；

将所述文件标识进行存储。

可选地，所述方法还包括：

向所述NFS服务端组件发送获取待查询目录的目录列表请求，以使所述NFS服务端组件基于所述目录列表请求返回所述待查询目录的目录列表，所述待查询目录的目录列表包括所述待查询目录下的待查询文件名及待查询文件存储地址；

根据所述待查询文件名及所述待查询文件存储地址，生成待查询文件标识；

将所述待查询文件标识进行存储。

可选地，所述将所述待查询文件标识进行存储的步骤包括：

从预先存储的目录树中找到与所述待查询文件标识对应的目标文件节点，所述目录树包括按照目录层次结构组织的目录节点和文件节点，每一目录节点表征一个目录，每一文件节点表征一个文件；

将所述待查询文件标识作为所述文件节点对应的文件的访问元数据，所述文件节点对应的文件的访问元数据表征访问所述文件节点对应的文件的文件名和文件存储地址。

可选地，所述方法还包括：

基于所述NFS服务端组件返回的操作待操作文件成功的响应请求，向所述NFS服务端组件发送针对所述待操作文件的文件状态获取请求，以使所述NFS服务端组件返回所述待操作文件的文件状态，所述待操作文件的文件状态包括待操作文件名及待操作文件存储地址；

根据所述待操作文件名及所述待操作文件存储地址，生成待操作文件标识；

将所述待操作文件标识进行存储。

可选地，所述将所述待操作文件标识进行存储的步骤包括：

将所述待操作文件名替换为所述待操作文件标识；

将所述待操作文件标识作为所述待操作文件的访问元数据进行存储，所述待操作文件的访问元数据表征访问所述待操作文件的文件名和文件存储地址。

第二方面，本发明实施例提供一种数据访问装置，应用于网络文件系统NFS客户端，所述NFS客户端与应用端及分布式文件系统中的存储节点均通信连接，所述存储节点运行有NFS服务端组件，所述装置包括：

接收模块，用于接收所述应用端发送用于访问待访问文件的文件访问请求；

访问模块，用于若所述文件访问请求包括文件标识，则向所述NFS服务端组件发送所述文件标识，以通过所述NFS服务端组件根据所述文件标识从所述存储节点访问所述待访问文件，所述文件标识包括所述待访问文件的文件名及文件存储地址；

访问模块，还用于若所述文件访问请求不包括所述文件标识但包括文件名，则根据所述文件名获取所述文件存储地址，以通过所述NFS服务端组件根据所述文件存储地址从所述存储节点访问所述待访问文件；

响应模块，用于向所述应用端响应所述文件访问请求。

第三方面，本发明实施例提供一种客户端，包括处理器和存储器，所述存储器用于存储程序，所述处理器用于在执行所述程序时，实现如上述第一方面所述的文件访问方法。

第四方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述第一方面所述的文件访问方法。

本发明实施例的有益效果包括，当应用端需要访问待访问文件时，向NFS客户端发送文件访问请求，若文件访问请求包括文件标识，文件标识包括待访问文件的文件名及文件存储地址，则通过NFS服务端组件根据文件标识从存储节点访问待访问文件，若文件访问请求不包括文件标识但是包括文件名，则根据文件名获取文件存储地址，通过NFS服务端组件根据文件存储地址从存储节点访问待访问文件，通过NFS客户端缓存待访问文件的文件标识，文件标识中包括文件存储地址，使得NFS客户端访问待访问文件时，NFS服务端组件无需访问文件元数据就可以直接从存储节点访问待访问文件，有效地降低文件访问时延，提高了文件访问性能。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明实施例提供的应用场景的示例图。

图2为本发明实施例提供的客户端的方框示意图。

图3为本发明实施例提供的分布式文件逻辑架构的示例图。

图4为本发明实施例提供的文件访问方法的流程示意图一。

图5为本发明实施例提供的目录树的示例图。

图6为本发明实施例提供的根据文件名进行文件访问的交互示例图。

图7为本发明实施例提供的根据文件标识进行文件访问的交互示例图。

图8为本发明实施例提供的一种文件访问装置的方框示意图。

图标：10-客户端；11-处理器；12-存储器；13-总线；14-通信接口；20-存储节点；30-应用端；100-文件访问装置；110-接收模块；120-访问模块；130-响应模块；140-存储模块。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本发明的描述中，需要说明的是，若出现术语“上”、“下”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

此外，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在不冲突的情况下，本发明的实施例中的特征可以相互结合。

请参考图1，图1为本发明实施例提供的应用场景的示例图，图1中，分布式文件系统包括多个存储节点20，多个存储节点20之间相互通信，分布式文件系统对外统一提供一个公共IP以对外提供存储服务，应用端30通过客户端10访问公共IP访问分布式文件系统中目录或者文件，客户端10上部署有Nfs-Client组件，也称为NFS客户端，各存储节点20上部署有Nfs-Server组件，也称为NFS服务端组件，应用端30将文件访问请求发送客户端10，客户端10上的Nfs-Client组件负责与Nfs-Server服务端组件进行交互，以便进行文件访问。此外，存储节点20还部署有元数据管理组件，用于管理目标/文件的元数据，例如，将目标/文件的元数据分布式存储于各存储节点20，或者从存储节点20读取指定目标/文件的元数据，Nfs-Server服务端可以通过与元数据管理组件进行交互，以获取指定目录/文件的元数据，需要说明的是，元数据管理组件可以部署在一个或者多个存储节点20上。

基于图1的应用场景，通常情况下会在存储节点20上设置缓存，并设置最近最少使用LRU(Least Recently Used，LRU)算法以缓存热点目录/文件元数据，应用端30访问文件时，由客户端10通过NFS客户端和NFS服务端组件进行交互，由NFS服务端组件读取文件的元数据，再根据文件的元数据访问存储节点20中的文件，这种方式，一方面，在文件随机访问应用场景中，缓存命中效率极其低下，无法有效提高元数据访问效率，最终使得文件访问效率也不理想，另一方面，文件访问时，需要逐层级向元数据服务器请求目录解析、获取文件元数据，访问时延较高，尤其是在高并发的场景，严重影响系统性能。

有鉴于此，本申请实施例提供一种文件访问方法、装置、客户端及存储介质，NFS客户端根据文件标识或者文件名，无需通过访问文件元数据即可直接访问文件，有效地降低了文件访问时延，下面将对其进行详细描述。

在图1的基础上，本发明实施例还提供了图1中客户端10的方框示意图，请参照图2，图2为本发明实施例提供的客户端10的方框示意图，客户端10可以是实体计算机或者能够实现与实体计算机具有相同功能的虚拟机。客户端10包括存储器11、处理器12、总线13、通信接口14。存储器11、处理器12通过总线13连接，处理器12通过通信接口14与其他的存储节点20或者应用端30通信连接。

存储器11用于存储程序，例如本实施例中的文件访问装置，该文件访问装置包括至少一个可以软件或固件(firmware)的形式存储于存储器11中的软件功能模块，处理器12在接收到执行指令后，执行所述程序以实现上述实施例揭示的文件访问方法。

存储器11可能包括高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非易失存储器(non-volatile memory)，例如至少一个磁盘存储器。可选地，存储器11可以是内置于处理器12中的存储装置，也可以是独立于处理器12的存储装置。

总线13可以是ISA总线、PCI总线或EISA总线等。图2仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器12可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器12中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器12可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

通过至少一个通信接口14(可以是有线或者无线)实现客户端10与存储节点20、以及应用端30之间的通信连接。

首先介绍本实施例提供的应用于图1的应用场景的分布式文件系统的逻辑架构图，请参照图3，图3为本发明实施例提供的分布式文件系统的逻辑架构的示例图，图3中，分布式文件系统(本实施例称之为MinFS)中每个存储节点均包括SSD和机械硬盘至少两种存储介质，分布式文件系统向客户端10提供网络文件系统NFS(Network File System，NFS)和用户态空间FUSE(Filesystem in Userspace，FUSE)两种访问方式，每一存储节点至少提供Metadata Server服务和Data Server服务两种服务，元数据通过Metadata Server服务存储至存储节点20的SSD、通过Data Server服务存储至存储节点20的机械硬盘。图3的逻辑架构中，包括以下主要组件：

1)Clients(客户端10)，MinFS提供一个全局统一命名空间，支持通过LibMinFS、NFS和用户控件文件系统FUSE(Filesystem in Userspace，FUSE)方式访问，LibMinFS性能远优于NFS、FUSE，支持直接访问，无路径解析开销。Clients配置Client-aware缓存属性，Clients可以目录树层级结构在线管理文件的Access Metadata元数据缓存，或者以离线方式持久化保存文件的Access Metadata元数据。利用文件Access Metadata缓存，可实现避开访问元数据服务器直接访问文件，有效降低文件访问时延。

2)Metadata Servers，维护一个扁平化的命名空间，按照目录对目录/文件元数据对象进行分组，根据目录id将元数据对象组哈希分区到不同的存储节点上的MetaServer，保证元数据访问局部性和均衡性。每个MetaServer后端采用KV Stor持久化引擎，如：RocksDB，以Key-Value Pairs间接方式，或者是以Key直接方式存储管理目录和文件元数据。通常，采用高性能存储介质，如：SSD/NVMe SSD，以提供高效元数据访问性能。

3)Data Servers，统一分布式文件存储，后端存储介质通常为HDD，采用纠删冗余策略，提供高可靠数据服务。以聚合方式保存海量小文件数据，以提高存储空间利用效率。以WAL方式保存目录列表，以降低大目录获取目标列表的操作时延。

基于该逻辑架构，本实施例还提供了一种具体的对元数据进行管理的方式，主要包括对元数据的拆分解耦和元数据的存储。

1)元数据拆分解耦

通常，标准文件系统，如：EXT4/XFS/Cephfs等，目录/文件inode占用数百字节，包括：name(名称)、id(标识)、permission(访问权限)、user(所属用户)、timestamp(修改时间)、entry list(目录列表)、file location(文件的存储位置)等。事实上，目录/文件inode信息可分解为多个相互独立的部分。

①对于目录inode，可分解为三部分：目录访问元数据Access Metadata(目录名称name，目录标识id，目录权限permission，目录所属用户user等)，用于描述目录本身属性；目录列表元数据Entrylist和目标内容元数据Content Metadata(日志索引logidx，文件索引fileidx，目录容量capacity，目录时间戳timestamp等)，与目录包括的子目录或者文件相关。

②对于文件inode，可分解为两部分：文件访问Access Metadata(文件名称name，文件存储位置location)，用于描述与用户文件数据相关；扩展属性Extended Attributes(文件权限permission，文件所属用户user，文件时间戳timestamp等)，用于描述文件扩展属性。

表1为对于目录和文件元数据进行分类的示例。

表1

表1中，KVS为key-value的存储方式，Dlog为日志的存储方式，目标元数据中的pid表示该目录的父目录，文件元数据中的pid表示该文件的父目录，SSD pool为由存储节点20中的SSD盘组成的SSD存储池，HDD pool为由存储节点20的HDD盘组成的HDD存储池，NFS客户端缓存可以NFS客户端的内存或者非易失性存储介质。

发明人通过研究发现，在海量小文件存储应用场景，用户通常更加关心文件数据及访问时延，很少单独针对某个文件设置Extended Attributes，更倾向于以目录聚类方式统一设置管理。因此，可以采用文件Extended Attributes与其父目录Access Metadata合并的方式，简化元数据服务管理。另外，不同目录/文件的元数据对象访问局部性不同，比如：读取目录操作只需要访问目录Content Metadata对象，获取文件属性操作需要访问父目录的Content Metadata对象和文件Access Metadata，因此，可以按照目录将目录的Content Metadata对象与其子目录/文件的Access Metadata对象分为一组，并以目录id进行哈希分区。

2)元数据on-disk格式

①目录Access Metadata，以Key-Value Pairs方式保存在MetaServers中。Key为<pid，name>，Value为{id，permission，user，timestamp等}，其中，pid为父目录id，占4bytes，”/”目录id为0。根据pid哈希分区，将元数据对象均衡到不同MetaServer管理。

②目录Content Metadata，以Key-Value Pairs方式保存在MetaServers中。Key为<id>，Value为{logidx，fileidx，capacity，etc.}，其中logidx、fileidx分别表示目录EntryList、聚合文件在DataServers中的存储位置信息，fileidx用于支持一键删除目录文件数据操作。根据id哈希分区到不同MetaServers管理，保证元数据访问局部性，可以通过目录id前缀迭代方式，获取目录EntryList。目录重命名rename操作，不影响目录id，只需要更新目录Access Metadata的Key即可，保证其后裔元数据不受影响。

③目录EntryList，以WAL方式保存在DataServers中，格式为{<name1，location><name2，location><name>，…}。对于大目录，id前缀迭代方式比较耗费CPU和IO资源，且耗时较长。可以在文件数超过阈值(如：1000)时，通过后台前缀迭代方式，一次性生成目录EntryList的预写日志WAL(Write-Ahead Logging，WAL)文件，后续以追加写方式更新，比如：文件创建create操作，追加记录<name，location>；文件删除delete操作，追加记录<name>；获取目录列表readdir操作，通过logidx直接从DataServers中读取目录EntryList。

④文件Access Metadata，以Key方式保存在MetaServers中，Key格式为<pid，name？location>。小文件数据以聚合成大文件方式保存在DataServers中，location表示其存储位置信息，具体格式表示为：Fileid-Len-Offset，其中Fileid为DataServers中聚合文件的唯一索引标识，Len为小文件数据长度，Fileid+Len共占用8bytes，Offset为小文件在聚合文件内偏移，占用4Bytes。根据pid哈希分区到不同MetaServers管理，保证元数据访问局部性，比如：文件创建create/删除delete操作，涉及父目录Content Metadata和文件Access Metadata，可以MetaServer本地事务方式完成，避免分布式事务开销。

⑤文件Extended Attributes，与目录Access Metadata合并保存。获取文件属性stat操作，通过组合父目录Access Metadata和文件Access Metadata，生成文件状态属性。

上述只是一种元数据的管理的实现方式，事实上也可以采用其他的元数据的管理方式，本实施例主要是对基于已经实现的元数据的管理方式提供一种通过对文件元数据进行缓存，以提高文件访问效率的实现方式。

当前常用的元数据缓存方式，主要是在NFS服务端或者是存储元数据的存储节点上对热点元数据进行缓存，采用的热点感知算法主要分两类：一是依据访问频率进行预热，如：LRU等；二是深度学习业务语义逻辑，进行预测预热。在安防海量小文件存储应用场景，同个文件短时间内被连续多次访问的概率接近于零，诸如LRU等传统访问预热算法，存在缓存空间需求高、命中率低的问题。而深度学习预测预热算法，需要AI芯片特殊硬件加持，且在多种类型业务负载场景下，容易出现预测失效的问题。

发明人基于对上述预热算法中的问题的根因进行了仔细分析和研究，提出一种由客户端根据自身业务负载特性，自治管理维护文件元数据缓存，即缓存即用，能够达到缓存空间需求低、命中率高的优势。

本实施例中的缓存具有以下两种方式：

①在线Online缓存，Client按需调用获取目录列表readdir，以获取目录信息，按照目录树层级结构管理目录列表EntryList，可以参照图3中的Client-aware Cache的目录树的示例，其中的圆形表示目录，方形表示文件，按照目录和文件之间的层级关系以树状结构维护文件元数据缓存。文件访问时，在Client即可完成文件名Name与文件存储地址Location转换，实现无需访问元数据服务MetaServer即可直接访问文件。该缓存方式适用于以目录聚类方式，顺序访问该目录下文件的应用场景。

②离线Offline缓存，Client自身需要永久保存文件全路径名，可通过以创建文件create/写文件write/关闭文件close操作，完成文件创建写入后，立即调用获取文件属性stat操作将文件名Name替换为Name？Location格式。文件访问时，直接通过Name？Location格式文件名访问文件，实现无需访问元数据服务MetaServer即可直接访问文件。该缓存方式适用于单文件随机访问的应用场景。

作为一种具体实现方式，本实施例以第一级子目录作为共享子目录树ShareSubtree，例如：根目录下的A目录，/A，若采用本实施例提供的上述缓存方式，针对该/A下所有目录的获取目录列表readdir操作，将返回Name？Location格式的目标列表Entry List，且针对该/A下所有文件的访问，NFS服务端或者是存储元数据的存储节点不再进行缓存，由Client自行管理。

基于图3的逻辑架构及上述缓存方式，本实施例还提了一种文件访问方法，请参照图4，图4为本发明实施例提供的文件访问方法的流程示意图一，该方法包括以下步骤：

步骤S100，接收应用端发送用于访问待访问文件的文件访问请求。

在本实施例中，应用端可以只获取到待访问文件的文件名，也可以获取到待访问文件的文件标识，因此，文件访问请求中可以包括文件名，也可以包括文件标识，文件标识包括符合预设格式的文件名和文件存储地址，例如，文件标识为：文件名？文件存储地址。

步骤S101，若文件访问请求包括文件标识，则向NFS服务端组件发送文件标识，以通过NFS服务端组件根据文件标识从存储节点访问待访问文件，文件标识包括待访问文件的文件名及文件存储地址。

在本实施例中，由于文件标识符合预设格式，因此，NFS客户端(即上文中的Client)可以根据预设格式判断文件访问请求中是否包括文件标识，若包括文件标识，NFS客户端向NFS服务端组件发送该文件标识，NFS服务端组件对文件标识进行解析，得到文件标识中的文件存储地址，再根据文件存储地址直接从存储节点10访问文件并返回NFS客户端。

步骤S102，若文件访问请求不包括文件标识但包括文件名，则根据文件名获取文件存储地址，以通过NFS服务端组件根据文件存储地址从存储节点访问待访问文件。

在本实施例中，若文件访问请求不包括文件标识但包括文件名，NFS客户端可以首先根据文件名判断本地是否存储有与文件名对应的文件存储地址，若有，则将文件名转换为文件存储地址，将文件存储地址发送至NFS服务端组件，由NFS服务端组件根据文件存储地址直接从存储节点10访问文件并返回NFS客户端。若没有，再由NFS服务端组件通过元数据管理组件访问文件元数据，获取文件存储地址，再由NFS服务端组件根据文件存储地址直接从存储节点10访问文件并返回NFS客户端。

步骤S103，向应用端响应文件访问请求。

本实施例提供的上述方法，文件标识中包括文件名和文件存储地址，采用直接映射，以key方式直接关联文件名和文件存储地址，有效优化元数据缓存空间，由NFS客户端缓存文件标识，NFS客户端可以根据自身业务负载特性，自治管理维护文件的元数据，有效提升缓存命中效率，有效降低文件访问时延。

在本实施例中，NFS客户端获取文件存储地址的方式至少有两种，具体为：

若NFS客户端存储有与文件名对应的文件标识，则从文件标识中获取文件存储地址。

若NFS客户端未存储有与文件名对应的文件标识，则根据文件名向元数据管理组件查询文件存储地址。

在本实施例中，NFS客户端向NFS服务端组件发送文件名，NFS服务端组件根据文件名通过元数据管理组件访问与文件名对应的文件元数据，从文件元数据中获取到文件名对应的文件存储地址，再将文件存储地址返回给NFS客户端。

本实施例提供的上述方法，当NFS客户端存储有与文件名对应的文件标识时，不再需要逐层级向元数据管理组件请求目录解析、获取文件元数据，得到文件存储地址，由于省略了目录解析访问，可以根据文件标识直接文件数据，实现零负载，极大地优化文件访问时延和吞吐量，尤其是对于小文件，效果更加明显。

在本实施例中，为了使后续再对待访问文件进行访问时，NFS客户端可以直接获取到文件标识，本实施例还提供了一种生成并存储文件标识的实现方式，具体为：

首先，根据文件名及文件存储地址生成文件标识。

在本实施例中，按照预设格式，根据文件名及文件存储地址生成文件标识。

其次，将文件标识进行存储。

在本实施例中，对文件标识进行存储的方式至少包括两种：一种是缓存在NFS客户端的易失性存储介质，例如，内存，一种是存储至NFS客户端的非易失性存储介质，例如，硬盘。

在本实施例中，NFS客户端至少在两种场景下可以主动将文件标识进行存储，以提高后续访问文件时文件标识的命中率，进而可以加快文件访问效率，下面将对两种场景分别介绍。

场景一：

首先，向NFS服务端组件发送获取待查询目录的目录列表请求，以使NFS服务端组件基于目录列表请求返回待查询目录的目录列表，待查询目录的目录列表包括待查询目录下的待查询文件名及待查询文件存储地址。

在本实施例中，获取待查询目录的目录列表请求可以是由应用端直接触发的，即应用端需要获取待查询目录的目录列表，也可以是NFS客户端根据需要自行触发的。

其次，根据待查询文件名及待查询文件存储地址，生成待查询文件标识。

在本实施例中，按照预设格式，根据待查询文件名及待查询文件存储地址生成待查询文件标识。

最后，将待查询文件标识进行存储。

在本实施例中，作为一种具体方式，将待查询文件标识进行存储的过程可以是：

首先，从预先存储的目录树中找到与待查询文件标识对应的目标文件节点，目录树包括按照目录层次结构组织的目录节点和文件节点，每一目录节点表征一个目录，每一文件节点表征一个文件。

在本实施例中，为了更清楚地说明目录树，请参照图5，图5为本发明实施例提供的目录树的示例图，图5中，/A目录包括A1子目录和A2子目录，A1子目录下有一个文件a.txt，A2子目录下有两个文件b1.txt和b2.txt，由图5可以看出，目录树的层次结构和/A的层次结构是一致的，由此可以更方便地根据文件的全路径从目录树中找到对应的待查询文件，进而找到对应的待查询文件标识。

其次，将待查询文件标识作为文件节点对应的文件的访问元数据，文件节点对应的文件的访问元数据表征访问文件节点对应的文件的文件名和文件存储地址。

在本实施例中，作为一种具体实施方式，每一个文件节点可以对应一个访问元数据的数据结构，以将该文件节点对应的文件的文件名和文件存储地址存储至访问元数据的数据结构。

场景二：

首先，基于NFS服务端组件返回的操作待操作文件成功的响应请求，向NFS服务端组件发送针对待操作文件的文件状态获取请求，以使NFS服务端组件返回待操作文件的文件状态，待操作文件的文件状态包括待操作文件名及待操作文件存储地址。

在本实施例中，操作待操作文件可以是创建文件、关闭文件等，由于文件被操作后，对文件进行访问的可能性比较大，为了提高后续访问文件时文件标识的命中率，进而可以加快文件访问效率，可以在文件操作完毕后，由NFS客户端触发一次获取待操作文件的访问元数据的，得到待操作文件名及待操作文件存储地址，进而得到待操作文件标识并将其进行存储。

其次，根据待操作文件名及待操作文件存储地址，生成待操作文件标识。

在本实施例中，按照预设格式，根据待操作文件名及待操作文件存储地址，生成待操作文件标识。

最后，将待操作文件标识进行存储。

在本实施例中，作为一种具体方式，将待查询文件标识进行存储的过程可以是：

首先，将待操作文件名替换为待操作文件标识。

其次，将待操作文件标识作为待操作文件的访问元数据进行存储，待操作文件的访问元数据表征访问待操作文件的文件名和文件存储地址。

作为一种较优选择，上述场景一更适合顺序访问指定目录下的文件的应用场景，上述场景二更适合随机访问单个文件的应用场景，当然，这是一种较优选择，并不代表场景一必须限定顺序访问指定目录下的文件的应用场景，场景二必须限定随机访问单个文件的应用场景。

为了更清楚地说明根据文件名和根据文件标识两种文件访问的具体过程，本实施例还提供了两种访问方式的交互示例图，请参照图6，图6为本发明实施例提供的根据文件名进行文件访问的交互示例图，这种方式也称为解析访问，需要读的文件是/A/B/File，NFS-Client得到的是文件名/A/B/File，具体访问步骤如下：

S10：NFS-Client(即NFS客户端)请求NFS-Server(即NFS服务端组件)查找目录A和目录B；

S11：NFS-server根据Key<0，A>和<1，B>(“/”目录id为0，“A”目录id为1，“B”目录id为2)哈希计算所在的MetaServer，比如：分别为MetaServerA、MetaServerB，分别向MetaServerA、MetaServerB查询是否存在对应记录。通常，NFS-server会缓存最近访问的目录元数据，若缓存，则NFS-server无需访问MetaServer，若未缓存，才需要访问MetaServer；图6虚线S11所示的需要访问MetaServer的情况。

S12：若目录A和目录B均存在，NFS-server向NFS-Client响应OK；

S13：NFS-Client向NFS-Server请求打开文件名为File的文件；

S14：NFS-Server根据Key<2，File>哈希计算文件File所在的MetaServer，比如：MetaServer A，向MetaServer A查询是否存在对应记录。由于文件数量巨大，通常NFS-server无法缓存所有的文件元数据；

S15：文件File存在，NFS-server向NFS-Client响应OK，会返回/A/B/File的文件标识fh；

S16：NFS-Client请求读文件File，read(fh，buf，size)，buf为缓存读取的文件File的数据，size为欲读取的数据的大小；

S17：NFS-server根据Key<2，File>哈希计算文件File所在的MetaServer，比如：MetaServer A，向MetaServer A查询文件File的location信息(即文件存储地址)。

S18：NFS-server根据location信息，向DataServer请求读取文件File的数据；

S19：NFS-server向NFS-Client响应读文件File请求。

需要说明的是，NFS-Server用于处理NFS协议，文件服务相关逻辑，通常，NFS-Server缓存最近访问的目录元数据，加速目录解析，首次访问时需要从MetaServer加载，若文件数据量巨大，NFS-Server无法缓存文件inode，需要从MetaServer加载，上述访问方式，文件名不携带location信息，NFS-Server若未缓存location信息，name需要查询MetaServer转换name->location，再根据location读取文件数据，NFS-Server若缓存有location信息，可以直接根据location读取文件数据。

请参照图7，图7为本发明实施例提供的根据文件标识进行文件访问的交互示例图，这种访问方式也称为直接访问，需要读的文件是/A/B/File，NFS-client得到的是文件标识/A/B/File？location，具体访问步骤如下：

S20：NFS-Client请求NFS-Server查找目录A和目录B；

S21：NFS-server根据Key<0，A>和<1，B>(“/”目录id为0，“A”目录id为1，“B”目录id为2)哈希计算所在的MetaServer，比如：分别为MetaServerA、MetaServerB，分别向MetaServerA、MetaServerB查询是否存在对应记录。通常，NFS-server会缓存最近访问的目录元数据，若缓存，则NFS-server无需访问MetaServer，若未缓存，才需要访问MetaServer，图7中S21所示是不需要访问MetaServer的情况；

S22：若目录A和目录B均存在，NFS-server向NFS-Client响应OK；

S23：NFS-client请求open文件File？location；

S24：NFS-server根据文件名称格式File？location，可直接判断文件存在，无需查询MetaServer；

S24：文件File存在，NFS-server向NFS-Client响应OK；

S25：直接向DataServer请求读取文件File的数据；

S26：NFS-server向NFS-Client响应读文件File请求。

需要说明的是，NFS-server根据name？location格式，判断文件存在，无需经过MetaServer判断文件是否存在，NFS-server直接从name？location中提取location信息，实现绕过MetaServer，直接访问文件数据。

为了执行上述实施例及各个可能的实施方式中的相应步骤，下面给出一种文件访问装置的实现方式。请参照图8，图8为本发明所提供的文件访问装置100的功能模块示意图。需要说明的是，本发明实施例所述的文件访问装置100，其基本原理及产生的技术效果与前述方法实施例相同，为简要描述，本实施例中未提及部分，可参考前述方法实施例的相应内容。该文件访问装置100应用于客户端10，文件访问装置100包括：接收模块110、访问模块120、响应模块130及存储模块140。

接收模块110，用于接收应用端发送用于访问待访问文件的文件访问请求。

访问模块120，用于若文件访问请求包括文件标识，则向NFS服务端组件发送文件标识，以通过NFS服务端组件根据文件标识从存储节点访问待访问文件，文件标识包括待访问文件的文件名及文件存储地址。

访问模块120，还用于若文件访问请求不包括文件标识但包括文件名，则根据文件名获取文件存储地址，以通过NFS服务端组件根据文件存储地址从存储节点访问待访问文件。

响应模块130，用于向应用端响应文件访问请求。

可选地，存储节点还运行有元数据管理组件，访问模块120具体用于：若NFS客户端存储有与文件名对应的文件标识，则从文件标识中获取文件存储地址；若NFS客户端未存储有与文件名对应的文件标识，则根据文件名向元数据管理组件查询文件存储地址。

可选地，存储模块140用于：根据文件名及文件存储地址生成文件标识；将文件标识进行存储。

可选地，存储模块140还用于：向NFS服务端组件发送获取待查询目录的目录列表请求，以使NFS服务端组件基于录列表请求返回所待查询目录的目录列表，待查询目录的目录列表包括待查询目录下的待查询文件名及待查询文件存储地址；根据待查询文件名及待查询文件存储地址，生成待查询文件标识；将待查询文件标识进行存储。

可选地，存储模块140具体用于：从预先存储的目录树中找到与待查询文件标识对应的目标文件节点，目录树包括按照目录层次结构组织的目录节点和文件节点，每一目录节点表征一个目录，每一文件节点表征一个文件；将待查询文件标识作为文件节点对应的文件的访问元数据，文件节点对应的文件的访问元数据表征访问文件节点对应的文件的文件名和文件存储地址。

可选地，存储模块140还用于：基于NFS服务端组件返回的操作待操作文件成功的响应请求，向NFS服务端组件发送针对待操作文件的文件状态获取请求，以使NFS服务端组件返回待操作文件的文件状态，待操作文件的文件状态包括待操作文件名及待操作文件存储地址；根据待操作文件名及待操作文件存储地址，生成待操作文件标识；将待操作文件标识进行存储。

可选地，存储模块140具体用于：将待操作文件名替换为待操作文件标识；将待操作文件标识作为待操作文件的访问元数据进行存储，待操作文件的访问元数据表征访问待操作文件的文件名和文件存储地址。

本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述所述的文件访问方法。

综上所述，本发明实施例提供了一种文件访问方法、装置、客户端及存储介质，应用于网络文件系统NFS客户端，NFS客户端与应用端及分布式文件系统中的存储节点均通信连接，存储节点运行有NFS服务端组件，所述方法包括：接收应用端发送用于访问待访问文件的文件访问请求；若文件访问请求包括文件标识，则向NFS服务端组件发送文件标识，以通过NFS服务端组件根据文件标识从存储节点访问待访问文件，文件标识包括待访问文件的文件名及文件存储地址；若文件访问请求不包括文件标识但包括文件名，则根据文件名获取文件存储地址，以通过NFS服务端组件根据文件存储地址从存储节点访问待访问文件；向应用端响应文件访问请求。通过NFS客户端缓存待访问文件的文件标识，文件标识中包括文件存储地址，使得NFS客户端访问待访问文件时，NFS服务端组件无需访问文件元数据就可以直接从存储节点访问待访问文件，有效地降低文件访问时延，提高了文件访问性能。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种文件访问方法，其特征在于，应用于网络文件系统NFS客户端，所述NFS客户端与应用端及分布式文件系统中的存储节点均通信连接，所述存储节点运行有NFS服务端组件，所述方法包括：

接收所述应用端发送用于访问待访问文件的文件访问请求；

若所述文件访问请求包括文件标识，则向所述NFS服务端组件发送所述文件标识，以通过所述NFS服务端组件根据所述文件标识从所述存储节点访问所述待访问文件，所述文件标识包括所述待访问文件的文件名及文件存储地址；

若所述文件访问请求不包括所述文件标识但包括文件名，则根据所述文件名获取所述文件存储地址，以通过所述NFS服务端组件根据所述文件存储地址从所述存储节点访问所述待访问文件；

向所述应用端响应所述文件访问请求。

2.如权利要求1所述的文件访问方法，其特征在于，所述存储节点还运行有元数据管理组件，所述根据所述文件名获取所述文件存储地址的步骤包括：

若所述NFS客户端存储有与所述文件名对应的文件标识，则从所述文件标识中获取所述文件存储地址；

若所述NFS客户端未存储有与所述文件名对应的文件标识，则根据所述文件名向所述元数据管理组件查询所述文件存储地址。

3.如权利要求2所述的文件访问方法，其特征在于，所述方法还包括：

根据所述文件名及所述文件存储地址生成所述文件标识；

将所述文件标识进行存储。

4.如权利要求1所述的文件访问方法，其特征在于，所述方法还包括：

向所述NFS服务端组件发送获取待查询目录的目录列表请求，以使所述NFS服务端组件基于所述目录列表请求返回所述待查询目录的目录列表，所述待查询目录的目录列表包括所述待查询目录下的待查询文件名及待查询文件存储地址；

根据所述待查询文件名及所述待查询文件存储地址，生成待查询文件标识；

将所述待查询文件标识进行存储。

5.如权利要求4所述的文件访问方法，其特征在于，所述将所述待查询文件标识进行存储的步骤包括：

从预先存储的目录树中找到与所述待查询文件标识对应的目标文件节点，所述目录树包括按照目录层次结构组织的目录节点和文件节点，每一目录节点表征一个目录，每一文件节点表征一个文件；

将所述待查询文件标识作为所述文件节点对应的文件的访问元数据，所述文件节点对应的文件的访问元数据表征访问所述文件节点对应的文件的文件名和文件存储地址。

6.如权利要求1所述的文件访问方法，其特征在于，所述方法还包括：

基于所述NFS服务端组件返回的操作待操作文件成功的响应请求，向所述NFS服务端组件发送针对所述待操作文件的文件状态获取请求，以使所述NFS服务端组件返回所述待操作文件的文件状态，所述待操作文件的文件状态包括待操作文件名及待操作文件存储地址；

根据所述待操作文件名及所述待操作文件存储地址，生成待操作文件标识；

将所述待操作文件标识进行存储。

7.如权利要求6所述的文件访问方法，其特征在于，所述将所述待操作文件标识进行存储的步骤包括：

将所述待操作文件名替换为所述待操作文件标识；

将所述待操作文件标识作为所述待操作文件的访问元数据进行存储，所述待操作文件的访问元数据表征访问所述待操作文件的文件名和文件存储地址。

8.一种数据访问装置，其特征在于，应用于网络文件系统NFS客户端，所述NFS客户端与应用端及分布式文件系统中的存储节点均通信连接，所述存储节点运行有NFS服务端组件，所述装置包括：

接收模块，用于接收所述应用端发送用于访问待访问文件的文件访问请求；

访问模块，用于若所述文件访问请求包括文件标识，则向所述NFS服务端组件发送所述文件标识，以通过所述NFS服务端组件根据所述文件标识从所述存储节点访问所述待访问文件，所述文件标识包括所述待访问文件的文件名及文件存储地址；

访问模块，还用于若所述文件访问请求不包括所述文件标识但包括文件名，则根据所述文件名获取所述文件存储地址，以通过所述NFS服务端组件根据所述文件存储地址从所述存储节点访问所述待访问文件；

响应模块，用于向所述应用端响应所述文件访问请求。

9.一种客户端，其特征在于，包括处理器和存储器，所述存储器用于存储程序，所述处理器用于在执行所述程序时，实现权利要求1-7中任一项所述的文件访问方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，该计算机程序被处理器执行时实现如权利要求1-7中任一项所述的文件访问方法。

Images