CN115203156A - 一种元数据处理方法、装置、设备及计算机存储介质 - Google Patents

Abstract

本申请实施例公开了一种元数据处理方法、装置、设备及存储介质，其中，所述方法包括：文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；所述目标操作的类型属于写操作的情况下，基于所述元数据对象的路径信息，对所述元数据对象进行与所述目标操作的类型对应的处理，得到处理结果；基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作：将所述处理结果写入元数据缓存中；将所述处理结果返回所述文件协议层；基于所述目标操作的类型，将所述元数据处理请求进行持久化。

Description

一种元数据处理方法、装置、设备及计算机存储介质

技术领域

本申请实施例涉及数据处理技术领域，涉及但不限于一种元数据处理方法、装置、设备及计算机存储介质。

背景技术

现有在分布式文件系统中，小文件的读写性能是一个痛点；相对于大文件来说，小文件的读写性能中对元数据的操作占比很高。当分布式文件系统中以小文件为主时，系统的读写性能取决于元数据的处理性能，而元数据的处理性能受限于元数据的语义，并发不高，因此容易达到性能瓶颈，造成大量小文件的处理形成性能瓶颈。

发明内容

有鉴于此，本申请实施例提供一种元数据处理方法、装置、设备及计算机存储介质。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种元数据处理方法包括：文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；所述目标操作的类型属于写操作的情况下，基于所述元数据对象的路径信息，对所述元数据对象进行与所述目标操作的类型对应的处理，得到处理结果；基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作：将所述处理结果写入元数据缓存中；将所述处理结果返回所述文件协议层；基于所述目标操作的类型，将所述元数据处理请求进行持久化。

第二方面，本申请实施例提供一种元数据处理装置所述装置包括：接收模块，用于文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；处理模块，用于所述目标操作的类型属于写操作的情况下，基于所述元数据对象的路径信息，对所述元数据对象进行与所述目标操作的类型对应的处理，得到处理结果；操作模块，用于基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作：将所述处理结果写入元数据缓存中；将所述处理结果返回所述文件协议层；基于所述目标操作的类型，将所述元数据处理请求进行持久化。

第三方面，本申请实施例提供一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法的元数据处理方法。

第四方面，本申请实施例提供一种计算机存储介质，存储有可执行指令，用于引起处理器执行时，实现上述方法的元数据处理方法。

本申请实施例中，利用文件协议层网关对所述元数据对象进行与所述目标操作对应的处理，并将处理结果保存在元数据缓存中，缩短了元数据读写路径；对于大部分非核心元数据不敏感的操作，可以直接将元数据写入到元数据缓存，读取时，也从元数据缓存中读到最新的元数据，从而极大的降低了元数据操作的时延。基于目标操作的类型，将元数据处理请求进行持久化，对于核心的元数据，以写日志的方式，直接在本地追加到持久化的存储中，相对于写入到元数据服务器，同样地缩短了读写路径。由于处理元数据请求在文件协议层网关完成，可以有效提高元数据处理的并发能力。

附图说明

图1A为本申请实施例提供的一种分布式元数据处理的系统架构示意图；

图1B为本申请实施例提供的一种元数据处理方法的实现流程示意图；

图2为本申请实施例提供的一种元数据处理方法的实现流程示意图；

图3为本申请实施例提供的一种元数据处理方法的功能配置示意图；

图4A为本申请实施例提供的一种元数据处理方法的流程示意图；

图4B为本申请实施例提供的一种请求序列的示意图；

图4C为本申请实施例提供的一种待发送队列和正发送队列对接的示意图；

图5为本申请实施例提供的元数据处理装置的组成结构示意图；

图6为本申请实施例提供的电子设备的一种硬件实体示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对发明的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

文件(File)：对一段数据进行管理的单位。

文件系统(File System)：对存储设备上的数据按文件进行存储和访问的管理系统。

小文件(Small File)：小文件，包含极少量数据的文件。

元数据(Metadata)：文件系统管理文件数据时产生的数据，即数据的数据。

缓存(Cache)：为了加速读写内容而将内容存储在本地的机制。

元数据缓存(Metadata Cache)：对元数据进行读写加速的缓存。

客户端(Client)：文件系统客户端，发起文件操作。

