一种元数据请求处理方法、装置、设备、介质与流程

1.本申请涉及分布式文件系统技术领域，特别涉及一种元数据请求处理方法、装置、设备、介质。


背景技术：

2.随着信息技术的发展，分布式文件系统成为大数据处理的基石，其中，在分布式文件系统中比较常用的架构为hadoop，hadoop是一个由apache基金会所开发的分布式系统基础架构，是云计算的存储基石。随着数据规模越来越大，由于hadoop中的namenode中心化问题导致分布式文件系统的性能遇到瓶颈，也即，hadoop架构的分布式文件系统中，由于只能由一个namenode节点提供整个分布式文件系统的元数据服务，所以使得整个分布式文件系统的性能受到namenode节点性能的限制。同时由于namenode节点将元数据存储在内存中，因此该文件系统所能存储的文件总量受限于namenode节点的内存总容量，且元数据存储一般为小文件存储，而过多的小文件存储会大量消耗namenode节点的存储量。


技术实现要素：

3.有鉴于此，本申请的目的在于提供一种元数据请求处理方法、装置、设备、介质，能够解决现有技术中由于namenode中心化带来的分布式文件系统性能瓶颈问题，提高分布式文件系统的性能。其具体方案如下：
4.第一方面，本申请公开了一种元数据请求处理方法，应用于分布式文件系统中的目标存储节点，包括：
5.通过本地的namenode服务接收所述分布式文件系统对应的客户端发送的第一元数据请求，其中，所述第一元数据请求为hdfs namenode支持的请求，所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点，所述分布式文件系统中的各个存储节点上均运行有所述namenode服务；
6.通过本地的所述namenode服务从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据；
7.如果从本地的所述namenode服务的缓存中未查询到所述第一元数据请求对应的元数据，则通过本地的所述namenode服务将所述第一元数据请求转化为第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求；
8.通过本地的所述namenode服务将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。
9.可选地，所述通过本地的所述namenode服务从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据之后，还包括：
10.如果从本地的所述namenode服务的缓存中查询到所述第一元数据请求对应的元
数据，则将所述元数据返回给所述客户端，并更新所述元数据的热度参数。
11.可选地，所述通过本地的所述namenode服务从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据，包括：
12.通过本地的所述namenode服务对所述第一元数据请求进行解析；
13.通过本地的所述namenode服务根据解析结果从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据。
14.可选地，所述预设负载均衡算法为轮询算法、随机法、加权轮询法及最小连接数法中的任一项。
15.可选地，所述元数据请求处理方法，还包括：
16.通过本地的所述namenode服务按照预设时间间隔对本地的所述namenode服务的缓存中的各条元数据的热度参数进行轮询；
17.将热度参数小于预设热度参数阈值的元数据从本地的所述namenode服务的缓存中删除。
18.可选地，所述通过本地的所述namenode服务将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，包括：
19.通过本地的所述namenode服务利用lru算法将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并更新所述元数据的热度参数。
20.第二方面，本申请公开了一种元数据请求处理装置，应用于分布式文件系统中的目标存储节点，包括：
21.namenode服务中的请求接收模块，用于接收所述分布式文件系统对应的客户端发送的第一元数据请求，其中，所述第一元数据请求为hdfs namenode支持的请求，所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点，所述分布式文件系统中的各个存储节点上均运行有所述namenode服务；
22.所述namenode服务中的查询模块，用于从所述namenode服务的缓存中查询所述第一元数据请求对应的元数据；
23.所述namenode服务中的请求转换模块，用于在从所述namenode服务的缓存中未查询到所述第一元数据请求对应的元数据时，则将所述第一元数据请求转化为第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求；
24.所述namenode服务中的数据缓存模块，用于将从所述对象存储池中查询到的所述元数据存储到所述namenode服务的缓存中；
25.所述namenode服务中的数据发送模块，用于将查询到的所述元数据返回所述客户端。
26.可选地，所述数据缓存模块，用于:
27.利用lru算法将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并更新所述元数据的热度参数。
28.第三方面，本申请公开了一种电子设备，包括：
29.存储器和处理器；
30.其中，所述存储器，用于存储计算机程序；
31.所述处理器，用于执行所述计算机程序，以实现前述公开的元数据请求处理方法。
32.第四方面，本申请公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述公开的元数据请求处理方法。
33.可见，本申请应用于分布式文件系统中的目标存储节点，首先通过本地的namenode服务接收所述分布式文件系统对应的客户端发送的第一元数据请求，其中，所述第一元数据请求为hdfs namenode支持的请求，所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点，所述分布式文件系统中的各个存储节点上均运行有所述namenode服务。然后再通过本地的所述namenode服务从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据。如果从本地的所述namenode服务的缓存中未查询到所述第一元数据请求对应的元数据，则通过本地的所述namenode服务将所述第一元数据请求转化为第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求。通过本地的所述namenode服务将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。由此可见，在本申请所述的分布式文件系统中各个存储节点上均运行有namenode服务，当需要处理对应的客户端的元数据请求时，便可以利用负载均衡算法从中确定出目标存储节点，然后由目标存储节点处理该元数据请求，这样分布式文件系统中的各个存储节点均运行有namenode服务，便可以解决现有技术中由于namenode中心化到来的分布式文件系统性能瓶颈，提高了分布式文件系统的容灾能力，且在处理元数据请求时，可以进行负载均衡，有不同存储节点上的namenode服务分担元数据请求处理压力，降低单个存储节点上的namenode服务的负载压力，提高分布式文件系统的性能。且目标存储节点上的namenode服务接收到对应的客户端发送的hdfs namenode支持的第一元数据请求之后，便可以先对namenode服务的缓存进行查询，看是否存在第一元数据请求对应的元数据，如果不存在，便需要将第一元数据转换成对象存储支持的第二元数据请求，然后从分布式文件系统中ceph构建的、用于进行对象存储的存储池中查询对应的元数据，并将查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。这样分布式文件系统中完全可以兼容现有的hadoop和ceph，通过对象存储池实现各个存储节点之间的元数据共享，从而支持各个存储节点上的namenode服务运行，也解决了现有技术中存储元数据受限于namenode节点的内存总容量的问题，且在各个存储节点上的namenode服务中引入缓存，可以进一步提高分布式文件系统的响应性能。
附图说明
34.为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
35.图1为本申请公开的一种元数据请求处理方法流程图；
36.图2为本申请公开的一种具体的元数据请求处理方法流程图；
37.图3为本申请公开的一种具体的元数据请求处理方法流程图；
38.图4为本申请公开的一种元数据请求处理装置结构示意图；
39.图5为本申请公开的一种电子设备结构示意图。
具体实施方式
40.下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
41.随着数据规模越来越大，由于hadoop中的namenode中心化问题导致分布式文件系统的性能遇到瓶颈，也即，hadoop架构的分布式文件系统中，由于只能由一个namenode节点提供整个分布式文件系统的元数据服务，所以使得整个分布式文件系统的性能受到namenode节点性能的限制。同时由于namenode节点将元数据存储在内存中，因此该文件系统所能存储的文件总量受限于namenode节点的内存总容量，且元数据存储一般为小文件存储，而过多的小文件存储会大量消耗namenode节点的存储量。有鉴于此，本申请提出了一种元数据请求处理方法，能够解决现有技术中由于namenode中心化带来的分布式文件系统性能瓶颈问题，提高分布式文件系统的性能。
42.参见图1所示，本申请实施例公开了一种元数据请求处理方法，应用于分布式文件系统中的目标存储节点，该方法包括：
43.步骤s11：通过本地的namenode服务接收所述分布式文件系统对应的客户端发送的第一元数据请求，其中，所述第一元数据请求为hdfs namenode支持的请求，所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点，所述分布式文件系统中的各个存储节点上均运行有所述namenode服务。
44.在实际实施过程中，所述分布式文件系统中可以包括多个存储节点，且各个所述存储节点上均运行有namenode服务，其中，namenode用于在hadoop分布式文件系统中，管理分布式文件系统的元数据。且各个所述存储节点上的namenode服务拥有自身对应的缓存，缓存中存储有元数据。此外，所述分布式文件系统的底层存储需要基于ceph构建对象存储池，用于进行对象存储，其中，ceph为新一代分布式文件系统。也即，所述分布式文件系统需要基于hadoop和ceph进行部署，兼容hadoop和ceph。所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点。
45.也即，当存在所述分布式文件系统对应的客户端需要向所述分布式文件系统发送元数据请求时，需要先利用预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出目标存储节点，然后由所述目标存储节点来处理对应的元数据请求。其中，所述预设负载均衡算法为轮询算法、随机法、加权轮询法及最小连接数法中的任一项。
46.在实际过程中，负责进行负载均衡处理的服务可以单独部署在一个节点上，由一个专用节点负责进行负载均衡处理。由于负责进行负载均衡处理的服务一般占用资源较小，所以也可以部署在一般进行存储服务的存储节点上，不需要专用节点来处理负载均衡。
47.在确定出所述目标存储节点之后，所述分布式文件系统会将所述目标存储节点的
ip地址(internet protocol address，互联网协议地址)发送给所述客户端，所述客户端便可以利用所述ip地址访问所述目标存储节点，向所述目标存储节点发送第一元数据请求，所述目标存储节点便可以通过本地的namenode服务接收所述客户端存储发送的第一元数据请求，由于所述namenode服务为hadoop分布式文件系统中管理文件系统的元数据的服务，所以所述第一元数据请求为hdfs(hadoop distributed file system，hadoop分布式文件系统)namenode支持的请求。
48.步骤s12：通过本地的所述namenode服务从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据。
49.在所述目标存储节点上的namenode服务接收到所述第一元数据请求之后，便需要从所述目标存储节点上的namenode服务的缓存中查询所述第一元数据请求对应的元数据。
50.具体地，通过本地的所述namenode服务从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据，包括：通过本地的所述namenode服务对所述第一元数据请求进行解析；通过本地的所述namenode服务根据解析结果从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据。
51.也即，所述目标存储节点中的namenode服务会先对所述第一元数据进行解析，获取所述第一元数据中的请求参数，得到对应的解析结果，然后根据所述解析结果从自身的缓存中查询所述第一元数据处理请求对应的元数据。
52.步骤s13：如果从本地的所述namenode服务的缓存中未查询到所述第一元数据请求对应的元数据，则通过本地的所述namenode服务将所述第一元数据请求转化为第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求。
53.如果从所述目标存储节点中的namenode服务的缓存中未查询到所述第一元数据请求对应的元数据，则表示需要从所述分布式文件系统的所述对象存储池中获取所述第一元数据请求对应的元数据，又由于所述第一元数据请求为hdfs namenode支持的请求，所以需要将所述第一元数据请求转换成第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求。利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据的过程可以具体由所述目标存储节点上负责进行对象存储中的元数据处理的部分执行。也即，所述第一元数据请求和所述第二元数据请求为同一个元数据请求在不同语义下的表达。
54.如果从本地的所述namenode服务的缓存中查询到所述第一元数据请求对应的元数据，则将所述元数据返回给所述客户端，并更新所述元数据的热度参数，其中，所述热度参数为表示元数据在最近预设时长之内被访问的次数等。
55.步骤s14：通过本地的所述namenode服务将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。
56.在所述对象存储池中查询到所述第二元数据对应的元数据之后，所述目标存储节点中的namenode服务将所述元数据存储到自身对应的缓存中，并将所述元数据返回给所述客户端。
57.其中，通过本地的所述namenode服务将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，包括：通过本地的所述namenode服务利用lru算法(least recently used，最近最少使用)将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并更新所述元数据的热度参数。
58.可见，本申请应用于分布式文件系统中的目标存储节点，首先通过本地的namenode服务接收所述分布式文件系统对应的客户端发送的第一元数据请求，其中，所述第一元数据请求为hdfs namenode支持的请求，所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点，所述分布式文件系统中的各个存储节点上均运行有所述namenode服务。然后再通过本地的所述namenode服务从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据。如果从本地的所述namenode服务的缓存中未查询到所述第一元数据请求对应的元数据，则通过本地的所述namenode服务将所述第一元数据请求转化为第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求。通过本地的所述namenode服务将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。由此可见，在本申请所述的分布式文件系统中各个存储节点上均运行有namenode服务，当需要处理对应的客户端的元数据请求时，便可以利用负载均衡算法从中确定出目标存储节点，然后由目标存储节点处理该元数据请求，这样分布式文件系统中的各个存储节点均运行有namenode服务，便可以解决现有技术中由于namenode中心化到来的分布式文件系统性能瓶颈，提高了分布式文件系统的容灾能力，且在处理元数据请求时，可以进行负载均衡，有不同存储节点上的namenode服务分担元数据请求处理压力，降低单个存储节点上的namenode服务的负载压力，提高分布式文件系统的性能。且目标存储节点上的namenode服务接收到对应的客户端发送的hdfs namenode支持的第一元数据请求之后，便可以先对namenode服务的缓存进行查询，看是否存在第一元数据请求对应的元数据，如果不存在，便需要将第一元数据转换成对象存储支持的第二元数据请求，然后从分布式文件系统中ceph构建的、用于进行对象存储的存储池中查询对应的元数据，并将查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。这样分布式文件系统中完全可以兼容现有的hadoop和ceph，通过对象存储池实现各个存储节点之间的元数据共享，从而支持各个存储节点上的namenode服务运行，也解决了现有技术中存储元数据受限于namenode节点的内存总容量的问题，且在各个存储节点上的namenode服务中引入缓存，可以进一步提高分布式文件系统的响应性能。
59.参见图2所示，本申请实施例公开了一种具体的元数据请求处理方法，应用于分布式文件系统中的目标存储节点，该方法包括：
60.步骤s21：通过本地的namenode服务接收所述分布式文件系统对应的客户端发送的第一元数据请求，其中，所述第一元数据请求为hdfs namenode支持的请求，所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点，所述分布式文件系统中的各个存储节点上均运行有所述namenode服务。
61.步骤s22：通过本地的所述namenode服务从本地的所述namenode服务的缓存中查
询所述第一元数据请求对应的元数据。
62.步骤s23：如果从本地的所述namenode服务的缓存中查询到所述第一元数据请求对应的元数据，则将所述元数据返回给所述客户端，并更新所述元数据的热度参数。
63.在所述目标存储节点中的namenode服务从自身的缓存中查询所述第一元数据请求对应的元数据的过程中，如果从本地的所述namenode服务的缓存中查询到所述第一元数据请求对应的元数据，也就获取到了所述第一元数据请求对应的元数据，便可以直接将所述元数据返回给所述客户端，并更新所述元数据的热度参数，其中，所述热度参数为表示元数据在最近预设时长之内被访问的次数等。
64.步骤s24：如果从本地的所述namenode服务的缓存中未查询到所述第一元数据请求对应的元数据，则通过本地的所述namenode服务将所述第一元数据请求转化为第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求。
65.步骤s25：通过本地的所述namenode服务将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。
66.步骤s26：通过本地的所述namenode服务按照预设时间间隔对本地的所述namenode服务的缓存中的各条元数据的热度参数进行轮询。
67.在实际应用中，由于各个所述存储节点上的namenode服务中的缓存的空间都是一定的，且一般来说不会太大，所以可以按照预设时间间隔对缓存中的各条元数据的热度参数进行轮询。
68.对于所述目标存储节点来说，就是由所述目标存储节点上的namenode服务对自身的缓存中的各条元数据的热度参数进行轮询。
69.步骤s27：将热度参数小于预设热度参数阈值的元数据从本地的所述namenode服务的缓存中删除。
70.可以理解的是，还需要将热度参数小于预设热度参数阈值的元数据从所述目标存储节点上的namenode服务的缓存中删除，其中，所述预设热度参数阈值可以根据实际情况进行设定，在此不进行具体限定。
71.在热度参数小于预设热度参数阈值时，表明对应的元数据在最近预设时间之内被访问到的次数较少，所以可以将其从所述目标存储节点上的namenode服务的缓存中删除。
72.参见图3所示，为元数据请求处理流程图。在分布式文件系统中各个存储节点上运行namenode服务，然后在客户端需要进行元数据请求时，进行负载均衡，确定出目标存储节点。由目标存储节点上的namenode服务接收所述客户端发送的hdfs namenode支持的第一元数据请求。所述目标存储节点上的namenode服务解析所述第一元数据请求，获取请求参数，然后查询所述目标存储节点上的namenode服务的缓存中是否包括对应的元数据，如果是，则将查询到的元数据返回客户端。如果未查询到，则将第一元数据请求转化成对象存储的第二元数据请求。向对象存储池查询对应的元数据。将利用lru算法将查询到元数据存储到目标存储节点上的namenode服务的缓存中，并将查询到的元数据返回客户端。
73.参见图4所示，本申请实施例公开了一种元数据请求处理装置，应用于分布式文件系统中的目标存储节点，包括：
74.namenode服务中的请求接收模块11，用于接收所述分布式文件系统对应的客户端发送的第一元数据请求，其中，所述第一元数据请求为hdfs namenode支持的请求，所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点，所述分布式文件系统中的各个存储节点上均运行有所述namenode服务；
75.所述namenode服务中的查询模块12，用于从所述namenode服务的缓存中查询所述第一元数据请求对应的元数据；
76.所述namenode服务中的请求转换模块13，用于在从所述namenode服务的缓存中未查询到所述第一元数据请求对应的元数据，则将所述第一元数据请求转化为第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求；
77.所述namenode服务中的数据缓存模块14，用于将从所述对象存储池中查询到的所述元数据存储到所述namenode服务的缓存中；
78.所述namenode服务中的数据发送模块15，用于将查询到的所述元数据返回所述客户端。
79.可见，本申请应用于分布式文件系统中的目标存储节点，首先通过本地的namenode服务接收所述分布式文件系统对应的客户端发送的第一元数据请求，其中，所述第一元数据请求为hdfs namenode支持的请求，所述目标存储节点为基于预设负载均衡算法从所述分布式文件系统中的各个存储节点中确定出的节点，所述分布式文件系统中的各个存储节点上均运行有所述namenode服务。然后再通过本地的所述namenode服务从本地的所述namenode服务的缓存中查询所述第一元数据请求对应的元数据。如果从本地的所述namenode服务的缓存中未查询到所述第一元数据请求对应的元数据，则通过本地的所述namenode服务将所述第一元数据请求转化为第二元数据请求，以便利用所述第二元数据请求从所述分布式文件系统中的对象存储池中查询所述元数据，其中，所述对象存储池为基于ceph构建的、用于进行对象存储的存储池，所述第二元数据请求为对象存储支持的请求。通过本地的所述namenode服务将从所述对象存储池中查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。由此可见，在本申请所述的分布式文件系统中各个存储节点上均运行有namenode服务，当需要处理对应的客户端的元数据请求时，便可以利用负载均衡算法从中确定出目标存储节点，然后由目标存储节点处理该元数据请求，这样分布式文件系统中的各个存储节点均运行有namenode服务，便可以解决现有技术中由于namenode中心化到来的分布式文件系统性能瓶颈，提高了分布式文件系统的容灾能力，且在处理元数据请求时，可以进行负载均衡，有不同存储节点上的namenode服务分担元数据请求处理压力，降低单个存储节点上的namenode服务的负载压力，提高分布式文件系统的性能。且目标存储节点上的namenode服务接收到对应的客户端发送的hdfs namenode支持的第一元数据请求之后，便可以先对namenode服务的缓存进行查询，看是否存在第一元数据请求对应的元数据，如果不存在，便需要将第一元数据转换成对象存储支持的第二元数据请求，然后从分布式文件系统中ceph构建的、用于进行对象存储的存储池中查询对应的元数据，并将查询到的所述元数据存储到本地的所述namenode服务的缓存中，并将所述元数据返回给所述客户端。这样分布式文件系统中完全可以兼容现
有的hadoop和ceph，通过对象存储池实现各个存储节点之间的元数据共享，从而支持各个存储节点上的namenode服务运行，也解决了现有技术中存储元数据受限于namenode节点的内存总容量的问题，且在各个存储节点上的namenode服务中引入缓存，可以进一步提高分布式文件系统的响应性能。
80.在一些具体的实施过程中，所述数据发送模块15，用于：
81.在从所述namenode服务的缓存中查询到所述第一元数据请求对应的元数据时，则将所述元数据返回给所述客户端，并更新所述元数据的热度参数。
82.在一些具体的实施过程中，所述查询模块12，用于：
83.对所述第一元数据请求进行解析；
84.根据解析结果从所述namenode服务的缓存中查询所述第一元数据请求对应的元数据。
85.在一些具体的实施过程中，所述预设负载均衡算法为轮询算法、随机法、加权轮询法及最小连接数法中的任一项。
86.在一些具体的实施过程中，所述元数据请求处理装置，还包括：
87.所述namenode服务中的轮询模块，用于按照预设时间间隔对本地的所述namenode服务的缓存中的各条元数据的热度参数进行轮询；将热度参数小于预设热度参数阈值的元数据从所述namenode服务的缓存中删除。
88.在一些具体的实施过程中，所述数据缓存模块14，用于：
89.利用lru算法将从所述对象存储池中查询到的所述元数据存储到所述namenode服务的缓存中，并更新所述元数据的热度参数。
90.进一步的，参见图5所示，本申请实施例还公开了一种电子设备，包括：处理器21和存储器22。
91.其中，所述存储器，用于存储计算机程序；所述处理器，用于执行所述计算机程序，以实现前述实施例中公开的元数据请求处理方法。
92.其中，关于上述元数据请求处理方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
93.进一步的，本申请实施例还公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述任一实施例中公开的元数据请求处理方法。
94.其中，关于上述元数据请求处理方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
95.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
96.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd
‑
rom、或技术领域内所公知的任意其它形式的存储介质中。
97.最后，还需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或者操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得一系列包含其他要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
98.以上对本申请所提供的一种元数据请求处理方法、装置、设备、介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。