CN117785997A - 数据处理方法及装置 - Google Patents

Abstract

本公开涉及一种数据处理方法及装置，该方法包括：通过智能网卡中的网卡模块接收客户端发送的数据操作请求；调用智能网卡中的请求解析模块对数据操作请求得到待处理数据和数据操作类型信息，并将待处理数据和数据操作类型信息输入至智能网卡中的执行引擎模块，由执行引擎模块基于所述待处理数据执行数据操作类型信息所指示的操作得到数据操作结果；调用请求分析模块对数据操作结果进行封装得到数据操作请求的应答，并通过网卡模块向客户端发送数据操作请求的应答。通过将服务器的CPU的一些工作负载迁移至智能网卡，由智能网卡处理客户端发送的数据操作请求，且对客户端节点呈现了数据库的访问抽象，有效降低服务器的CPU的处理压力。

Description

数据处理方法及装置

技术领域

本公开涉及数据处理技术领域，尤其涉及一种数据处理方法及装置。

背景技术

键值数据库(KV-store，简称KVS)是一种新型的非关系型数据库(NoSQLdatabase)，主要以键值对(key-value)的形式存储数据。在数据存储上，由于键值数据库相对于传统关系型数据库更加灵活；在访问接口上，键值数据库使用写入(PUT)、读取(GET)等简单的数据访问接口，即可满足大量的业务需求，因此，键值数据库在各个领域中被广泛应用。

随着互联网的快速发展，网络使用呈现的爆发式增长，数据库的访问压力不断正大，针对数据库的高并发访问场景，如数百数千用户同时访问时，会导致数据库性能下降，因此，如何提高键值数据库的性能是当前亟待解决的问题。

发明内容

为了解决上述技术问题，本公开提供了一种数据处理方法及装置。

第一方面，本公开提供了一种数据处理方法，包括：

通过智能网卡中的网卡模块接收客户端发送的数据操作请求；

调用所述智能网卡中的请求分析模块对所述数据操作请求进行解析得到待处理数据和数据操作类型信息，并将所述待处理数据和所述数据操作类型信息输入至所述智能网卡中的执行引擎模块；

调用所述执行引擎模块基于所述待处理数据执行所述数据操作类型信息所指示的数据操作得到数据操作结果；

调用所述请求分析模块对所述数据操作结果进行封装得到所述数据操作请求的应答，并通过所述网卡模块向所述客户端发送所述数据操作请求的应答。

第二方面，本公开提供一种数据处理装置，包括：

网卡模块，用于接收客户端发送的数据操作请求；

请求分析模块，用于对接收的所述数据操作请求进行解析得到待处理数据和数据操作类型信息，并将所述待处理数据和所述数据操作类型信息输入至执行引擎模块；

执行引擎模块，用于基于所述待处理数据执行所述数据操作类型信息指示的数据操作得到数据操作结果；

所述请求分析模块，还用于对所述数据操作结果进行封装得到所述数据操作请求的应答；

所述网卡模块，还用于向客户端发送所述数据操作请求的应答。

第三方面，本公开提供一种电子设备，包括：存储器和处理器；

所述存储器被配置为存储计算机程序指令；

所述处理器被配置为执行所述计算机程序指令，使得所述电子设备实现如第一方面所述的数据处理方法。

第四方面，本公开提供一种可读存储介质，包括：计算机程序指令，电子设备的至少一个处理器执行所述计算机程序指令，使得所述电子设备实现如第一方面所述的数据处理方法。

第五方面，本公开提供一种计算机程序产品，当所述计算机程序产品被电子设备执行时，使得所述电子设备实现如第一方面所述的数据处理方法。

本公开提供一种数据处理方法及装置，其中，该方法包括：通过智能网卡中的网卡模块接收客户端发送的数据操作请求；调用智能网卡中的请求解析模块对数据操作请求得到待处理数据和数据操作类型信息，并将待处理数据和数据操作类型信息输入至智能网卡中的执行引擎模块，由执行引擎模块基于所述待处理数据执行数据操作类型信息所指示的数据操作得到数据操作结果；调用请求分析模块对数据操作结果进行封装得到数据操作请求的应答，并通过网卡模块向客户端发送数据操作请求的应答。通过将服务器的CPU的一些工作负载迁移至智能网卡中，由智能网卡处理客户端发送的数据操作请求，通过智能网卡对客户端节点呈现了针对数据库的访问抽象，而不必要求服务器CPU参与数据操作请求的处理，有效降低服务器的CPU的处理压力。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本公开一实施例提供的数据处理***的框架示意图；

图2为本公开一实施例提供的数据操作请求/应答的数据结构图；

图3为本公开一实施例提供的数据处理方法的流程示意图；

图4为本公开另一实施例提供的数据处理***的框架示意图；

图5为本公开示例性地示出了哈希索引机制的框架示意图；

图6为本公开示例性示出的索引结构中索引槽的数据结构示意图；

图7为本公开另一实施例提供的数据处理方法的流程示意图；

图8为本公开一实施例提供的数据存储方式的示意；

图9为本公开一实施例提供的数据处理***的结构示意图；

图10为本公开一实施例提供的内存分配器所采用的内存管理机制的结构示意图；

图11为本公开另一实施例提供的数据处理***的结构示意图；

图12为本公开一实施例提供的数据中继站的结构示意图；

图13为本公开另一实施例提供的数据处理方法的流程示意图；

图14为本公开另一实施例提供的数据处理方法的流程示意图；

图15为本公开另一实施例提供的数据处理方法的流程示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

KVS以其独特的优势，在很多领域得到了广泛的应用。目前，为了支持更高性能的数据存储与访问，将业务以及应用部署在内存键值数据库中成为一种新的解决方案。

随着分布式***设计的快速发展，分布式内存键值数据库成为新的研究热点方向。分布式内存键值数据库通过网络传输数据，且允许数据存储在多个节点上，这不仅提供了更大的键值数据对存储空间，而且具有更灵活的扩展能力(即动态加入或删除存储服务节点)。

远程直接内存访问(Remote Direct Memory Access，RDMA)技术具有高带宽、低延迟的特点，它与KVS追求高吞吐、低延迟的目标不谋而合。此外，RDMA技术除了支持类似传统套接字(socket)网络传输机制的双边消息语义，还支持单边内存语义。

其中，采用双边消息语义进行数据处理主要交互过程如下：客户端节点将操作请求发送给服务端节点，服务端节点在本地执行相应的PUT/GET等数据操作，并将操作结果返回给客户端节点。客户端节点收到服务端节点反馈的结果后操作完成。

其中，单边内存语义是指客户端可以直接以服务端旁路(server-bypass)的方式读写服务端的内存空间的访问方式，单边通过内存语义，为分布式***构建共享内存和类load/store的应用程序接口(API)提供了更加便捷的途径。采用单边内存语义进行数据处理主要交互过程如下：对于GET操作，使用RDMA READ动作来完成键值对数据的读取；对于PUT操作，需要合理组合RDMA ATOMIC、RDMA WRITE和RDMA READ动作来支持一致的数据写入。在单边内存语义场景中，服务端节点除了参与数据存储和初始的通信建立，后续关键数据路径上基本不需要做出响应。