文件协议层网关(protocol gate way，PGW)：作为文件系统客户端。

元数据服务器(metadata server，MDS)：管理文件系统的元数据。

Dcache：一种持久化的分布式数据缓存。

Jounrnal：一种追加方式写入数据的持久化方式。

分布式文件系统(distribute file system，DFS)：由多个client/server节点组成的文件系统，允许client管理server节点上存储的文件。

EDS：一种分布式的存储系统，提供了对象、块、和文件存储功能。

通用Internet文件系统(Common Internet File System，CIFS)：一种windows下的文件共享协议。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

应当理解，此处所描述的一些实施例仅仅用以解释本申请的技术方案，并不用于限定本申请的技术范围。

图1A为本申请实施例提供的一种分布式元数据处理的系统架构示意图，如图1A所示，该示意图包括：文件共享协议101、文件协议层网关102、持久化日志103和元数据服务器104，其中，文件协议层网关102包括应用程序接口1021和元数据缓存1022。

文件共享协议101，可以是一种windows下的文件共享协议；

文件协议层网关102可以作为文件系统客户端，发起文件操作；应用程序接口1021，用于接收并处理元数据请求；元数据缓存1022，是用于对元数据进行读写加速的缓存。

持久化日志103为在持久化的分布式数据缓存中，利用一种追加方式写入数据的持久化方式；

元数据服务器104，用于管理文件系统的元数据。

本申请实施例提供的一种元数据处理方法，如图1B所示，该方法包括：

步骤S101、文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；

任何文件系统中的数据分为数据和元数据。数据是指普通文件中的实际数据，而元数据指用来描述一个文件的特征的系统数据，诸如访问权限、文件拥有者以及文件数据块的分布信息等等。

在一些实施例中，如图1A所示，文件协议层网关102可以作为文件系统客户端接收文件共享协议101发送的元数据处理请求。

在一些实施例中，待处理的元数据对象可以是例如：文件的位置、文件的大小、文件的占用空间等；对应地，待处理的元数据对象的路径信息可以是例如：存放文件的位置信息的路径信息，存放文件的大小的路径信息，存放文件的占用空间信息的路径信息等。

步骤S102、所述目标操作的类型属于写操作的情况下，基于所述元数据对象的路径信息，对所述元数据对象进行与所述目标操作的类型对应的处理，得到处理结果；

在一些实施例中，写操作可以是例如：打开、创建、设置属性信息、创建扩展属性、截断。

在一些实施例中，目标操作的类型属于写操作的情况下，可以基于元数据对象的路径信息确定元数据对象存放的位置，在确定数据对象存放的位置的情况下，可以对元数据对象进行与目标操作对应的处理，例如，基于存放文件的位置信息的路径信息，可以设置存放文件的位置信息。

步骤S103、基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作：将所述处理结果写入元数据缓存中；将所述处理结果返回所述文件协议层；基于所述目标操作的类型，将所述元数据处理请求进行持久化。

将所述处理结果存储于元数据缓存中，在实施过程中，例如，可以将设置的存放文件的位置信息存储与数据缓存中。在一些实施例中，如图1A所示，元数据缓存1022可以设置于文件协议层网关102，是用于对元数据进行读写加速的缓存。

将所述处理结果返回所述文件协议层，在一些实施例中，如图1A所示，在对元数据完成处理后，将处理结果返回文件共享协议101。

基于所述目标操作的类型，将所述元数据处理请求进行持久化。在根据目标操作的不同类型，确定将元数据请求进行持久化的方式，例如，目标操作的类型为写操作，且为核心写操作(编辑节点号、编辑大小、更改路径)的情况下，立即将元数据处理请求进行持久化；目标操作的类型为写操作，且为非核心写操作(打开、创建、设置属性信息、创建扩展属性、截断)的情况下，可以定期将非核心写操作进行持久化。在一些实施例中，如图1A所示，可以利用在持久化的分布式数据缓存中的持久化日志103，用一种追加方式写入数据的持久化方式进行元数据处理请求的持久化。其中，持久化日志103可以使用本地固态驱动器(Solid State Disk或Solid State Drive，SSD)进行替代，通过牺牲高可用性换取更好的写日志性能。

