一种Ceph对象存储元数据处理的优化方法及装置与流程

一种ceph对象存储元数据处理的优化方法及装置
【技术领域】
1.本发明涉及分布式存储之对象存储技术领域，特别是涉及一种ceph对象存储元数据处理的优化方法及装置。


背景技术：

2.随着云计算、大数据、移动互联、社交网络的快速发展，企业信息化的非结构化数据呈现爆炸式的增长。然而，面临数据激增，传统存储在企业数字化转型中已成为瓶颈，选择更合适的存储技术成为it基础设施建设的必选项。相对于传统的文件系统存储，对象存储以对象作为数据存储单元，舍弃了文件系统元数据管理的特性，将所有对象通过扁平化的关键字取值方式进行数据存储，大大简化了元数据管理的复杂度。
3.ceph是一款统一的、优秀的开源分布式存储系统，既支持传统的块、文件存储协议，也支持新兴的对象存储协议，同时具备高可用、高可扩展性、高性能的特性，因此在各领域都有广泛的使用。
4.ceph对象存储中的数据类型，分为两大类。一类是元数据，是描述对象数据属性的数据，用来指示对象数据的存储位置、历史数据、资源查找、文件记录等功能的数据，主要包括用户元数据、存储桶元数据、对象索引元数据等；另一类是真正的对象数据，即用户上传的数据，是对用户有意义的、真正可见的数据，如一张图片、一份文档、一段视频等。当前，ceph对象存储对元数据和对象数据进行统一管理，通过同一个存储引擎(即原生的存储引擎)进行读写，将两类数据保存到物理硬盘上。如果要对某个对象数据进行操作，需要通过原生的存储引擎，先从物理硬盘上加载相关的元数据，然后再查找对象数据的索引，最后再根据索引找到目标对象数据在磁盘中的存储位置进行读写操作。当数据量较大时(比如存入了海量的小文件对象数据)，从硬盘上读取巨大的索引并进行查找是相当耗时的，导致海量文件场景下对象存储的读写性能较差。
5.鉴于此，克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。


技术实现要素：