基于双边消息语义和单边内存语义的内存KVS各有优势。双边消息语义可以支持更加丰富灵活的接口定义(因为数据操作过程可以对用户侧隐藏)，而单边内存语义可以实现单次网络往返(RTT)下更加快速高效的数据访问。

但传统的基于RDMA的内存键值数据库至少存在以下问题：

1、服务端节点的CPU处理瓶颈问题。

采用基于双边消息语义RPC机制的内存键值数据库需要将操作请求发送给服务端节点，服务端节点的CPU负责执行具体的数据存储逻辑，并将数据操作结果返回给客户端。这种处理机制会导致高并发场景(如数百甚至数千客户端同时访问)下服务端节点CPU成为关键路径上的性能瓶颈，进而可能会产生较高的尾延迟。这不仅仅是由于单服务器的多核频率限制，而且和CPU与网卡的交互模式有关。服务端节点的CPU不仅要为每一个客户端节点的数据操作请求提前准备接收请求工作(recv work request，RECV WR)和负责轮询完成队列(completion queue，CQ)，还要处理操作请求，拷贝数据，准备发送请求工作(sendwork request，SEND WR)等，这就产生了许多的额外的访问开销。此外，由于服务端节点CPU是执行KVS访问的核心器件，就必然需要在服务器上部署更加昂贵高效的CPU组件以及适配的主板等。这与时下云计算领域所倡导的计存分离架构思想(即计算资源与存储资源解耦，存储节点专注于数据存储即可)相背离，难以做到存储节点的低总成本(total cost ofownership，TCO)控制。

2、复杂的KVS访问协议实现与多次网络往返开销。

采用基于单边内存语义的内存键值数据库允许客户端进行索引查询并定位相应键值对数据所在服务端节点的内存地址，通过READ和WRITE等动作完成GET/PUT操作。然而，这不仅要求客户端节点缓存服务端节点键值对数据的索引结构，而且对并发操作的一致性提出了更高的挑战：需要把传统的服务端节点中心化一致性保障机制升级为分布式一致性保障，更复杂也更难以保证正确性。而且即便像通过组合多个WRITE、ATOMIC、READ操作支持一致性的数据写入操作，也存在多次网络往返开销。由于缺乏事务支持，RDMA提供的内存级别抽象并不适合构建高效的KVS。

3、对硬件带宽的利用效率较低，存在吞吐性能瓶颈。

硬件带宽如网卡线速、PCIe带宽、内存带宽等决定了内存键值数据库访问的上限。而上述部分已经提到，无论是基于双边消息语义还是单边内存语义的内存键值数据库***都存在性能瓶颈(CPU处理瓶颈、多次网络往返)。这就使得它们无法高效利用硬件的带宽资源。例如，当CPU成为处理瓶颈时，内存带宽和网络带宽存在浪费；当网络往返成为瓶颈时，PCIe带宽和网络带宽存在浪费。自然地，带宽浪费就会导致吞吐率存在瓶颈，无法支撑理想状态下高效内存键值数据库的构建。

随着互联网技术的不断发展，支持RDMA技术的网卡(NIC，如RoCE、InifinibandHCA等)在网络部署上逐渐普及开来。与此同时，数据中心正在出现另一个关于硬件加速的进化趋势。越来越多的数据中心服务器上装配了智能网卡(SmartNIC，又可称为可编程网卡)。智能网卡的核心组件是一个现场可编程门阵列(FPGA)，它带有一个嵌入式网卡芯片以连接到网络，还有一个PCIe连接器以连接到服务器(host)。

因此，本公开提供的数据处理方法，通过将服务器的CPU的一些工作负载迁移至智能网卡中，由智能网卡中的FPGA作为处理器芯片，处理客户端发送的数据操作请求，通过智能网卡对客户端节点呈现了KVS的访问抽象，而不必要求服务器的CPU参与数据操作请求的处理过程，有效降低服务器的CPU的处理压力，此外，对于PUT/GET操作均支持一次网络往返的操作延迟，最大化利用网络带宽来提升访问吞吐率。需要说明的是，针对存在类似问题的数据库，本公开提供的数据处理方法同样适用。

接下来，通过一些实施例，结合附图以及场景，对本公开提供的数据处理方法进行详细介绍。其中，数据处理方法可以由本公开提供的数据处理装置执行，该装置可以通过任意的软件和/或硬件的方式实现，例如，其可以为软件***。在下述实施例中，以数据处理装置为数据处理***，且服务器中部署的数据库为内存键值数据库为例进行说明。

图1为本公开一实施例提供的数据处理***的架构示意图。请参阅图1所示，数据处理***100部署在智能网卡中，数据处理***100能够访问并操作服务器的内存中的数据库。其中，智能网卡中的网卡模块，主要用于接收客户端发送的数据操作请求发送给数据处理***100相应的模块以及将数据处理***100生成的应答传递给客户端。

其中，数据处理***100可以包括：请求分析模块101和执行引擎模块102。请求分析模块101主要用于对智能网卡中的网卡模块传输的数据操作请求进行解析识别与封装传递。其中，请求分析模块101可以包括：请求译码器101a和请求编码器101b，请求译码器101a主要用于从网卡模块中获取客户端发送的数据操作请求进行解析识别；请求编码器101b主要用于根据执行引擎模块102传递的数据操作结果进行数据封装得到数据操作请求的应答并传递给网卡模块，通过网卡模块将应答反馈给客户端。

执行引擎模块102主要用于根据客户端发送的数据操作请求所指示的数据操作类型执行相应的动作(如写入/读取/删除等等数据操作)，并将数据操作结果传递给请求分析模块101。执行引擎模块102可以与服务器的内存交互，实现针对键值对数据的操作。

作为一种可能的实施方式，请求分析模块101中的请求译码器101a和请求编码器101b可以共用相同的数据结构，即数据操作请求和数据操作结果可以共用相同的数据结构。请参阅图2所示，图2示例性地示出数据操作请求/应答所共用的数据结构的示意图。

其中，数据操作请求/应答可以包括：事务标识信息、组成本次事务的总请求/应答的数量信息、本请求在所有请求/应答中的顺序信息、数据操作类型、本次事务对应的键的总长度、本次事务的值的总长度、本次请求/应答所包含的键的长度、本次请求/应答所包含的值的长度、用于容纳本次事务的全部或者部分键数据的字段、用于容纳本次事务的全部或者部分值数据的字段、校验信息等等中的一项或者多项。