本申请实施例中，利用文件协议层网关对所述元数据对象进行与所述目标操作对应的处理，并将处理结果保存在元数据缓存中，缩短了元数据读写路径；对于大部分非核心元数据不敏感的操作，可以直接将元数据写入到元数据缓存，读取时，也从元数据缓存中读到最新的元数据，从而极大的降低了元数据操作的时延。基于目标操作的类型，将元数据处理请求进行持久化，对于核心的元数据，以写日志的方式，直接在本地追加到持久化的存储中，相对于写入到元数据服务器，同样地缩短了读写路径。由于处理元数据请求在文件协议层网关完成，可以有效提高元数据处理的并发能力。

图2为本申请实施例提供的一种元数据处理方法，元数据处理请求还包括写入参数值，如图2所示，该方法包括：

步骤S201、文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；

步骤S202、所述目标操作的类型属于写操作的情况下，在基于所述元数据对象的路径信息查找到所述元数据对象的情况下，基于所述元数据对象将所述写入参数值写入，得到作为所述处理结果的写入结果；

在一些实施例中，写操作可以是例如：打开、创建、设置属性信息、创建扩展属性、截断；对应地，写入参数值可以是设置的属性信息，创建的扩展信息等。

在实施过程中，例如，文件协议层网关接收文件协议层发送的元数据处理请求为设置属性信息，其中，元数据处理请求包括设置属性信息的路径信息、设置属性信息和设置的属性信息，设置的属性信息即写入参数。

在一些实施例中，可以先根据元数据对象的路径信息确定元数据对象，再将写入参数值写入元数据对象，例如，数据处理请求为设置属性信息，可以先根据设置属性信息的路径信息确定待写入的属性信息的位置，再将设置的属性信息写入对象的位置，得到已经写入的属性信息。

在实施过程中，首先需要基于元数据对象的路径查找元数据对象，在查找到元数据对象的情况下，再将写入参数值写入元数据对象，最后得到写入结果。

步骤S203、在基于所述元数据对象的路径信息未查找到所述元数据对象的情况下，得到写入错误的写入结果；

在实施过程中，如果基于元数据对象的路径信息未查找到元数据对象，则无法写入参数，得到写入错误的写入结果。

步骤S204、在所述目标操作的类型为第二预设类型的情况下，在将所述写入结果写入元数据缓存的同时，将所述元数据处理请求进行持久化后，将所述写入结果返回所述文件协议层。

在一些实施例中，第二预设类型可以是核心的元数据处理请求，用户可以根据实际需要设置核心的元数据请求。

在实施过程中，在所述目标操作的类型为第二预设类型的情况下，可以写入结果写入元数据缓存的同时，将所述元数据处理请求进行持久化，最后将所述写入结果返回所述文件协议层。

本申请实施例中，元数据处理请求还包括写入参数值，需要基于元数据对象的路径查找元数据对象，在查找到元数据对象的情况下，再将写入参数值写入元数据对象，最后得到写入结果；如果基于元数据对象的路径信息未查找到元数据对象，则无法写入参数，得到写入错误的写入结果。这样，可以将写入参数值有效写入对应的元数据对象，并得到写入结果。

在目标操作的类型为第二预设类型的情况下，可以入结果写入元数据缓存的同时，将所述元数据处理请求进行持久化，最后将所述写入结果返回所述文件协议层。这样，对于核心的元数据请求，以写日志的方式，直接在本地追加到持久化的存储中，相对于写入到元数据服务器，同样地缩短了读写路径，同时将核心的元数据请求立即同步进行持久化处理，可以有效保障核心的元数据请求不会丢失。

本申请实施例提供的一种元数据处理方法，该方法包括：

步骤S211、文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；

步骤S212、所述目标操作的类型属于写操作的情况下，在基于所述元数据对象的路径信息查找到所述元数据对象的情况下，基于所述元数据对象将所述写入参数值写入，得到作为所述处理结果的写入结果；

步骤S213、在基于所述元数据对象的路径信息未查找到所述元数据对象的情况下，得到写入错误的写入结果；

步骤S214、在所述目标操作的类型为第一预设类型的情况下，在将所述写入结果写入元数据缓存中，将所述元数据处理请求写入所述元数据缓存的待持久化序列后，将所述写入结果返回所述文件协议层；