6.本发明要解决的技术问题是：
7.现有技术的ceph对象存储对元数据和对象数据进行统一管理，通过同一个存储引擎(即原生的存储引擎)进行读写，将两类数据保存到物理硬盘上。如果要对某个对象数据进行操作，需要通过原生的存储引擎，先从物理硬盘上加载相关的元数据，然后再查找对象数据的索引，最后再根据索引找到目标对象数据在磁盘中的存储位置进行读写操作。当数据量较大时(比如存入了海量的小文件对象数据)，从硬盘上读取巨大的索引并进行查找是相当耗时的，导致海量文件场景下对象存储的读写性能较差。
8.本发明采用如下技术方案：
9.第一方面，本发明提供了一种ceph对象存储元数据处理的优化方法，包括：
10.判断请求操作的数据类型；
11.若请求操作的数据类型为元数据，则调用元数据存储引擎与内存中的数据库进行交互完成相应的操作；
12.若请求操作的数据类型为对象数据，则调用原生的存储引擎与物理硬盘进行交互完成相应的操作。
13.优选的，所述元数据存储引擎与原生的存储引擎处于同一逻辑层；
14.上层应用调用接口适配层中的指定类和函数，根据数据类型是元数据或对象数据作为分支条件，在相应的分支下调用元数据存储引擎或者原生的存储引擎处理操作请求；
15.其中，所述分支条件和分支下调用的动作在接口适配层实现中增加，从而保持接口适配层对外的定义不变。
16.优选的，所述元数据存储引擎包括外部接口层、中间转换层和驱动层，具体的：
17.所述外部接口层，向上一级的接口适配层提供可被调用的标准功能接口；
18.所述中间转换层，为各个内存中的数据库抽象出统一的标准操作接口，供所述外部接口层调用，并且所述中间转换层还对接驱动层中的各个内存中的数据库的驱动模块；
19.所述驱动层，用于针对各个内存中的数据库，实现对应访问各个内存中的数据库的驱动模块。
20.优选的，若是写入/读取元数据，则调用元数据存储引擎相应的标准功能接口，经过中间转换层和驱动层后，在内存中的数据库中写入/读取元数据。
21.优选的，若是读取对象数据，根据操作请求中携带的信息调用元数据存储引擎，从内存中的数据库中获取相应的元数据；
22.根据从内存中的数据库中获取的元数据，调用原生的存储引擎从磁盘中读取对象数据。
23.优选的，若是写入对象数据，根据操作请求中携带的信息调用元数据存储引擎，从内存中的数据库中获取相应的元数据；
24.根据从内存中的数据库中获取的元数据，调用原生的存储引擎在磁盘中写入对象数据，并得到在磁盘中写入所述对象数据而新增的元数据；
25.调用元数据存储引擎将所述新增的元数据写入内存中的数据库。
26.优选的，还包括初始化过程，具体为：
27.在初始化过程中通过元数据存储引擎提供的外部接口层、中间转换层和驱动层里的驱动模块，启动相应的内存中的数据库；
28.内存中的数据库在启动过程中，会读取持久化保存在物理硬盘上的所有元数据，并将从物理硬盘上读取的所有元数据加载到待启动的内存中的数据库中。
29.优选的，还包括，通过元数据存储引擎中的异步线程，将内存中的数据库中的元数据周期性的写入到物理硬盘中进行持久化保存，防止节点异常掉电或服务异常退出导致元数据丢失。
30.优选的，所述元数据包括集群元数据和用户元数据信息；
31.所述集群元数据包括realm区域、zonegroup命名空间组和zone命名空间中的一项或者多项；
32.所述用户元数据信息包括user用户元数据、acl访问控制列表元数据、quota配额元数据、object对象元数据和bucket_index存储桶索引元数据中的一项或者多项。
33.第二方面，本发明还提供了一种ceph对象存储元数据处理的优化装置，包括至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被程序设置为执行第一方面所述的ceph对象存储元数据处理的优化方法。
34.本发明的有益效果为：
35.本发明将元数据的操作和对象数据的操作进行分离，若请求操作的数据类型为元数据，则调用新增的元数据存储引擎与内存中的数据库进行交互完成相应的操作；若请求操作的数据类型为对象数据，则调用原生的存储引擎与物理硬盘进行交互完成相应的操作。由于元数据的操作是使用新增的元数据存储引擎与内存中的数据库进行交互完成的，而内存读写效率远高于物理硬盘，因此可以有效提高处理效率，以此来支撑海量文件下的对象存储应用场景。
36.进一步，新增元数据存储引擎后，仅需修改接口适配层的内部实现，接口定义保持不变，因此上层业务系统直接调用接口适配层的接口，不感知此变动，对业务系统的影响最小化。另外，由于元数据存储引擎在设计上采用了驱动层，驱动层可以适配多种内存中的数据库，灵活可配，使用者可根据实际需要对后端使用的内存中的数据库进行选择。
【附图说明】
37.为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
38.图1是本发明实施例提供的一种ceph对象存储元数据处理的优化方法的流程；
39.图2是本发明实施例提供的一种ceph对象存储元数据处理的优化方法的元数据存储引擎的架构图；
40.图3是本发明实施例提供的一种ceph对象存储元数据处理的优化方法的架构图；
41.图4是本发明实施例提供的一种ceph对象存储元数据处理的优化方法的时序图；
42.图5是本发明实施例提供的一种ceph对象存储元数据处理的优化方法的架构图；
43.图6是本发明实施例提供的一种ceph对象存储元数据处理的优化装置的框架图。
【具体实施方式】
44.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
45.在本发明的描述中，术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不应当理解为对本发明的限制。
46.此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
47.实施例1:
48.本发明实施例1提供了一种ceph对象存储元数据处理的优化方法，如图1所示，包括：
49.步骤1：判断请求操作的数据类型；接口适配层获取操作请求后，会根据请求操作的数据类型调用不同的存储引擎来执行相应的操作请求。
50.步骤2：若请求操作的数据类型为元数据，则调用元数据存储引擎与内存中的数据库进行交互完成相应的操作；元数据存储引擎从架构上可以分为3层，分别为外部接口层、中间转换层和驱动层。
51.外部接口层，作为元数据存储引擎对外的窗口，通过定义若干标准功能接口，向上一级的接口适配层暴露元数据存储引擎能够提供的功能。当接口适配层需要使用元数据存储引擎提供的功能时，只需调用外部接口层提供的标准功能接口即可。接口适配层无需关注元数据存储引擎内部的实现和处理细节，其中，标准功能接口包括：同步数据到物理硬盘、管理后端数据库服务起停、用户元数据管理类、存储桶元数据管理类、对象元数据管理类和索引元数据管理类中的一种或者多种。所述用户元数据管理类，定义了用户元数据增删改查操作；所述存储桶元数据管理类，定义了存储桶元数据增删改查操作；所述对象元数据管理类，定义了对象元数据增删查改操作；所述索引元数据管理类，定义了索引元数据增删查改操作。
52.中间转换层，对接驱动层中的各内存型的数据库的驱动文件，为后端的各个内存型的数据库(内存型的数据库即为以内存为存储介质的数据库，即内存中的数据库)抽象出统一的标准操作接口供外部接口层调用，因此只需要实现标准操作接口，就可以把各内存型的数据库以即插即用的形式整合到对象存储的系统中。所述外部接口层根据操作类型统一调用标准操作接口进行处理；操作类型包括增删查改等，标准操作接口也包括增删查改，若操作类型为查，则外部接口层相应的调用标准操作接口中的dbop::driver-》get_key()函数(该函数为标准操作接口中的查询接口)；由于中间转换层的存在，每当适配了一种新的数据库时，外部接口层不感知这个变化，只需要统一调用中间转换层抽象出的统一的标准操作接口即可。
53.驱动层，根据中间转换层定义的标准操作接口，为各种内存型的数据库封装了对应的数据库操作接口供中间转换层调用，每一个内存型的数据库对应一个驱动文件。
54.步骤3：若请求操作的数据类型为对象数据，则调用原生的存储引擎与物理硬盘进行交互完成相应的操作。
55.本实施例提供一种实际场景中可实现的方式，如图2-3所示，ceph对象存储包括对象存储网关，对象存储网关包括前端处理层和后端数据处理层，其中，前端处理层包括http server模块、restapi通用处理层、handler模块和op操作模块(operation操作模块)；后端数据处理层包括接口适配层、元数据存储引擎和原生的存储引擎，其中，元数据存储引擎与原生的存储引擎处于同一逻辑层，所述元数据存储引擎包括外部接口层、中间转换层和驱动层，具体为：
56.假设本次操作请求为：如图4所示，查询key为“user_key”的用户的元数据。若是写入/读取元数据，则调用元数据存储引擎相应的标准功能接口，经过中间转换层和驱动层后，在内存中的数据库中写入/读取元数据。
57.对象存储网关接收到客户端发送过来的查询某个用户的操作请求后，判断出本次
请求操作的数据类型是元数据。
58.操作请求顺次经过对象存储网关的http server模块、restapi通用处理层、handler模块和op操作模块后，op操作模块调用接口适配层相应的存储引擎执行操作。
59.接口适配层根据请求操作的数据类型的不同选取不用的代码分支，从而调用不同的存储引擎执行查询(即读取)的操作请求：
60.由于此次请求操作的数据类型为查询用户元数据，因此接口适配层调用元数据存储引擎的外部接口层定义的相应的标准功能接口，具体的，调用标准功能接口中的用户元数据管理类中的usermetaop::get(user_key)函数执行查询的操作请求，其中，参数user_key为该用户的key。
61.由于此次操作类型为查询操作，因此usermetaop::get(user_key)函数会继续调用中间转换层的标准操作接口中的dbop::driver-》get_key(user_key)函数执行查询操作。然后中间转换层会根据预先配置的驱动文件调用驱动文件中定义的相应数据库操作接口，以便从驱动文件对应的内存型的数据库中查询用户元数据。假设预先配置的驱动文件为redis.cc，驱动文件redis.cc包含了redis数据库的各种数据库操作接口，因此中间转换层会继续调用驱动文件redis.cc中的相应数据库操作接口从内存型的redis数据库中查询用户元数据，并将查询到的用户元数据逐层向上返回。其中，内存型的数据库包括：redis数据库、leveldb、rocks、tikv数据库和xedis等，在此不一一赘述。另外，本实施例仅仅是举例说明，并不用于限定本发明。
62.所述元数据存储引擎与原生的存储引擎处于同一逻辑层；上层应用调用接口适配层中的指定类和函数，根据数据类型是元数据或对象数据作为分支条件，在相应的分支下调用元数据存储引擎或者原生的存储引擎处理操作请求；其中，所述分支条件和分支下调用的动作在接口适配层实现中增加，从而保持接口适配层定义不变。
63.op操作模块直接交互的是接口适配层，在接口适配层的内部，根据数据类型是元数据或对象数据作为分支条件，在相应的分支下调用元数据存储引擎或者原生的存储引擎处理操作请求，如：接口适配层原生的一个接口函数为func a，接口函数func a传入的参数是预先定义好的，不会因为内部实现方式多增加了一条分支而发生变化。op操作模块会直接调用接口函数func a，接口函数func a内部的具体实现根据数据类型是元数据或对象数据作为分支条件分为两个分支，其中一个分支是调用原生的存储引擎执行对象数据的操作请求，另一个分支是调用元数据存储引擎执行元数据的操作请求。由于所述分支条件和分支下调用的动作在接口适配层的实现中增加的，可以保持接口适配层定义不变，因此op操作模块调用接口函数为func a时不感知此变化。这将有利于降低对业务系统的影响。
64.所述元数据存储引擎包括外部接口层、中间转换层和驱动层，具体的：所述外部接口层，向上一级的接口适配层提供可被调用的标准功能接口；
65.所述中间转换层，为各个内存中的数据库抽象出统一的标准操作接口，供所述外部接口层调用，并且所述中间转换层还对接驱动层中的各个内存中的数据库的驱动模块；
66.所述中间转换层，为各个内存中的数据库抽象出统一的标准操作接口，供所述外部接口层调用，具体包括：中间转换层为后端的各个内存中的数据库抽象出统一的标准操作接口，所述外部接口层统一调用标准操作接口进行处理；每当适配了一种新的内存中的数据库时，所述外部接口层不感知新的内存中的数据库的适配。
67.所述驱动层，用于针对各个内存中的数据库，实现对应访问各个内存中的数据库的驱动模块。
68.驱动层，根据中间转换层定义的标准操作接口，为各种内存型的数据库封装了对应的数据库操作接口，每一个内存型的数据库对应一个驱动文件。
69.还包括初始化过程，具体为：在初始化过程中通过元数据存储引擎提供的外部接口层、中间转换层和驱动层里的驱动模块，启动相应的内存中的数据库；内存中的数据库在启动过程中，会读取持久化保存在物理硬盘上的所有元数据，并将从物理硬盘上读取的所有元数据加载到待启动的内存中的数据库中。
70.启动ceph对象存储的对象存储网关后，首先会对各类全局变量、工作线程进行初始化，并注册各类资源管理器和资源处理器。其中，对象存储网关对工作线程进行初始化时，包括元数据管理工作线程的初始化过程，在元数据管理工作线程的初始化过程中，会通过外部接口层提供的标准功能接口中的管理后端数据库服务起停、中间转换层和驱动层的驱动文件，实现相应的内存中的数据库的启动。内存中的数据库在启动过程中会读取持久化保存在物理硬盘上的所有元数据，并将从物理硬盘上读取的所有元数据加载到待启动的内存中的数据库中。
71.为了防止节点掉电或者服务异常退出导致内存型的数据库中的元数据丢失。
72.还包括，通过元数据存储引擎中的异步线程，将内存中的数据库中的元数据周期性的写入到物理硬盘中进行持久化保存，防止节点异常掉电或服务异常退出导致元数据丢失。
73.具体包括：在对象存储网关的主线程运行过程中，元数据存储引擎的异步线程，周期性的(如一小时一次)将内存中的数据库中的元数据，写入到物理硬盘中进行持久化保存，防止节点异常掉电或服务异常退出导致元数据丢失；在对象存储网关的主线程退出时，也会触发元数据存储引擎的异步线程将内存型的数据库中的元数据全部落盘，以便下一次对象存储网关启动时，内存型的数据库初始化加载持久化保存在物理硬盘上的所有元数据。
74.所述元数据包括集群元数据和用户元数据信息；所述集群元数据包括realm区域、zonegroup命名空间组和zone命名空间中的一项或者多项；所述用户元数据信息包括user用户元数据、acl访问控制列表元数据、quota配额元数据、object对象元数据和bucket_index存储桶索引元数据中的一项或者多项。
75.实施例2：
76.为了进一步理解本发明，在实施例1的基础上，本发明还提供了一种实际场景中可实现的方式，本实施例假设使用内存型的redis数据库来存储元数据。如图5所示，包括三个网关节点，分别为网关节点1、网关节点2和网关节点3，每个网关节点均包括redis server(redis server是redis数据库的服务实例)和对象存储网关，其中，三个网关节点采用一主两备的redis数据库集群部署模式。整个redis数据库集群，由网关节点1作为主节点对外提供服务，网关节点2和网关节点3两个备节点定期从主节点同步元数据。备节点只作为热备，当主节点故障时，会自动进行主备切换。redis server和对象存储网关部署在3台服务器上，另有若干台服务器(最少3台)部署rados系统的osd和monitor。对象存储网关通过元数据存储引擎与redis数据库集群交互完成元数据的操作请求，通过原生的存储引擎与osd交
互完成对象数据的操作请求。
77.假设本实施例想要通过s3协议创建一个用户。
78.首先需要通过radosgw-admin工具(该工具是ceph对象存储的命令行管理工具)创建一个s3用户，并将创建好的用户元数据保存在内存型的redis数据库中。下面以创建demo用户为例，说明该实施例的具体流程。
79.步骤s11：启动ceph对象存储网关服务后，首先会对各类全局变量、工作线程进行初始化，并注册各类资源管理器和资源处理器。
80.步骤s12：对象存储网关初始化元数据管理工作线程。在初始化过程中，该线程通过元数据存储引擎提供的标准功能接口中的管理后端数据库服务起停、中间转换层和驱动层中的驱动文件redis.cc，启动redis数据库。redis数据库在启动过程中，会读取持久化保存在物理硬盘上的所有元数据，并将从物理硬盘上读取的所有元数据加载到待启动的内存中的数据库中。如图5所示，备节点会定期从主节点同步元数据。这些元数据都是以key-value的形式保存，存放在运行有redis server的节点的内存当中。
81.步骤s13：通过radosgw-admin工具，将创建用户的操作请求发送到对象存储网关，操作请求中携带本次需要创建的用户的用户名demo。对象存储网关接收到操作请求后，对操作请求做进一步解析。通过radosgw-admin工具发送过来的操作请求，会交由admin类型的资源管理器进行处理。由于本次请求是对用户资源做创建操作，因此可以得到对应的资源管理器实例rgwrestmgr_user和资源处理器实例rgwhandler_user和操作对象实例rgwop_user_create。
82.步骤s14：操作对象实例rgwop_user_create对操作请求预处理，主要是执行鉴权检查及操作权限认证。
83.步骤s14-1：先对创建用户的操作请求进行鉴权。由于radosgw-admin工具是通过内置的admin账号进行相关操作的，所以本次创建用户的操作请求直接鉴权通过。
84.步骤s14-2：然后将操作请求中携带的用户名demo作为key，通过接口适配层，调用元数据存储引擎提供的标准功能接口中的用户元数据管理类定义的查询操作，即调用usermetaop::get(demo)函数，经过中间转换层和驱动层的驱动文件redis.cc，转换成适用于redis数据库的语句进行查询，查询内存型的redis数据库中是否已经存在用户名demo。
85.步骤s14-3：如果不存在，则继续执行创建用户的操作请求。
86.步骤s15：创建demo用户并将用户元数据保存到redis数据库中。
87.步骤s15-1：执行操作对象实例rgwop_user_create创建demo用户。用户创建完成后，会得到demo用户的各类元数据，包括id(demo)、accesskey(用户标识用户的身份，如：9ish6l9ks061dx0bgd1j)、secretkey(作为私钥形式保存在服务器上，如：uk9c4wyquhxdo78gj3t3em2el8upllpaah49hxxx)、用户操作权限掩码op_mask(如“read,write,delete”)、用户配额(“user_quota”：{“enabled”：false，“max_size_kb”：-1,“max_objects”：-1})、存储桶配额(“bucket_quota”：{“enabled”：false，“max_size_kb”：-1,“max_objects”：-1})等。
88.步骤s15-2：步骤s15-1得到的元数据通过接口适配层，调用元数据存储引擎提供的标准功能接口中的用户元数据管理类，经过中间转换层和驱动层的驱动文件redis.cc，转换成适用于redis数据库的增的语句并进行增的操作，将demo用户元数据信息以key＝“demo”，value＝{{“id”，“demo”}，{“accesskey”，“9ish6l9ks061dx0bgd1j”}，
…
{
…
}}这样
的形式保存到redis数据库中。
89.步骤s16：通过元数据存储引擎中的异步线程，将redis数据库在内存中的用户元数据，周期性的写入到物理硬盘中进行持久化保存，防止节点异常掉电或服务异常退出导致元数据丢失。
90.实施例3：
91.为了进一步理解本发明，在实施例1的基础上，本发明还提供了一种实际场景中可实现的方式，本实施例以上传本地文件的对象数据file1.txt到存储桶bucket01中为例进行说明，本实施例假设使用内存型的redis数据库来存储元数据。
92.存储桶是对象数据的容器，上传对象数据前必须具备存储桶。假设现在demo用户已经创建了一个名为bucket01的存储桶，该存储桶具有公共读写权限，且容量配额为100gb。在客户端服务器上，安装s3cmd工具(s3cmd是用于创建s3存储桶，上传、检索和管理数据到对象存储系统的命令行程序)，并进行相关配置，主要是设定s3存储的服务端地址和端口，以及demo用户的accesskey和secretkey，以便执行上传对象数据的操作请求：下面以上传本地文件的对象数据file1.txt到存储桶bucket01中为例，说明该实施例的具体流程。
93.步骤21：启动ceph对象存储网关服务后，首先会对各类全局变量、工作线程进行初始化，并注册各类资源管理器和资源处理器。
94.步骤s22：对象存储网关初始化元数据管理工作线程。在初始化过程中，该线程通过元数据存储引擎提供的标准功能接口中的管理后端数据库服务起停、中间转换层和驱动层中的驱动文件redis.cc，启动redis数据库。redis数据库在启动过程中，会读取持久化保存在物理硬盘上的所有元数据，并将从物理硬盘上读取的所有元数据加载到待启动的数据库中。如图5所示，备节点会定期从主节点同步元数据。这些元数据都是以key-value的形式，存放在运行有redis server的节点的内存当中。
95.步骤s23：通过s3cmd工具，将上传本地文件的对象数据file1.txt到存储桶bucket01的操作请求s3cmd put file1.txt s3://bucket01/file1.obj发送到对象存储网关。对象存储网关接收到操作请求后，对操作请求做进一步解析。解析得到上传本地文件的对象数据的操作请求中包括了存储桶名称bucket01、保存在rados系统中使用的对象数据的名称file1.obj(对象数据的名称可以和待上传的对象数据的源文件的名称不同，由用户自行指定)和源文件file1.txt。
96.通过s3cmd工具发送过来的操作请求，会交由s3类型的资源管理器进行处理。因此可以得到对应的资源管理器实例rgwrestmgr_s3，资源处理器实例rgwhandler_rest_service_s3(用来获取所有的存储桶列表)、rgwhandler_rest_bucket_s3(对单个存储桶进行操作和管理)、rgwhandler_rest_obj_s3(对对象数据进行操作和管理)和创建对象数据的操作对象实例rgwputobj。
97.步骤s25：操作对象实例rgwputobj对上传本地文件的对象数据file1.txt到存储桶bucket01的操作请求进行认证和鉴权。操作请求的头部，携带有客户端的签名信息，例如client signature＝9isu+ty4soqz+9xcskpse5nrpdm＝。本地服务端会根据已保存的secretkey，计算出对应用户的合法的签名信息，并与操作请求传过来签名信息进行比较。二者一致则表示认证和鉴权成功，之后转至步骤s26。如果认证和鉴权失败，则会退出本次操作请求的处理过程。
98.步骤s26：若是写入对象数据，根据操作请求中携带的信息调用元数据存储引擎，从内存中的数据库中获取相应的元数据；
99.将操作请求中携带的用户名demo、存储桶名称bucket01和对象数据的名称file1.obj作为key，通过接口适配层，调用元数据存储引擎提供的标准功能接口中的用户元数据管理类、存储桶元数据管理类和对象元数据管理类中定义的查操作，即分别调用usermetaop::get(demo)函数、buckmetaop::get(bucket01)函数和objmetaop::get(file1.obj)函数,经过中间转换层和驱动层的驱动文件redis.cc，转换成适用于redis数据库的语句进行查询，获取demo用户和存储桶bucket01的元数据，主要包括用户的配额信息、用户的操作权限掩码op_mask、存储桶的索引信息、存储桶的配额信息、存储桶的acl访问控制列表信息等；以及查询file1.obj的元数据是否存在于redis数据库，将获取的元数据返回给接口适配层。
100.步骤s27：接口适配层根据步骤s26中获取的用户操作权限掩码op_mask，判断demo用户是否具备数据写入存储桶的操作权限；并校验本次需写入存储桶的对象数据的大小是否会超过demo用户和存储桶bucket01的配额限制。如果本次操作请求验证通过，则跳转至步骤s28；如果没有，则退出本次操作请求的处理过程。
101.步骤s28：根据从内存中的数据库中获取的元数据，调用原生的存储引擎在磁盘中写入对象数据，并得到在磁盘中写入所述对象数据而新增的元数据；
102.接口适配层进一步根据步骤s26中获取的存储桶的索引信息和待上传的对象数据的名称file1.txt，使用crush算法，计算出对象数据存放的目标物理位置，包括存储节点的信息(节点的ip或主机名)和磁盘的信息(对应osd服务的id)。然后接口适配层通过调用原生的存储引擎，与目标存储节点对应的osd守护进程建立tcp连接并进行交互，将对象数据写入目标磁盘对应的位置，并得到在目标磁盘中写入对象数据file1.txt而新增的元数据。
103.步骤s29：调用元数据存储引擎将所述新增的元数据写入内存中的数据库；
104.对象数据file1.txt写入完成后，可得到对象数据file1.txt写入目标磁盘后新增的元数据，包括对象数据的大小(单位：字节)、修改时间、实体标签etag信息等，再通过接口适配层，调用元数据存储引擎提供的标准功能接口中的对象元数据管理类，经过中间转换层和驱动层的redis驱动文件redis.cc，转换成适用于redis数据库的增的语句并进行增的操作，将对象数据file1.obj对应的元数据以key＝“file1.obj”，value＝{{“obj_size”，“100”}，{“mtime”，“2021-07-0417:26:30.000000”}，{“etag”，“45a62d3d5d3e946250904697486591bc”}，
…
{
…
}}这样的形式保存到redis数据库中。增加完元数据后，将本次写的操作请求的执行结果返回给客户端。另外，通过元数据存储引擎中的异步线程，将redis数据库在内存中的用户元数据，周期性的写入到物理硬盘中进行持久化保存，防止节点异常掉电或服务异常退出导致元数据丢失。
105.若是读取对象数据，根据操作请求中携带的信息调用元数据存储引擎，从内存中的数据库中获取相应的元数据；根据从内存中的数据库中获取的元数据，调用原生的存储引擎从磁盘中读取对象数据。
106.实施例4：
107.在上述实施例1-3提供的ceph对象存储元数据处理的优化方法的基础上，本发明还提供了一种可用于实现上述方法的ceph对象存储元数据处理的优化装置，如图6所示，是
本发明实施例的装置架构示意图。本实施例的ceph对象存储元数据处理的优化装置包括一个或多个处理器31以及存储器32。其中，图6中以一个处理器31为例。
108.所述处理器31和所述存储器32可以通过总线或者其他方式连接，图6中以通过总线连接为例。
109.所述存储器32作为一种ceph对象存储元数据处理的优化方法非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1-3中的ceph对象存储元数据处理的优化方法。所述处理器31通过运行存储在所述存储器32中的非易失性软件程序、指令以及模块，从而执行ceph对象存储元数据处理的优化装置的各种功能应用以及数据处理，即实现实施例1-3的ceph对象存储元数据处理的优化方法。
110.所述存储器32可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，所述存储器32可选包括相对于所述处理器31远程设置的存储器，这些远程存储器可以通过网络连接至所述处理器31。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
111.所述程序指令/模块存储在所述存储器32中，当被所述一个或者多个处理器31执行时，执行上述实施例1-3中的ceph对象存储元数据处理的优化方法，例如，执行以上描述的图1所示的各个步骤。
112.本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(rom，read only memory)、随机存取存储器(ram，random access memory)、磁盘或光盘等。
113.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。