本公开实施例中，对于数据操作请求/应答的数据量大小不做限定，如，可以为32字节大小、64字节大小、128字节大小等等，示例性地，图2所示实施例中以数据操作请求/应答可以采用64字节大小为例进行举例说明。具体地，可以包括一个4字节的TxID字段(指代一个全局唯一的事务ID，该事务ID可以由用户指定)，2字节的Num字段(指示组成本次事务的总请求/应答数量，从而可以应对变长key和value)，2字节的Seq字段(指示本请求/应答在本事务的所有请求/应答中的次序，用于收到所有请求或应答后的数据拼接)，2字节的Opcode字段(指明数据操作类型，如读取/写入/删除等)，2字节的Tkey_len字段(指示本次事务的key总长度，可跨多个请求)，2字节的Tvalue_len字段(指示本次事务的value总长度，可跨多个请求/应答)，1字节的Key_len字段(本次请求包含的key长度)，1字节的Value_len字段(本次请求/应答包含的value长度)，16字节的Key字段(容纳本次事务的全部或部分key数据)，24字节的Value字段(容纳本次事务的全部或部分value数据)和8字节的Checksum字段(即校验信息，可以为单个请求的校验和，用于网络传输后核对请求/应答数据的完整性、准确性)。

图3为本申请一实施例提供的数据处理方法的流程示意图。参照图3所示，本实施例提供的方法包括：

S301、通过智能网卡中的网卡模块接收客户端发送的数据操作请求。

S302、调用智能网卡中的请求分析模块对数据操作请求进行解析得到待处理数据和数据操作类型信息，并将待处理数据和数据操作类型信息输入至智能网卡中的执行引擎模块。

结合图1所示，智能网卡的网卡模块可以接收客户端发送的数据操作请求，并将数据操作请求传输至请求译码器，由请求译码器对数据操作请求进行解析得到数据操作请求对应的数据结构中的数据操作类型、键值对数据等等信息。

在一些实施例中，客户端可以向数据处理***发送单独的数据操作请求，相应地，数据处理***的请求译码器可以通过解析该单独的数据操作请求，获取其中的信息，并执行相应的动作。

在另一些实施例中，客户端可以向数据处理***发送多个数据操作请求，使得数据处理***通过对多个数据操作请求进行聚合，从而针对超长键值对数据执行相应的动作。示例性地，结合图2所示的数据结构，数据处理***的请求译码器可以解析识别多个数据操作请求，获取各数据操作请求中的TxID字段、Seq字段以及Checksum字段等等，再基于多个数据操作请求中的TxID识别是否属于同一事务，通过Seq字段还原各数据操作请求的顺序，并利用Checksum字段检查数据一致性，从而实现超长键值对数据的数据操作。其中，请求译码器可以对多个具有相同事务标识的数据操作请求分别进行解析得到多个Key字段，再按照Seq字段所指示的顺序将多个Key字段进行拼接得到该事务对应的待处理数据。且具有相同事务标识的数据操作请求中指示的数据操作类型是一致的。需要说明的是，若执行数据操作请求需要Value字段，则还可以按照上述方式将解析得到的Value字段进行拼接。

S303、通过调用智能网卡中的执行引擎模块基于待处理数据执行数据操作类型信息所指示的数据操作得到数据操作结果。

数据操作请求可以为数据读请求、数据写请求或者数据删除请求，数据处理***的执行引擎模块可以基于数据操作请求所指示的数据操作类型执行读操作、写操作或者删除操作，获取相应的数据操作结果。

若数据操作请求为数据读请求，执行引擎模块获取的数据操作结果可以为读取到的待处理数据所指示的目标数据(如value数据)；若数据操作请求为数据写入操作，执行引擎模块获取的数据操作结果可以为写入成功/失败的信息；若数据操作请求为数据删除请求，执行引擎模块获取的数据操作结果可以为删除成功/失败的信息。

S304、调用请求分析模块对数据操作结果进行封装得到所述数据操作请求的应答。

请求编码器可以将数据操作结果填充至数据操作请求对应的数据结构的指定字段中得到应答。

以图2所示实施例的数据结构为例：

示例性地，若数据操作请求为数据读请求，请求编码器可以将读取的value数据(即数据操作结果)填充至数据操作请求对应的数据结构中的Value字段中得到数据操作请求的应答。

作为一种可能的实施方式，若数据读请求是针对超长键值对数据的操作，读取的value数据的数据量可能较大，由于数据操作请求中相应字段的大小无法满足读取的value数据的数据量，则可以根据读取的value数据的数据量创建多个应答结构，以满足读取的value数据。

例如，结合图2所示的数据结构，value字段为24字节，若读取的value数据小于24字节，则将读取的value数据写入value字段中即可；若读取的value数据大于24字节，则可以创建多个所需应答结构，再将读取的value数据写入多个应答结构分别对应的value字段中。

若数据操作请求为数据写请求或者数据删除请求，请求编码器可以将图2所示数据结构中的用于指示数据操作类型中的字段(Opcode字段)修改为ack/null，代表写入/删除操作成功/失败。其中，ack可以表示写入/删除操作成功，null可以表示写入/删除操作失败。

需要说明的是，此处所示的复用数据结构的实现方式仅为示例，请求/应答的数据结构以及复用方式还可以通过其他方式实现，本公开对此不做限定。

S305、通过网卡模块向客户端发送数据操作请求的应答。

其中，请求编码器将封装好的应答传递给智能网卡的网卡模块，通过网卡模块将应答传输给客户端。客户端接收到应答后，对应答进行解析，可以先匹配TxID字段，然后检查Opcode字段确认数据操作类型，如有需要再去Value字段获取数据。例如，数据操作请求为数据读请求时，可以获取Value字段中的数据，若数据操作请求为数据写请求/数据删除请求时，客户端可以获取Opcode字段，确定数据写入/删除是否成功。

本实施例提供的方法，通过将服务器的CPU的一些工作负载迁移至智能网卡，由智能网卡处理客户端发送的数据操作请求，且对客户端节点呈现了数据库的访问抽象，有效降低服务器的CPU的处理压力。此外，应答复用数据操作请求的数据结构，通过该数据结构复用机制能够极大减少服务器的空间分配和数据拷贝开销。此外，支持聚合的多数据操作请求的数据结构是缓存对齐的，因此，在数据传输时能够减小边界不对齐导致的网络传输开销，避免读写放大问题。

从存储的角度来说，键值数据库可以包括两部分：索引结构和键值对数据，其中，键值对数据是用户执行数据操作的目标对象，索引结构是用于查找请求键值对数据存储位置的检索数据结构。

图4为本公开一实施例提供的数据处理***的架构示意图。参照图4所示，本实施例提供的数据处理***在图1所示实施例的基础上，还包括：索引模块103。其中，索引模块103可以设置在智能网卡的内存中，索引模块103中包括键值对数据对应的索引信息，而索引信息指向的键值对数据可以存储在服务器的内存(即host memory，以下称为服务器的内存)中。

在智能网卡的内存中设置索引模块103用于存储索引结构的情况下，调用执行引擎模块102处理客户端发送的数据操作请求时还可能执行引擎模块102需要与索引模块103进行交互。

其中，本公开对于索引结构的具体实现方式不做限定。作为一种可能的实施方式，索引结构可以采用哈希索引结构，如：链式哈希索引结构、cuckoo哈希索引结构、hopscotch哈希索引结构等等，当然，索引结构还可以采用二叉树、radix tree、B树、B+树、红黑树等结构。