在一些实施例中，第一预设类型可以是非核心的元数据处理请求，用户可以根据实际需要设置非核心的元数据请求。

在一些实施例中，在所述目标操作的类型为第一预设类型的情况下，可以定期或者，在元数据请求的数量达到一定数量阈值的情况下，将目标操作的类型为第一预设类型的元数据处理请求进行封装，然后将封装后的请求发送至持久化日志，这样，可以有效减少元数据请求写入持久化日志的次数。

在一些实施例中，述元数据缓存的待持久化序列可以是将至少两个目标操作的类型为第一预设类型的元数据请求进行合并后写入的持久化序列。

在实施过程中，在所述目标操作的类型为第一预设类型的情况下，可以定期或者，在元数据请求的数量达到一定数量阈值的情况下，将所述元数据处理请求写入所述元数据缓存的待持久化序列。

步骤S215、在将所述写入结果返回所述文件协议层后，将所述元数据处理请求进行持久化，得到持久化日志。

本申请实施例中，在目标操作的类型为非核心请求的情况下，可以先处理元数据请求，再将元数据请求写入元数据缓存的待持久化序列，同时将写入结果返回文件协议层。这样，可以有效减小元数据处理时延。

本申请实施例提供的一种元数据处理方法，该方法包括：

步骤S221、文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；

步骤S222、所述目标操作的类型属于写操作的情况下，在基于所述元数据对象的路径信息查找到所述元数据对象的情况下，基于所述元数据对象将所述写入参数值写入，得到作为所述处理结果的写入结果；

步骤S223、在基于所述元数据对象的路径信息未查找到所述元数据对象的情况下，得到写入错误的写入结果；

步骤S224、在所述目标操作的类型为第一预设类型的情况下，在将所述写入结果写入元数据缓存中，将所述元数据处理请求写入所述元数据缓存的待持久化序列后，将所述写入结果返回所述文件协议层；

步骤S225、在将所述写入结果返回所述文件协议层后，在所述待持久化序列，将至少两个所述目标操作的类型为第一预设类型的元数据处理请求进行合并，将合并后的元数据处理请求发送至所述持久化日志。

在一些实施例中，可以首先在待持久化序列中，将至少两个目标操作的类型为第一预设类型的元数据处理请求进行合并，然后将合并后的元数据处理请求发送至所述持久化日志。

本申请实施例中，首先在待持久化序列中，将至少两个目标操作的类型为第一预设类型的元数据处理请求进行合并，然后将合并后的元数据处理请求发送至所述持久化日志。这样，将元数据请求合并后再发送至所述持久化日志，可以有效减少元数据发送至所述持久化日志的次数，即减少了交互次数，有效提升系统的处理效率。

图3为本申请实施例提供的一种元数据处理方法，元数据处理请求还包括写入参数值，如图3所示，该方法包括：

步骤S301、文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；

步骤S302、所述目标操作的类型属于写操作的情况下，在基于所述元数据对象的路径信息查找到所述元数据对象的情况下，基于所述元数据对象将所述写入参数值写入，得到作为所述处理结果的写入结果；

步骤S303、在基于所述元数据对象的路径信息未查找到所述元数据对象的情况下，得到写入错误的写入结果；

步骤S304、在所述目标操作的类型为第一预设类型的情况下，在将所述写入结果写入元数据缓存中，将所述元数据处理请求写入所述元数据缓存的待持久化序列后，将所述写入结果返回所述文件协议层；

步骤S305、在将所述写入结果返回所述文件协议层后，判断所述待持久化序列中第二个元数据处理请求与第一元数据处理请求是否满足合并规则；

步骤S306、在满足所述合并规则的情况下，将第二个元数据处理请求与第一元数据处理请求进行合并，将合并后的第一个元数据请求作为更新后的第一元数据请求；

以此类推，直至将所述待持久化序列中的元数据处理请求合并完，或者不满足合并规则的情况下，将所述第一元数据处理请求或合并后的第一个元数据处理请求发送至所述持久化日志。

所述预设的合并规则，包括：

在以下之一目的操作与所述创建操作进行合并的情况下，得到创建请求序列：所述打开、所述设置属性信息、所述创建扩展属性、所述截断；