本实施例中，为了提升智能网卡的内存利用率，索引结构可以采用子索引结构组织以及多路索引机制的方式实现。其中，子索引结构组织表示索引结构由多个子索引结构组成，每个子索引结构可以包括多个索引槽，每个索引槽中可以用于存储键值对数据的相关信息。多路索引机制表示采用预设的多种映射方式将数据操作请求映射至多个子索引结构。通过子索引结构组织和多路索引机制，能够实现针对索引结构访问的负载均衡处理，从而避免大量访问同一索引结构导致访问压力较大。

当索引结构采用哈希索引结构实现时，索引结构可以包括多个哈希桶，在处理数据操作请求时采用多路哈希的方式进行映射。其中，图5示例性地以哈希桶和两路哈希的方式为例示出哈希索引机制的示意图。

请参阅图5所示的两个哈希桶，分别为哈希桶X和哈希桶Y，其中，哈希桶X和哈希桶Y可以是缓存对齐的，从而可以利用缓存的空间局部性大大减少访问同一个哈希桶的访问开销。每个哈希桶可以包括：多个索引槽、用于指示桶内的各索引槽是否为空闲槽的字段、以及用于指示桶内的索引槽是否被线程占用的字段。

假设一个哈希桶大小为64字节，且哈希桶是缓存对齐时，每个哈希桶可以包含4字节的元数据：1字节Bitmap字段(每个比特位代表对应的桶内索引槽是否为空闲槽，0为空闲，1为占用)，1字节Lockmap字段(每个比特位代表对应的桶内索引槽是否被某一线程占用，0为空闲，1为占用)，2字节Padding字段(该字段为无意义比特位，仅用于对齐4字节)。每个哈希桶内可以包含4个15字节的索引槽，每个索引槽可以用于存储一条键值对数据的索引信息。

需要说明的是，本公开对于各哈希桶包括的索引槽的数量不做限定，各哈希桶分别包括的索引槽的数量可以是相同的，也可以是不同的，索引槽数量不同时，可通过调整元数据的字节大小，从而保证元数据能够完整地表示全部索引槽的状态。此外，采用多路哈希索引机制，本公开对于映射方式的数量及实现不做限定。

为了减小键值对数据的访问和存储开销，索引结构可以采用内联存储机制实现，即将满足预设条件的键值对数据内联地存储在索引槽中，客户端需要访问这些内联存储的键值对数据时，可以通过访问索引结构实现，从而无需访问服务器的内存，无需通过智能网卡与服务器之间的PCIe数据通道，进而减小服务器的访问与存储压力。

作为一种可能的实施方式，可以根据键值对数据的属性信息确定键值对数据是否满足内联存储机制的要求。此处提及键值对数据的属性信息可以包括但不限于：特定字段的数据类型(如int8、int16、int32、int64、float32、float64、sring等等)、数据量大小等等。

示例性地，图6为本公开示例性示出的索引结构中索引槽的数据结构示意图。请参阅图6所示，采用内联存储机制时，索引槽可以包括用于指示键值对数据的数据类型的字段、用于指示键和值的存储类型的字段、用于存储键的相关信息的字段以及用于存储值的相关信息的字段。本公开对于各字段的字节大小不做限定。

结合前述图5所示实施例，图6所示实施例以索引槽为15字节为例进行示例说明。其中，索引槽包括4个字段，分别为：6比特用于指示数据类型的字段(也可以称为type字段)、2比特用于指示键和值的相关信息存储方式的字段(也可以称为Flag字段)、8字节用于存储键的相关信息的字段(也可以称为key-info字段)以及6字节用于存储值的相关信息的字段(也可以称为value-info字段)。

Flag字段可以有三种取值：01、10、11。其中，Flag字段取值为01时，表示键值对数据中的键和值均可以内联地存储在索引槽中。Flag字段取值为10时，表示键值对数据中的键可以内联的存储在索引槽中，但键值对数据中的值不可以内联地存储在索引槽中。Flag字段取值为11时，表示键值对数据中的键和值均不可以内联地存储在索引槽中。

请参阅图6所示的4个索引槽，其中，索引槽1中存储Int32类型的数据以及索引槽2中存储的string类型的数据，键和值的字节大小均满足key-info字段和value-info字段的字节大小限制，因此，键和值内联存储在索引槽中。

索引槽3中存储的int64类型的数据，键满足key-info字段的字节大小限制，但值大于6字节，无法满足value-info字段的字节大小限制，因此，键可以内联地存储在索引槽的key-info字段中，value-info字段则可以填充键值对数据对应的指针信息，即键值对数据存储在指针信息所指向的服务器的内存中。

索引槽4中存储的string类型的数据，键的字节大小无法满足key-info字段的字节大小限制，因此，键值对数据需要采用非内联存储的方式。参照图6所示，key-info字段可以用于存储键值对数据中键的指纹摘要信息，其中，键的指纹摘要信息可以通过对键进行映射获得的满足key-info字段的字节大小限制的数据，例如，通过对键进行哈希计算的方式进行映射，当然也可以采用其他方式进行映射，获取键的指纹摘要信息。value-info字段则可以填充键值对数据对应的指针信息，即键值对数据存储在指针信息所指向的服务器的内存中。

接下来，通过图7至图9所示实施例，详细介绍在智能网卡的内存中设置索引模块，且索引模块中的索引结构采用如前所述的哈希桶、多路哈希以及采用了内联存储机制实现的情况下，数据处理***如何处理客户端发送的数据读请求、数据写请求以及数据删除请求。

图7为本公开一实施例提供的数据处理方法的流程图。请参阅图7所示，本实施例提供的方法包括：

S701、通过智能网卡中的网卡模块接收客户端发送的数据操作请求。

S702、调用智能网卡中的请求分析模块对数据操作请求进行解析得到待处理数据和数据操作类型信息，并将待处理数据和数据操作类型信息输入至智能网卡中的执行引擎模块。

步骤S701、S702分别与图3所示实施例中步骤S301、S302类似，可参照图3所示实施例的详细描述，简明起见，此处不再赘述。

S703、调用执行引擎模块基于待处理数据从智能网卡包括的内存中存储的索引结构中确定待处理数据对应的目标索引槽。

其中，确定目标索引槽可以但不限于通过下述方式实现：

步骤a、调用执行引擎模块对待处理数据进行哈希计算得到哈希值，基于哈希值在索引结构中进行匹配得到匹配成功的哈希桶。

其中，数据处理***可以采用一种或多种哈希算法匹配哈希桶。其中，待处理数据为键值对数据时，可以通过对待处理键值对数据中的键采用多种的哈希算法进行计算得到多个哈希值，基于多个哈希值匹配到多个哈希桶。

步骤b、调用执行引擎模块基于待处理数据在匹配成功的哈希桶包括的索引槽中进行匹配得到匹配结果，基于匹配结果确定目标索引槽。

示例性地，当数据操作请求为数据读请求或者数据删除请求时，可以根据待处理键值对数据中的键或者键的指纹摘要信息在多个匹配成功的哈希桶中进行匹配，匹配成功的索引槽即为目标索引槽。

示例性地，当数据操作请求为数据写请求时，可根据多个匹配成功的哈希桶中索引槽的占用情况或者其他因素，为待处理数据分配一个空闲的索引槽作为目标索引槽，结合前述图5所示实施例，索引槽的占用情况可通过哈希桶的Bitmap字段中各比特位为0或者1获得。在一些情况下，当数据操作请求为修改数据的数据写请求，则要修改的数据所对应的索引槽即为目标索引槽。

其中，在哈希桶中进行匹配，可基于待处理数据的属性信息来判断是采用待处理数据进行匹配还是待处理数据的指纹摘要信息进行匹配。

作为一种可能的实施方式，若待处理键值对数据中的键满足内联存储的要求，则调用执行引擎模块根据待处理键值对数据中的键在哈希桶包括的各索引槽中进行匹配，确定索引槽中所填充的键的相关信息与待处理键值对的键相匹配的索引槽为目标索引槽。例如，结合图6所示实施例中的数据结构，确定key-info字段中填充的键与待处理键值对数据中的键一致的索引槽为目标索引槽。

作为另一种可能的实施方式，若待处理键值对数据中的键不满足内联存储的要求，则调用执行引擎模块根据待处理键值对数据中的键的指纹摘要信息在哈希桶包括的各索引槽中进行匹配，确定索引槽中所填充的键的相关信息与待处理键值对的键的指纹摘要信息相匹配的索引槽为目标索引槽。例如，结合图6所示实施例中的数据结构，确定key-info字段中填充的键的指纹摘要信息待处理键值对数据中的键的指纹摘要信息一致的索引槽为目标索引槽。

S704、调用执行引擎模块针对目标索引槽执行数据操作类型信息指示的数据操作得到数据操作结果。

根据不同的数据操作请求，并结合索引采用内联以及非内联存储方式，通过几种不同的情形示例说明数据处理***的执行引擎模块如何执行数据操作请求。

情形一、数据操作请求为数据读请求，目标索引槽中的Flag字段为01。

目标索引槽中的Flag字段为01，则表明要读取的键值对数据内联地存储在目标索引槽中，调用执行引擎模块可以从目标索引槽中的value-info字段中读取value数据。且执行引擎模块可以根据目标索引槽中的type字段确定value数据的数据类型。

情形二、数据操作请求为数据读请求，目标索引槽中的Flag字段为10或者11。

目标索引槽中的Flag字段为10或者11，则表明要读取的键值对数据存储在服务器的内存中，调用执行引擎模块可以从目标索引槽中的value-info字段中读取指针信息，并根据指针信息从服务器的内存中读取value数据。且执行引擎模块可以根据目标索引槽中的type字段确定value数据的数据类型。

情形三、数据操作请求为数据删除请求，目标索引槽中的Flag字段为01。

目标索引槽中的Flag字段为01，则表明要删除的键值对数据内联地存储在目标索引槽中，调用执行引擎模块可以释放该目标索引槽，从而完成数据删除。

情形四、数据操作请求为数据删除请求，目标索引槽中的Flag字段为10或者11。

目标索引槽中的Flag字段为10或者11，则表明要删除的键值对数据存储在服务器的内存中，调用执行引擎模块可以从目标索引槽中的value-info字段中读取指针信息，并删除服务器的内存中指针信息指向的内存中的键值对数据释放键值对数据所占用的服务器的内存。且调用执行引擎模块释放该目标索引槽，从而完成数据删除。

情形五、数据操作请求为数据写请求，待处理键值对数据中的键和值可以采用内联存储。

调用执行引擎模块向目标索引槽中的Flag字段填充为01；向目标索引槽中的type字段中填充待处理键值对数据的数据类型；将待处理键值对数据中的键填充至key-info字段；将待处理键值对数据中的值填充至value-info字段。

情形六、数据操作请求为数据写请求，待处理键值对数据中的键可以采用内联存储，值采用非内联存储。

调用执行引擎模块向目标索引槽中的Flag字段填充为10；向目标索引槽中的type字段中填充待处理键值对数据的数据类型；将待处理键值对数据中的键填充至key-info字段；为待处理键值对数据分配服务器的内存，根据所分配的服务器的内存的地址生成指针信息，将指针信息填充至value-info字段。调用执行引擎模块将待处理键值对数据传递给服务器存储至所分配的服务器的内存中。

情形七、数据操作请求为数据写请求，待处理键值对数据的键采用非内联存储。

待处理键值对数据中的键采用非内联存储的情况下，待处理键值对数据中的值也采用非内联存储，且目标索引槽中需要存储待处理键值对数据中的键的指纹摘要信息以及指针信息。因此，调用执行引擎模块可将目标索引槽中的Flag字段填充为11；在目标索引槽中的type字段中填充待处理键值对数据的数据类型；将待处理键值对数据中的键的指纹摘要信息填充至key-info字段；为待处理键值对数据分配服务器的内存，根据所分配的服务器的内存的地址生成指针信息，将指针信息填充至value-info字段。调用执行引擎模块将待处理键值对数据传递给服务器存储至所分配的服务器的内存中。

作为一种可能的实施方式，服务器的内存可以支持以下两种方式的数据存储：

方式一、若键值对数据中的键采用内联存储，且根据键值对数据的数据类型可以确定数据长度，则在服务器的内存中可以只存储待处理键值对数据中的值。示例性地，服务器的内存中键值对数据采用方式一存储时，数据结构可以如图8中方式一所示。

方式二、若键值对数据中的键采用非内联存储，或者，键值对数据中的键采用内联存储，且根据键值对数据的数据类型无法确定数据长度，则在服务器的内存中不仅需要存储键值对数据的键和值，还需要存储键的数据长度和值的数据长度。示例性地，服务器的内存中键值对数据采用方式二存储时，数据结构可以如图8中方式二所示。需要说明的是，采用方式二存储键值对数据时，数据结构也可以采用其他方式，例如，先存储键值对数据，再存储键值对数据的键的数据长度信息以及值的数据长度信息，或者，还可以按照键值对数据中的键、键的数据长度信息、键值对数据中的值、值的长度信息的顺序存储，本公开对此不做限定。

服务器的内存采用方式一存储键值对数据，能够免去键值对数据中的键和相关数据不必要的内存空间占用开销，从而能够提升服务器的内存的利用率。此外，对于方式二，通过在服务器的内存中存储数据长度的信息，数据处理***的执行引擎能够正确处理数据的访问边界，使得客户端发送的数据操作请求能够保证被正确处理，不会出现错误。

结合前述情形二所示的场景中，若要读取的数据采用方式一存储，则从服务器的内存中读取键值对数据中的值，若要读取的数据采用方式二存储，则执行引擎从服务器的内存中读取键值对数据以及键值对数据的数据长度信息；在前述情形四所示的场景中，若要删除的数据采用方式一存储，则从服务器的内存中删除存储的键值对数据中的值，若要删除的数据采用方式二存储，则从服务器的内存中删除键值对数据以及键值对数据的数据长度信息；在情形六以及情形七所示的场景中，若满足方式一的要求，则可以将键值对数据中的键存储至服务器的内存中，若满足方式二的要求，则将键值对数据以及键值对数据的数据长度信息均存储至服务器的内存中。