在以下之一目的操作与所述打开操作进行合并的情况下，得到打开请求序列：所述设置属性信息、所述创建扩展属性、所述截断；

在以下之一目的操作与所述设置属性信息进行合并的情况下，得到设置属性信息请求序列；所述创建扩展属性、所述截断；

在创建扩展属性与所述设置属性信息进行合并的情况下，得到截断请求序列。

表3B为本申请实施例提供的一种合并规则，如表3B所示，包括横向表头或纵向表头都包括：创建、打开、设置属性信息、创建扩展属性、截断。

表内填写的请求为横向表头和纵向表头的请求合并后的请求。其中，表中的无表示不会出现或者不能合并。

表3B

如表3B所示，合并规则可以理解为：

基于将所述打开、或所述设置属性信息、或所述创建扩展属性、或所述截断与所述创建合并的情况下，得到创建请求序列；

基于将所述设置属性信息、或所述创建扩展属性、或所述截断与所述打开合并的情况下，得到打开请求序列；

基于将所述创建扩展属性、或所述截断与所述设置属性信息合并的情况下，得到设置属性信息请求序列；

基于将所述创建扩展属性与所述截断合并的情况下，得到截断请求序列。

本申请实施例中，在满足所述合并规则的情况下，将第二个元数据处理请求与第一元数据处理请求进行合并，将合并后的第一个元数据请求作为更新后的第一元数据请求；以此类推，直至将所述待持久化序列中的元数据处理请求合并完，或者不满足合并规则的情况下，将所述第一元数据处理请求或合并后的第一个元数据处理请求发送至所述持久化日志。这样，可以将非核心请求进行有效合并发送持久化日志，将核心请求直接发送持久化日志，合并了元数据请求，减少了元数据交互次数。

在分布式文件系统中，小文件的性能是一个痛点；相对于大文件来说，小文件的性能中元数据占比很高。当分布式文件系统中以小文件为主时，系统的性能取决于元数据的处理性能，而元数据的处理性能受限于元数据的语义，并发不高，因此容易达到性能瓶颈。从而造成大量小文件的处理形成性能瓶颈。因此，需要采用一种方法，提高元数据的处理能力。

常见的优化方向是对元数据服务器进行横向扩展，可以同时处理多个目录下的文件，使得总体的性能上升。这类方法可以提高目录级别的并发性能，但无法提高单个目录内的文件处理能力。

图1A为本申请实施例提供的一种分布式元数据处理的系统架构示意图，如图1A示，向原架构中添加了元数据缓存1022和持久化日志103，从文件共享协议101发起的请求，到达文件协议层网关102后，经应用程序接口1021处理后，统一进入内存元数据缓存1022，由元数据缓存1022根据元数据请求的类型，以及涉及到的元数据种类，决定是否立即返回请求。

对于写请求，元数据写入到元数据缓存，或者进一步持久化到持久化日志103中，再返回。

对于读请求，如果在元数据缓存中命中元数据，则立即返回；否则，读请求继续发送到元数据服务器，等待元数据服务器返回后，达文件协议层网关再向上层返回。

元数据缓存和持久化日志的加入，缩短了元数据的IO路径，降低元数据时延。

图4A为本申请实施例提供的一种元数据处理方法的流程示意图，如图4A所示，该方法包括：

步骤1、文件共享协议101发送元数据处理请求至文件协议层网关101；

步骤2、文件协议层网关102中的应用程序接口1021将元数据请求写入文件协议层网关102中的元数据缓存1021；

步骤3、元数据缓存将元数据处理请求写入持久化日志103；

步骤4、持久化日志103将存储的元数据处理请求发送至元数据缓存1022；

步骤5、元数据缓存1022将处理的结果发送给应用程序接口；

步骤6、应用程序接口1021将处理的结果返回文件共享协议101；

步骤7、持久化日志将元数据处理请求写入元数据缓存104，并在元数据缓存中处理元数据处理请求。

本申请实施例可以将元数据请求根据用户的实际需求分为非核心请求和核心请求，其中，为非核心请求提供处理方法A，为核心请求提供处理方法B：

处理方法A：对于非核心的元数据写入，为了加速元数据处理，不立即持久化。由元数据缓存定期的将指令写入到持久化日志中。

处理方法A的处理步骤为：

步骤S401、元数据请求写入到元数据缓存进行处理，得到处理结果；

如图4A所示，步骤2为用程序接口1021将元数据请求写入文件协议层网关102中的元数据缓存1021进行处理，得到处理结果。

步骤S402、立即向文件共享协议返回处理结果，然后异步的将元数据请求写入到持久化中；

如图4A所示步骤5、6，即向文件共享协议101返回处理结果，然后如步骤7异步的将元数据请求写入到持久化中。

元数据缓存中缓存着非核心元数据的请求，可以进行合并后，再一次性的写入到持久化日志中。

图4B为本申请实施例提供的一种请求序列的示意图，如图4B所示，包括：

元数据三次异步写入的元数据请求：

第一次写入的元数据请求的类型为创建、创建扩展属性、截断、设置属性信息；第二次写入的元数据请求类型为写入、获取属性、获取扩展属性；第三次写入的元数据请求类型为属性、设置属性信息、创建扩展属性和关闭。

图4C为本申请实施例提供的一种待发送队列和正发送队列对接的示意图，如图4C所示，全局队列401包括待发送队列402和正发送队列403的对接，将待发送对队列402定期的一次性加入到正发送队列403中，并且进行请求合并。这样，在全局队列401中能看到被合并的请求的过程，不能合并的请求还是原样留在了全局正发送队列402中，这是从全局的角度处理请求。

从单个文件的角度处理请求，当请求从全局队列401发送对接出来后，请求就直接在文件中进行处理，所以文件1有待发送队列1和正发送队列2两个队列，当文件正发送队列2为空的情况下，文件中下一批可以合并的请求进行发送，直到文件中的待发送队列为空

步骤S403、再异步地更新到元数据服务器。

如图4A所示，步骤7为将元数据处理请求异步更新到元数据服务器104。

本申请实施例提供的一种异步发送机制，异步发送机制是元数据缓存更新元数据的指令到持久化日志的基本方法，通过异步发送队列来实现。

元数据缓存中会同时存在多个文件的元数据更新，因此需要一个全局的元数据指令队列，保存待持久化的元数据指令，同时，由于需要在每个文件内进行指令的合并处理，因此需要文件粒度的元数据指令队列。当文件的请求持久化到持久化日志后，文件队列中会清理相关的请求。

处理方法B：对于核心的元数据，需要优先保障其安全性。例如，核心请求为追加写入数据后，需要更新size。需要将MetaCache中更新的元数据请求，同步提交到Journal中。

步骤S411、元数据请求写入到元数据缓存进行处理，得到处理结果；同步提交元数据处理请求到持久化日志；

如图4A所示，步骤2为用程序接口1021将元数据请求写入文件协议层网关102中的元数据缓存1021进行处理，得到处理结果。步骤3为同步提交元数据处理请求到持久化日志103中。

步骤S412、立即向文件共享协议返回处理结果；

如图4A所示，步骤5、6为立即向文件共享协议101返回处理结果。

步骤S413、再异步地更新到元数据服务器。

如图4A所示，步骤7为将元数据处理请求异步更新到元数据服务器104。

本申请实施例提出了一种可以用于分布式文件系统提升小文件性能的优化方法。该方法基于内存中的元数据缓存，通过减小元数据处理时延，达到提高元数据处理的并发能力的目的。相对于传统的优化方法，做出了以下几点优化：

1、缩短了元数据IO路径，对于大部分元数据不敏感的操作，可以直接将元数据写入到内存，读取时，也从内存中读到最新的元数据，从而极大的降低了元数据操作的时延；对于重要的元数据，以写持久化日志的方式，直接在本地追加到持久化的存储中，相对于写入到元数据服务器，同样地缩短了IO路径。

2、合并了元数据请求，减少了元数据交互次数。采用了元数据缓存后，以异步的方式将元数据同步到持久化日志中，在提交前，进行元数据请求合并，从而减少提交的次数。

同时本申请还可以完成文件协议层网关的横向扩展：这里，横向扩展以目录为粒度。通常以共享目录作为扩展的基本单位。为了保证元数据缓存的完整性，要求共享目录和文件协议层网关所在节点进行绑定，防止通过多个节点同时访问和操作共享目录，造成主节点的元数据缓存不完整，造成元数据缓存失效,无法缩短元数据IO路径。因此，在横向扩展时，要求不同的文件协议层网关配置不同的共享目录，并使得所有的目录能够均匀的分布在各个节点上。