S705、调用请求分析模块对所述数据操作结果进行封装得到所述数据操作请求的应答。

S706、通过网卡模块向客户端发送数据操作请求的应答。

本实施例中S705、S706分别与图3所示实施例中S304、S305类似，可参照图3所示实施例中的详细描述，简明起见，此处不再赘述。

本实施例中，数据处理***通过子索引结构组织以及多路索引的方式，利用子索引结构缓存的空间局部性大大减小访问同一个子索引结构而带来的访问开销，有效提升智能网卡的内存利用率。此外，索引结构采用内联存储机制实现，能够优化小键值对数据的访问和存储开销，从而减小服务器的内存的访问压力，有效提升数据处理效率。

结合前述图7所示实施例中步骤S705中情形五至情形七的描述，待处理数据需要写入服务器的内存中，智能网卡需要与服务器进行交互请求服务器分配内存空间用于数据写入，若针对每一次数据写入操作均单独请求服务器，则智能网卡需要频繁地与服务器的CPU进行交互，这会成为键值对数据操作的性能瓶颈。为了解决该问题，本公开通过在数据处理***中设置内存分配器，内存分配器可以采用预申请以及slab管理相结合的方式实现近网卡的主机内存管理。

其中，图9为本公开一实施例提供的数据处理***的结构示意图。参照图9所示，本实施例提供的数据处理***在图4所示实施例的基础上，还包括：内存分配器104。

其中，内存分配器104设置在智能网卡的内存中，主要负责从服务器的主机内存中申请空闲存储空间并进行管理。数据处理***中设置有内存分配器104的情况下，执行引擎模块102在处理客户端发送的数据操作请求时还可能需要与内存分配器104进行交互。

作为一种可能的实施方式，内存分配器104在存储资源不足时，会与服务器CPU进行交互，申请预设大小的内存空间，预设大小不限定，例如，可以一次申请数百兆的大段内存空间。

其中，内存分配器104可以采用slab管理机制进行服务器的内存的本地管理。具体地，内存分配器104可以采用不同阶(order)管理不同大小的空闲内存，每个阶代表一个内存块为固定大小的链表结构。

例如，参照图10所示的管理机制的结构示意图，内存分配器104包括11个阶，分别为第0阶至第10阶，第0阶至第10阶依次代表内存块大小为8B、16B、32B、64B、128B、256B、512B、1KB、2KB、4KB、8KB的链表结构，在上述11个阶中，最大可以支持8KB的内存分配(去除一些元数据的干扰，可支持最大4KB的键值对数据存储)。

需要说明的是，采用slab管理机制时，设置的阶数以及各阶分别对应的内存块大小可以根据实际需求设定，上述图10所示实施例仅为示例，并不是对于内存分配器104管理主机内存的实现方式的限制。

通过内存分配器的服务器的内存本地管理机制，当数据处理***实现键值对数据删除、写入时，可以通过操作内存分配器完成服务器的内存资源的分配与释放，而不必与服务器CPU进行交互，显著减小数据处理***的整体性能开销，从而降低操作延迟，提高吞吐率。

结合前文各实施例可知，执行引擎模块102为数据处理装置100中连接其他组成模块的核心功能模块。为了进一步提高数据处理***执行数据操作请求的处理效率，本公开提供的数据处理装置100中，可以在智能网卡中设置数据中继站，减小热的键值对数据的操作所造成的对服务器的内存的多次访问，从而优化数据处理***的整体性能。其中，图11为本公开一实施例提供的数据处理***的结构示意图。请参阅图11所示，数据处理装置100还包括：设置在智能网卡的内存中的数据中继站105。

数据中继站105主要用于缓存满足预设要求的键值对数据，当执行引擎模块102执行数据操作请求时，执行引擎模块102可以先访问的数据中继站进行匹配。例如，数据中继站中可以缓存数据量满足预设要求(如键和值的长度均在8字节以内的键值对数据)。

作为一种可能的实施方式，数据中继站105可以采用基于链式哈希索引的结构实现，采用该结构，对于同样的键的操作，每次都可以映射到固定的链表中进行匹配。

其中，图12示例性地示出了数据中继站的结构示意图，数据中继站105中包括多个链表结构，每个链表结构对应一标识(如图12中所示的哈希ID)，通过对待处理键值对数据中的键进行哈希算法处理得到哈希值，根据哈希值查询各链表分别对应的哈希ID，即可映射到相应的目标链表结构，并在目标链表结构中执行操作。

其中，执行引擎模块102在处理数据读请求时，可以先在数据中继站105中进行匹配，确定数据中继站105中是否存在相匹配的键；若匹配成功，则返回该键对应的最新版本的值；若匹配失败，则可以返回null，以指示数据中继站105中不存在相应的键。

执行引擎模块102处理数据写请求和数据删除请求时，执行引擎模块102会向哈希到的目标链表结构中原子地添加一个数据项，数据项包括：用于指示数据操作类型的字段、用于容纳键的字段以及用于容纳值的字段；此外，执行引擎模块102还会删除目标链表结构中相同键的数据项。

接下来，通过图13至图15所示实施例分别详细介绍通过图11所示实施例的数据处理***如何实现数据读取、数据删除以及数据写入。

图13为本公开一实施例提供的数据处理方法的流程图。请参阅图13所示，本实施例中，客户端发送的数据操作请求为数据读请求，当数据处理***接收到客户端发送的数据读请求，通过请求译码器解析得到待处理键值对数据以及数据操作类型的信息并传递给执行引擎模块，执行引擎模块首先需要判断数据读请求中键是否满足内联存储的要求，例如，可根据键的大小判断，假设在8字节以内，则满足内联存储要求，大于8字节则不满足内联存储要求。

若键满足内联存储要求，则调用执行引擎模块访问数据中继站，查看数据中继站中是否有对应键的最新版本的值，如查询到相应的数据项，则返回最新版本的值。

若键满足内联存储要求，但在数据中继站中未查询到对应键最新版本的值，则调用执行引擎模块访问索引模块，查询索引结构，通过两种哈希算法映射到两个哈希桶，并根据键在哈希到的两个哈希桶中进行匹配确定目标索引槽。接下来，根据目标索引槽中的Flag字段和type字段确定要读取的数据的长度以及要从何处读取数据。若Flag字段的取值为01，则从目标索引槽中读取type信息确定值的数据长度，并从目标索引槽中读取值，之后，再解锁目标索引槽；若Flag字段的取值为10，则从目标索引槽中读取指针信息，并根据指针信息从服务器的内存中读取键值对数据。

若键不满足内联存储要求，则首先需要通过两种哈希算法映射到两个哈希桶(本实施例中以两个哈希桶为例进行举例)，再计算键的指纹摘要信息，根据键的指纹摘要信息在哈希到的哈希桶中进行匹配，确定目标索引槽。需要说明的是，在匹配的过程中，键的指纹摘要信息可能与多个索引槽相匹配，即目标索引槽的数量可能为多个。接下来，根据目标索引槽中的指针信息，从服务器的内存中读取键值对数据，若服务器的内存中读取的键值对数据的键也完全匹配，则将从服务器的内存中读取的值返回，若服务器的内存中读取的键值对数据的键不匹配，则继续匹配下一个目标索引槽，重复上述过程。