本申请还可以在文件协议层进行请求合并，减少了网络交互次数，降低了时延。

基于前述的实施例，本申请实施例提供一种元数据处理装置，该装置包括所包括的各模块，各模块包括各子模块，各子模块包括单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图5为本申请实施例提供的元数据处理装置的组成结构示意图，如图5所示，所述装置500包括：

接收模块501，件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；

处理模块502，用于所述目标操作的类型属于写操作的情况下，基于所述元数据对象的路径信息，对所述元数据对象进行与所述目标操作的类型对应的处理，得到处理结果；

操作模块502，用于基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作：将所述处理结果写入元数据缓存中；将所述处理结果返回所述文件协议层；基于所述目标操作的类型，将所述元数据处理请求进行持久化。

在一些实施例中，元数据处理请求还包括写入参数值，对应地，所述处理模块502包括写入子模块和得到子模块，其中，所述写入子模块，用于在基于所述元数据对象的路径信息查找到所述元数据对象的情况下，基于所述元数据对象将所述写入参数值写入，得到作为所述处理结果的写入结果；所述得到子模块，用于在基于所述元数据对象的路径信息未查找到所述元数据对象的情况下，得到写入错误的写入结果。

在一些实施例中，所述操作模块503包括写入子模块，持久化子模块和返回子模块，其中，所述写入子模块，用于在所述目标操作的类型为第二预设类型的情况下，在将所述写入结果写入元数据缓存；所述持久化子模块用于同时，将所述元数据处理请求进行持久化；所述返回子模块，用于将所述写入结果返回所述文件协议层。

在一些实施例中，所述写入子模块，还用于在所述目标操作的类型为第一预设类型的情况下，在将所述写入结果写入元数据缓存中；所述返回子模块，用于将所述元数据处理请求写入所述元数据缓存的待持久化序列后，将所述写入结果返回所述文件协议层；所述持久化子模块，用于在将所述写入结果返回所述文件协议层后，将所述元数据处理请求进行持久化，得到持久化日志。

在一些实施例中，所述持久化子模块还用在所述待持久化序列，将至少两个所述目标操作的类型为第一预设类型的元数据处理请求进行合并，将合并后的元数据处理请求发送至所述持久化日志。

在一些实施例中，所述持久化子模块包括判断单元和合并单元，其中，所述判断单元，用于判断所述待持久化序列中第二个元数据处理请求与第一元数据处理请求是否满足合并规则；所述合并单元，用于在满足所述合并规则的情况下，将第二个元数据处理请求与第一元数据处理请求进行合并，将合并后的第一个元数据请求作为更新后的第一元数据请求；以此类推，直至将所述待持久化序列中的元数据处理请求合并完，或者不满足合并规则的情况下，将所述第一元数据处理请求或合并后的第一个元数据处理请求发送至所述持久化日志。

在一些实施例中，预设的合并规则包括：在以下之一目的操作与所述创建操作进行合并的情况下，得到创建请求序列：所述打开、所述设置属性信息、所述创建扩展属性、所述截断；在以下之一目的操作与所述打开操作进行合并的情况下，得到打开请求序列：所述设置属性信息、所述创建扩展属性、所述截断；在以下之一目的操作与所述设置属性信息进行合并的情况下，得到设置属性信息请求序列；所述创建扩展属性、所述截断；在创建扩展属性与所述设置属性信息进行合并的情况下，得到截断请求序列。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的元数据处理方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备(可以是手机、平板电脑、笔记本电脑、台式计算机等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的元数据处理方法中的步骤。

对应地，本申请实施例提供一种电子设备，图6为本申请实施例提供的电子设备的一种硬件实体示意图，如图6所示，该设备600的硬件实体包括：包括存储器601和处理器602，所述存储器601存储有可在处理器602上运行的计算机程序，所述处理器602执行所述程序时实现上述实施例中提供的元数据处理方法中的步骤。

存储器601配置为存储由处理器602可执行的指令和应用，还可以缓存待处理器602以及电子设备600中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory，RAM)实现。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备(可以是手机、平板电脑、笔记本电脑、台式计算机等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

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

Claims (10)

1.一种元数据处理方法，所述方法包括：

文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；

所述目标操作的类型属于写操作的情况下，基于所述元数据对象的路径信息，对所述元数据对象进行与所述目标操作的类型对应的处理，得到处理结果；

基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作：

将所述处理结果写入元数据缓存中；

将所述处理结果返回所述文件协议层；

基于所述目标操作的类型，将所述元数据处理请求进行持久化。

2.如权利要求1所述的方法，其特征在于，所述元数据处理请求还包括写入参数值，对应地：

所述基于所述元数据对象的路径信息，对所述元数据对象进行与所述目标操作的类型对应的处理，得到处理结果，包括：在基于所述元数据对象的路径信息查找到所述元数据对象的情况下，基于所述元数据对象将所述写入参数值写入，得到作为所述处理结果的写入结果；

在基于所述元数据对象的路径信息未查找到所述元数据对象的情况下，得到写入错误的写入结果。

3.如权利要求1或2所述的方法，其特征在于，所述基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作，包括：

在所述目标操作的类型为第二预设类型的情况下，在将所述写入结果写入元数据缓存的同时，将所述元数据处理请求进行持久化后，将所述写入结果返回所述文件协议层。

4.如权利要求1或2所述的方法，其特征在于，所述基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作，包括：

在所述目标操作的类型为第一预设类型的情况下，在将所述写入结果写入元数据缓存中，将所述元数据处理请求写入所述元数据缓存的待持久化序列后，将所述写入结果返回所述文件协议层；

在将所述写入结果返回所述文件协议层后，将所述元数据处理请求进行持久化，得到持久化日志。

5.如权利要求4所述的方法，其特征在于，所述将所述元数据处理请求进行持久化，得到持久化日志，包括：

在所述待持久化序列，将至少两个所述目标操作的类型为第一预设类型的元数据处理请求进行合并，将合并后的元数据处理请求发送至所述持久化日志。

6.如权利要求5所述的方法，其特征在于，所述在所述待持久化序列，将至少两个所述目标操作的类型为第一预设类型的元数据处理请求进行合并，将合并后的元数据处理请求发送至所述持久化日志，包括：

判断所述待持久化序列中第二个元数据处理请求与第一元数据处理请求是否满足合并规则；

在满足所述合并规则的情况下，将第二个元数据处理请求与第一元数据处理请求进行合并，将合并后的第一个元数据请求作为更新后的第一元数据请求；

以此类推，直至将所述待持久化序列中的元数据处理请求合并完，或者不满足合并规则的情况下，将所述第一元数据处理请求或合并后的第一个元数据处理请求发送至所述持久化日志。

7.如权利要求6所述的方法，其特征在于，所述预设的合并规则，包括：

在以下之一目的操作与所述创建操作进行合并的情况下，得到创建请求序列：所述打开、所述设置属性信息、所述创建扩展属性、所述截断；

在以下之一目的操作与所述打开操作进行合并的情况下，得到打开请求序列：所述设置属性信息、所述创建扩展属性、所述截断；

在以下之一目的操作与所述设置属性信息进行合并的情况下，得到设置属性信息请求序列；所述创建扩展属性、所述截断；

在创建扩展属性与所述设置属性信息进行合并的情况下，得到截断请求序列。

8.一种元数据处理装置，所述装置包括：

接收模块，用于文件协议层网关接收文件协议层发送的元数据处理请求；其中，所述元数据处理请求至少包括待处理的元数据对象的路径信息、对所述元数据对象的目标操作的类型；

处理模块，用于所述目标操作的类型属于写操作的情况下，基于所述元数据对象的路径信息，对所述元数据对象进行与所述目标操作的类型对应的处理，得到处理结果；

操作模块，用于基于所述目标操作的类型，对所述处理结果和所述元数据处理请求进行以下操作：将所述处理结果写入元数据缓存中；将所述处理结果返回所述文件协议层；基于所述目标操作的类型，将所述元数据处理请求进行持久化。

9.一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至7任一项所述方法中的步骤。

10.一种计算机存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至7任一项所述的方法中的步骤。

Images