图14为本公开一实施例提供的数据处理方法的流程图。请参阅图14所示，本实施例中，客户端发送的数据操作请求为数据写请求，当数据处理***接收到客户端发送的数据写请求，通过请求译码器解析通过请求译码器解析得到待处理键值对数据以及数据操作类型的信息并传递给执行引擎模块，执行引擎模块首先需要判断数据写请求中键是否满足内联存储的要求，例如，可根据键的大小判断，假设在8字节以内，则满足内联存储要求，大于8字节则不满足内联存储要求。

若键满足内联存储的要求，则需要进一步判断要写入的键值对数据是否为小键值对数据，若是小键值对数据则需要写入数据中继站中，若不是小键值对数据则需要将数据写入目标索引槽或服务器的内存。

具体地，若值的大小满足预设要求(预设要求例如为8字节大小)，则将键哈希到数据中继站中的目标链表结构，且在目标链表结构的表头添加一个PUT数据项，接着遍历目标链表结构删除所有包含该键的数据项，完成上述流程即可返回，后续步骤可异步执行。

其中，图14中所示需要异步执行的步骤与值不满足预设要求的情形执行引擎模块同步执行的步骤相同，即通过对键通过两种哈希算法将键哈希到两个哈希桶(图14所示实施例以2个哈希桶为例进行举例说明)，并根据键在两个哈希桶中匹配，如果匹配成功，则释放该旧的键值对数据占用的服务器的内存空间。接着，执行引擎模块判断值是否满足内联存储的要求，例如，在图5所示实施例的索引槽的数据结构的基础上，可以通过判断值是否小于6字节，确定值是否满足内联存储的要求；若确定值可以内存存储，则根据键值对数据填充目标索引槽，并返回；若确定值不可以内联存储，则需要通过内存分配器确定内存资源是否充足。若内存资源充足，则直接为键值对数据分配内存空间，并在分配的内存空间中填充键值对数据，然后填充目标索引槽并返回；若内存资源不充足，则请求服务器CPU预分配一段内存资源(请求分配的内存资源的大小可灵活设置)，然后对该段内存资源建立分阶管理，然后为要写入的键值对数据分配内存空间，并在分配的内存空间中填充键值对，然后填充索引槽并返回。

若键不满足内联存储的要求，执行引擎模块可以通过对键进行哈希算法处理，将键哈希到两个哈希桶(图14所示实施例以2个哈希桶为例进行举例说明)，接着，计算键的指纹摘要信息，并根据键的指纹摘要信息在哈希桶内匹配索引槽；若匹配成功，则执行引擎模块从服务器的内存读取相应的键值对数据匹配键是否一致，若一致，则执行引擎模块释放旧的键值对数据所占用的内存空间，接着执行键值对数据的写入流程；若根据键的指纹摘要信息在两个哈希桶内均未匹配成功，则为当前要写入的键值对数据分配并锁定一个空闲索引槽，接着执行键值对数据的写入流程。

其中，键值对数据的写入流程可参照前述异步执行的步骤中根据值的大小是否满足内联存储的要求进行写入的相关描述，简明起见，此处不再赘述。

图15为本公开一实施例提供的数据处理方法的流程图。请参阅图15所示，本实施例中，客户端发送的数据操作请求为数据删除请求，当数据处理***接收到客户端发送的数据删除请求，通过请求译码器解析通过请求译码器解析得到待处理键值对数据以及数据操作类型的信息并传递给执行引擎模块，执行引擎模块首先需要判断数据删除请求中键是否满足内联存储的要求，例如，可根据键的大小判断，假设在8字节以内，则满足内联存储要求，大于8字节则不满足内联存储要求。

若键满足内联存储的要求，则需要进一步判断要删除的键值对数据是否为小键值对数据，若是小键值对数据则需要优先进入数据中继站中进行查找，若不是小键值对数据则需要在服务器主机内存中进行查找。

具体地，若值的大小满足预设要求(预设要求例如为8字节大小)，则将键哈希到数据中继站中的目标链表结构，且在目标链表结构的表头添加一个DEL数据项，并将键值对数据写入DEL数据项中，删除目标链表结构中相同键的数据项之后即可返回，剩余步骤可以异步执行。其中，异步执行的步骤逻辑与写入操作类似，即通过对键进行哈希算法处理，将键哈希到两个哈希桶(图15所示实施例以2个哈希桶为例进行举例说明)，并根据键在两个哈希桶中匹配，如果匹配成功，根据匹配成功的目标索引槽中的Flag字段的取值进一步确定数据存储在目标索引槽中还是服务器的内存中；若Flag字段为01，则解锁目标索引槽，并释放键值对数据所占用的内存；若Flag字段为10，则根据目标索引槽中的指针信息，从服务器的内存中读取键值对数据，并释放键值对数据所占用的内存，解锁目标索引槽，之后返回。

若键不满足内联存储的要求，则通过对键进行哈希算法处理，将键哈希到两个哈希桶，接着计算键的指纹摘要信息，根据键的指纹摘要信息在哈希桶中匹配，需要说明的是，两个哈希桶中与键的指纹摘要信息匹配的索引槽的数量可能为多个，即目标索引槽的数量可能为多个，则从匹配成功的目标索引槽中读取的指针信息，根据指针信息从服务器的内存中读取键值对数据，当确定与读取的键值对数据的键一致，则释放键值对数据所占的内存，解锁目标索引槽，之后返回；若确定与读取的键值对数据的键不一致，则继续读取下一个目标索引槽中的指针信息，进行匹配，重复执行上述流程。

结合前述实施例，本公开通过将服务器的CPU的一些工作负载迁移至智能网卡中，由智能网卡处理客户端发送的数据操作请求，通过智能网卡对客户端节点呈现了KVS的访问抽象，而不必要求服务器CPU参与数据操作请求的处理，且数据处理***通过子索引结构组织以及多路索引的机制、内联存储机制、数据中继站加速结构以及通过内存分配器实现服务器的内存预申请以及本地管理的方式，大大减小了服务器的性能瓶颈，提高了内存键值数据库的访问开销，对于客户端而言，低延迟能够给客户端带来较好的体验感受。

在图13至图15所示实施例中，若数据中继站中存储的键值对数据对于key的大小有要求，对于value的大小没有要求，则在确定是否进入数据中继站中进行查询时，也可以判断key的大小是否满足预设的条件即可，无需判断value的大小。

示例性地，本公开实施例还提供一种电子设备，包括：存储器和处理器，本公开对于存储器和处理器的类型等等不做限定，其中，存储器和处理器可以通过数据总线连接。存储器被配置为存储计算机程序指令，处理器被配置为执行计算机程序指令，使得电子设备实现如上任一方法实施例所示的数据处理方法。

示例性地，本公开实施例还提供一种计算机可读存储介质，包括：计算机程序指令，计算机程序指令被电子设备的至少一个处理器执行时，使得所述电子设备实现如上任一方法实施例所示的数据处理方法。

示例性地，本公开实施例还提供一种计算机程序产品，当电子设备执行计算机程序产品，使得电子设备实现如上任一方法实施例所示的数据处理方法。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (15)

1.一种数据处理方法，其特征在于，包括：

通过智能网卡中的网卡模块接收客户端发送的数据操作请求；

调用所述智能网卡中的请求分析模块对所述数据操作请求进行解析得到待处理数据和数据操作类型信息，并将所述待处理数据和所述数据操作类型信息输入至所述智能网卡中的执行引擎模块；

调用所述执行引擎模块基于所述待处理数据执行所述数据操作类型信息所指示的数据操作得到数据操作结果；

调用所述请求分析模块对所述数据操作结果进行封装得到所述数据操作请求的应答，并通过所述网卡模块向所述客户端发送所述数据操作请求的应答。

2.根据权利要求1所述的方法，其特征在于，所述调用所述请求分析模块对所述数据操作结果进行封装得到所述数据操作请求的应答，包括：

调用所述请求分析模块基于所述数据操作结果更新所述数据操作请求对应的数据结构中的目标字段得到所述数据操作请求的应答。

3.根据权利要求1所述的方法，其特征在于，所述通过智能网卡中的网卡模块接收客户端发送的数据操作请求，包括：

通过所述网卡模块接收所述客户端发送的具有相同事务标识的多个数据操作请求；

所述调用所述智能网卡中的请求分析模块对所述数据操作请求进行解析得到待处理数据和数据操作类型信息，包括：

调用所述请求分析模块根据分别对具有相同事务标识的所述多个数据操作请求分别进行解析得到多个数据字段以及多个相同的数据操作类型信息；

调用所述请求分析模块根据所述多个数据操作请求分别包括的顺序指示信息对所述多个待处理数据字段进行拼接得到所述待处理数据。

4.根据权利要求3所述的方法，其特征在于，具有相同事务标识的所述多个数据操作请求的数据结构一致。

5.根据权利要求1所述的方法，其特征在于，所述调用所述执行引擎模块基于所述待处理数据执行所述数据操作类型信息指示的数据操作得到数据操作结果，包括：

调用所述执行引擎模块基于所述待处理数据从所述智能网卡包括的内存中存储的索引结构中确定所述待处理数据对应的目标索引槽；

调用所述执行引擎模块针对所述目标索引槽执行所述数据操作类型信息指示的数据操作得到所述数据操作结果。

6.根据权利要求5所述的方法，其特征在于，所述索引结构采用哈希桶的方式实现，所述哈希桶包括多个索引槽；所述通过所述执行引擎模块基于所述待处理数据在所述智能网卡包括的内存中存储的索引结构中确定所述待处理数据对应的目标索引槽，包括：

调用所述执行引擎模块对所述待处理数据进行哈希计算得到哈希值，基于所述哈希值在所述索引结构中匹配得到匹配成功的哈希桶；

调用所述执行引擎模块基于所述待处理数据在匹配成功的哈希桶包括的索引槽中进行匹配得到匹配结果，基于所述匹配结果确定所述目标索引槽。

7.根据权利要求6所述的方法，其特征在于，所述调用所述执行引擎模块对所述待处理数据进行哈希计算得到哈希值，基于所述哈希值在所述索引结构中匹配得到匹配成功的哈希桶，包括：

调用所述执行引擎模块对所述待处理数据采用多种预设哈希算法分别进行哈希计算得到多个哈希值；

调用所述执行引擎模块将所述多个哈希值与所述索引结构包括的各哈希桶的标识进行匹配得到匹配成功的多个哈希桶。

8.根据权利要求6所述的方法，其特征在于，所述调用所述执行引擎模块基于所述待处理数据在匹配成功的哈希桶包括的索引槽中进行匹配得到匹配结果，包括：

调用所述执行引擎模块基于所述待处理数据在匹配成功的哈希桶中进行匹配；或者，调用所述执行引擎模块计算所述待处理数据对应的指纹摘要信息，基于所述指纹摘要信息在匹配成功的哈希桶中进行匹配。

9.根据权利要求5所述的方法，其特征在于，若所述数据操作请求为数据读请求，所述调用所述执行引擎模块针对所述目标索引槽执行所述数据操作类型信息指示的数据操作得到所述数据操作结果，包括：

若确定所述待处理数据和所述待处理数据对应的目标数据均采用内联方式存储，则从所述目标索引槽中读取所述待处理数据指示的目标数据；

若确定所述待处理数据采用内联方式存储，所述待处理数据对应的目标数据采用非内联方式存储，或者，若确定所述待处理数据采用非内联方式存储，则从所述目标索引槽中获取指针信息，并从所述指针信息指示的服务器的内存中读取所述待处理数据对应的目标数据。

10.根据权利要求5所述的方法，其特征在于，若所述数据操作请求为数据删除请求，则所述调用所述执行引擎模块针对所述目标索引槽执行所述数据操作类型信息指示的数据操作得到所述数据操作结果，包括：

若确定所述待处理数据和所述待处理数据指示的目标数据均采用内联存储方式存储，则删除所述目标索引槽；

若确定所述待处理数据采用内联方式存储，所述待处理数据指示的目标数据采用非内联方式存储，或者，若确定所述待处理数据采用非内联方式存储，则从所述目标索引槽中获取指针信息，并删除所述指针信息所指示的服务器的内存中的数据，且释放所述目标索引槽。

11.根据权利要求10所述的方法，其特征在于，所述删除所述指针信息所指示的服务器的内存中的数据，包括：

通过所述执行引擎模块控制所述智能网卡的内存管理模块释放所述指针信息所指示的服务器的内存，所述内存管理模块用于管理所述服务器的内存。

12.一种数据处理装置，其特征在于，包括：

网卡模块，用于接收客户端发送的数据操作请求；

请求分析模块，用于对接收的所述数据操作请求进行解析得到待处理数据和数据操作类型信息，并将所述待处理数据和所述数据操作类型信息输入至执行引擎模块；

执行引擎模块，用于基于所述待处理数据执行所述数据操作类型信息指示的数据操作得到数据操作结果；

所述请求分析模块，还用于对所述数据操作结果进行封装得到所述数据操作请求的应答；

所述网卡模块，还用于向所述客户端发送所述数据操作请求的应答。

13.一种电子设备，其特征在于，包括：存储器和处理器；

所述存储器被配置为存储计算机程序指令；

所述处理器被配置为执行所述计算机程序指令，使得所述电子设备实现如权利要求1至11任一项所述的数据处理方法。

14.一种计算机程序产品，其特征在于，当所述计算机程序产品被电子设备执行时，使得所述电子设备实现如权利要求1至11任一项所述的数据处理方法。

15.一种可读存储介质，其特征在于，包括：计算机程序指令，电子设备的至少一个处理器执行所述计算机程序指令，使得所述电子设备实现如权利要求1至11任一项所述的数据处理方法。