CN116049085A - 一种数据处理系统及方法 - Google Patents

Abstract

本申请提供一种数据处理系统及方法。数据处理系统包括：至少一个第一节点和至少一个第二节点，其中至少一个第一节点和至少一个第二节点基于用户态协议栈通信。第一节点，被配置为：基于用户态协议栈，接收来自应用端的数据处理请求，基于应用端的数据处理请求，向至少一个第二节点发送数据请求；第二节点，被配置为：基于用户态协议栈，接收第一节点发送的数据请求，并且各自通过DMA或者所述第二节点之间通过RDMA对第一节点发送的数据请求进行处理。如此改进数据通信从而避免性能损耗及提升整体系统性能。

Description

一种数据处理系统及方法

技术领域

本申请涉及计算机技术领域，具体涉及网络通信和数据库技术领域，尤其涉及一种数据处理系统及方法。

背景技术

随着互联网技术和网络通信技术的发展，数据库作为核心的底层基础设施也保持了迅速的增长。常见的一种数据库是关系型数据库，也就是将数据按照关系模型进行组织和管理以及使用结构化查询语言(structured query language，SQL)做各种关系运算得到检索结果。此外存在时序型数据库、图数据库、文档型数据库、键值(key-value，KV)数据库等。根据数据库内部处理事务的方式，数据库还可以分成单机数据库和分布式数据库。单机数据库一般在一个节点上完成数据库事务。分布式数据库一般通过多个节点协调完成数据库事务也叫做分布式事务或者说在分布式环境下处理事务。面对海量数据需要存储的要求，单机数据库一般通过纵向扩展例如增加磁盘存储空间和内存等，分布式数据库一般通过横向扩展例如增加新的机器或者新的节点。但是，随着需要存储的数据规模日益增加，需要通过数据库来完成的数据库事务的需求也复杂多变，因此产生大量的数据库的数据通信，也即在数据库的设备、机器和节点之间存在大量的数据通信。

在现有技术中，一般通过传输控制协议/互联协议(transmission controlprotocol/internet protocol，TCP/IP协议)来处理各节点间的数据通信，但是这样会导致频繁发起系统调用并且触发操作系统中内核态和用户态之间的频繁切换及数据拷贝操作，从而造成性能损耗和不利于提升整体系统性能。

综上所述，目前需要解决的问题是如何改进数据库的数据通信从而避免性能损耗及提升整体系统性能。

发明内容

本申请实施例提供了一种数据处理系统及方法，用于解决现有技术中存在的问题也就是如何改进数据库的数据通信从而避免性能损耗及提升整体系统性能。

第一方面，本申请提供了一种数据处理系统。所述数据处理系统包括：至少一个第一节点和至少一个第二节点，其中所述至少一个第一节点和所述至少一个第二节点基于用户态协议栈通信；所述第一节点，被配置为：基于所述用户态协议栈，接收来自应用端的数据处理请求，基于所述应用端的数据处理请求，向所述至少一个第二节点发送数据请求；所述第二节点，被配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过直接内存访问DMA或者所述第二节点之间通过远程直接内存访问RDMA对所述第一节点发送的数据请求进行处理。

在本申请的第一方面的一种可能实现方式中，所述第一节点还配置为：基于所述用户态协议栈，根据所述应用端的数据处理请求协调所述第二节点，从而使得所述第二节点各自通过DMA或者使得所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。

在本申请的第一方面的一种可能实现方式中，所述至少一个第一节点基于所述用户态协议栈进行的数据通信涉及所述至少一个第一节点的操作系统的用户空间，并且不涉及所述操作系统的内核空间。

在本申请的第一方面的一种可能实现方式中，所述数据处理系统是分布式数据库，所述第一节点是协调节点CN，所述第二节点是数据节点DN，所述CN可协调所述DN从而使得所述DN各自通过DMA或者所述DN之间通过RDMA对所述CN发送的数据请求进行处理。

在本申请的第一方面的一种可能实现方式中，所述用户态协议栈包括以堆栈形式固化的传输控制协议/互联协议TCP/IP协议。

在本申请的第一方面的一种可能实现方式中，所述数据处理系统是单机数据库，所述第一节点是本地数据节点，所述第二节点是相对于所述应用端的另一应用端。

在本申请的第一方面的一种可能实现方式中，所述用户态协议栈包括以堆栈形式固化的局域网通信协议或者内部总线通信协议。

在本申请的第一方面的一种可能实现方式中，所述用户态协议栈从多种预设用户态协议栈中选择。

在本申请的第一方面的一种可能实现方式中，所述用户态协议栈通过代理通信库进行接口封装，所述代理通信库用于自适应选择用于所述第一节点和所述第二节点之间通信的用户态协议栈。

在本申请的第一方面的一种可能实现方式中，所述代理通信库还用于对TCP/IP协议栈和RDMA进行接口封装。

在本申请的第一方面的一种可能实现方式中，所述代理通信库包括统一化通信模型接口。

第二方面，本申请提供了一种数据处理方法。所述数据处理方法应用于数据处理系统，所述数据处理系统包括：至少一个第一节点和至少一个第二节点，所述至少一个第一节点和所述至少一个第二节点基于用户态协议栈通信；所述数据处理方法包括：所述第一节点，基于所述用户态协议栈，接收来自应用端的数据处理请求；所述第一节点，基于所述应用端的数据处理请求，向所述至少一个第二节点发送数据请求。

在本申请的第二方面的一种可能实现方式中，所述第二节点被配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过DMA或者所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。

在本申请的第二方面的一种可能实现方式中，所述第一节点配置为：基于所述用户态协议栈，根据所述应用端的数据处理请求协调所述第二节点，从而使得所述第二节点各自通过DMA或者使得所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。

在本申请的第二方面的一种可能实现方式中，所述至少一个第一节点基于所述用户态协议栈进行的数据通信涉及所述至少一个第一节点的操作系统的用户空间，并且不涉及所述操作系统的内核空间。

在本申请的第二方面的一种可能实现方式中，所述第一节点和所述第二节点均属于分布式数据库，所述第一节点是CN，所述第二节点是DN，所述CN可协调所述DN从而使得所述DN各自通过DMA或者所述DN之间通过RDMA对所述CN发送的数据请求进行处理。

在本申请的第二方面的一种可能实现方式中，所述用户态协议栈包括以堆栈形式固化的传输控制协议/互联协议TCP/IP协议。

在本申请的第二方面的一种可能实现方式中，所述第一节点和所述第二节点均属于单机数据库，所述第一节点是本地数据节点，所述第二节点是相对于所述应用端的另一应用端。

在本申请的第二方面的一种可能实现方式中，所述用户态协议栈包括以堆栈形式固化的局域网通信协议或者内部总线通信协议。

在本申请的第二方面的一种可能实现方式中，所述用户态协议栈从多种预设用户态协议栈中选择。

在本申请的第二方面的一种可能实现方式中，所述用户态协议栈通过代理通信库进行接口封装，所述代理通信库用于自适应选择用于所述第一节点和所述第二节点之间通信的用户态协议栈。

在本申请的第二方面的一种可能实现方式中，所述代理通信库还用于对TCP/IP协议栈和RDMA进行接口封装。

在本申请的第二方面的一种可能实现方式中，所述代理通信库包括统一化通信模型接口。

第三方面，本申请实施例还提供了一种计算机设备，所述计算机设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据上述任一方面的任一种实现方式的方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机设备上运行时使得所述计算机设备执行根据上述任一方面的任一种实现方式的方法。

第五方面，本申请实施例还提供了一种计算机程序产品，其特征在于，所述计算机程序产品包括存储在计算机可读存储介质上的指令，当所述指令在计算机设备上运行时使得所述计算机设备执行根据上述任一方面的任一种实现方式的方法。

附图说明

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

图1为一种分布式数据库的数据通信场景的示意图；

图2为本申请实施例提供的数据库的示意图；

图3为本申请实施例提供的数据库的第一节点与应用端之间的数据通信的示意图；

图4为本申请实施例提供的数据库的第二节点之间的数据通信的示意图；

图5为本申请实施例提供的数据处理方法的流程示意图；

图6为本申请实施例提供的一种计算设备的结构示意图；

图7为本申请实施例提供的代理通信库的示意图。

具体实施方式

下面将结合附图对本申请实施例作进一步地详细描述。

本申请实施例提供了一种数据处理系统及方法，用于解决现有技术中存在的问题也就是如何改进数据库的数据通信从而避免性能损耗及提升整体系统性能。其中，本申请实施例提供的方法和设备是基于同一发明构思的，由于方法及设备解决问题的原理相似，因此方法与设备的实施例、实施方式、示例或实现方式可以相互参见，其中重复之处不再赘述。

应当理解的是，在本申请的描述中，“至少一个”指一个或一个以上，“多个”指两个或两个以上。另外，“第一”、“第二”等词汇，除非另有说明，否则仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

参阅图1，图1为一种分布式数据库的数据通信场景的示意图。如图1所示，分布式数据库包括协调节点104、数据节点106和数据节点108。图1所示的分布式数据库的构造，包括其中的协调节点和数据节点各自的数量，仅为示例性。用户102指的是数据库事务的发起方或者应用方，可以等效地替换为应用端(application，APP)、用户应用、应用程序等。协调节点104指的是分布式数据库中的协调节点(coordinatorNode，CN)，协调节点用于对外，例如对用户102提供接口，负责数据分发、查询服务以及节点规划等。协调节点上一般不存储实际的业务数据也不负责管理实际的业务数据，而是存储整个数据库系统的全局元数据(metadata)，并提供数据库视图。元数据是关于其它数据及信息资源的描述性信息。数据节点(DataNode，DN)用于执行由协调节点分发的执行请求，例如数据处理请求，并且负责管理与本数据节点相关的业务数据，包括处理存储在本数据节点的业务数据的元数据。数据节点还可以负责存储与本数据节点相关的业务数据的分片信息用于实现数据分片存储。随着对数据存储需求的增加，分布式数据库可以通过横向扩展，例如增加新的协调节点来扩大集群规模，通过将数据分片存储在不同协调节点上来满足需要存储的数据规模日益增加的需求。应当理解的是，分布式数据库一般通过多个节点协调完成数据库事务也叫做分布式事务或者说在分布式环境下处理事务，而且不同的节点可能位于同一地理位置也可能位于不同的地理位置，每个节点可能是一台主机或者多台主机或者虚拟机和物理机器的组合。

继续参阅图1，对数据库外部而言，例如对于用户102，可以通过分布式数据库的协调节点，例如协调节点104来完成数据读取、数据写入及数据查询等操作，也就是完成分布式事务，并且不需要考虑实际的业务数据是位于哪个具体的数据节点上。图1还示出了分布式数据库与外部之间的数据通信或者说数据交互的通信特点及对应的通信需求，以及数据库内部的数据通信或者说数据交互的通信特点及对应的通信需求，这些通信特点及相应通信需求表现为在报文长短、发生频次及数据量大小等方面具有不同的特点。具体地，用户102和协调节点104之间的数据通信或者数据交互的特点体现为通信需求120，通信需求120具有报文短、发生频次多、数据量小的特点；协调节点104和数据节点106之间的数据通信或者数据交互的特点体现为通信需求130，通信需求130具有报文短、发生频次多、数据量小的特点；协调节点104和数据节点108之间的数据通信或者数据交互的特点体现为通信需求132，通信需求132具有报文短、发生频次多、数据量小的特点；数据节点106和数据节点108之间的数据通信或者数据交互的特点体现为通信需求140，通信需求140具有报文长、发生频次少、数据量大的特点。此外，有时候还会发生用户102和数据节点如数据节点108之间的数据通信或者数据交互，其特点体现为通信需求150，通信需求150具有报文短、发生频次多、数据量小的特点。由上述关于图1所示的分布式数据库的各种通信需求可以看出，涉及到数据节点之间，例如数据节点106和数据节点108之间的数据交互或者数据通信，具有与通信需求140类似的特点也就是报文长、发生频次少、数据量大。基于分布式数据库中数据分片存储在不同数据节点的特性，来自数据库外部的数据处理请求，例如分布式事务还有数据读取、数据写入及数据查询等操作，经常需要涉及两个或者更多个数据节点，也需要通过协调节点来协调这些两个或者更多个数据节点来完成该数据处理请求。随着需要存储的数据规模日益增加，需要通过数据库来完成的数据库事务的需求也复杂多变，参与每个分布式事务的节点数量及具体哪些节点也是复杂多变的，而这些节点之间的数据通信或者数据交互也各自具有不同的特点，例如上述图1中分布式数据库中的各种通信需求。另外，各个节点的操作系统一般将进程执行状态分成内核态执行和用户态执行，其中处于内核态执行(有时也叫作处于核心态执行)的进程能访问所有的内存空间和对象，而处于用户态执行的进程能访问的内存空间和对象受到限制。类似地，各个节点对于操作系统代码和设备驱动程序代码也区分对待工作在内核态的代码(不受限制地访问有效地址)和工作在用户态的代码(访问受限制)。类似地，各个节点的计算机指令级别也通过分级来区分不同的程序的不同指令执行权限，例如处理器运行某些指令级别的指令时是属于内核态而运行另一些指令级别的指令时是属于用户态。一方面，当运行在用户态下的进程、程序、代码需要突破其受到的访问对象或者权限的限制时，例如当用户态程序需要调用内核态程序时，就涉及到从用户态切换到内核态，这意味着需要通过例如系统调用(用户态程序通过系统调用向操作系统申请资源)、中断(发出中断信号)、异常(发生异常如缺页异常)等机制来发起状态切换，并且带来性能损耗和延时。另一方面，当内核态程序或者内核态代码执行完毕后回到用户态程序，又涉及到从内核态切换到用户态，包括将内核态程序或者内核态代码的执行结果反馈到用户态程序，并且带来性能损耗和延时。

继续参阅图1，一种数据库的通信方式是通过传输控制协议/互联协议(transmission control protocol/internet protocol，TCP/IP协议)来处理各节点间的数据通信，例如通过各节点的操作系统提供的TCP/IP协议，如TCP/IP网络通信协议栈来进行与其它节点的数据交互。这样做可以借助TCP/IP协议所规定的通信标准及方法实现在不同网络、不同节点之间及时完整传输网络数据信息并且可以满足不同应用要求及传输方式。但是，通过TCP/IP协议来处理数据通信，会导致频繁发起系统调用，并且触发操作系统中内核态和用户态之间的频繁切换及数据拷贝操作，从而造成性能损耗和不利于提升整体系统性能。具体地，通过TCP/IP协议来处理数据通信，会导致节点的操作系统的用户态/内核态之间的频繁切换并带来巨大系统性能开销，而且也导致频繁的系统调用以及更多的处理数据包的时间。而采用内核态协议栈则依靠中断来唤醒内核处理数据包，也会导致增加开销。此外，通过TCP/IP协议来处理数据通信还会导致用户态/内核态的数据拷贝操作以及所带来的额外开销。下面结合图2进一步详细说明，本申请实施例提供的数据库及数据处理方法是如何改进数据库的数据通信，从而避免性能损耗及提升整体系统性能，并且在克服通过TCP/IP协议来处理数据通信的各种不足的同时也充分考虑到了数据库的节点之间的数据通信或者数据交互各自具有的不同的特点。

参阅图2，图2为本申请实施例提供的数据库的示意图。如图2所示，数据库包括第一节点212和第一节点214，还包括第二节点222、第二节点224、第二节点226、第二节点228。数据库从应用端202和应用端204接收数据库事务或者说数据处理请求。应当理解的是，图2所示的数据库可以理解为数据处理系统。也就是说，图2还示意性示出了数据处理系统的示意图，该数据处理系统包括图2所示的第一节点和第二节点，且该数据处理系统接收来自应用端202和/或应用端204的数据处理请求。图2中还通过带箭头的实线示意性示出了各节点之间的数据通信或者数据交互关系。可以看出，应用端202和应用端204分别与第一节点212和第一节点214进行数据交互或者数据通信，然后第一节点212和第一节点214分别与第二节点222、第二节点224、第二节点226、第二节点228进行数据交互或者数据通信。虽然图2没有示出，但是在第二节点222、第二节点224、第二节点226、第二节点228之间也可能存在彼此之间的数据交互或者数据通信，例如第二节点222与第二节点224之间以及第二节点222与第二节点226之间存在数据交互或者数据通信。这里，应用端202和应用端204代表了数据库事务的发起方，也就是说图2的数据库的数据库事务或者数据处理请求来自于应用端202和/或应用端204。应用端202和应用端204可以等效地替换为应用端、APP端、用户应用、应用程序等。并且，应当理解的是，应用端202和/或应用端204可以采用任意合适的软件、硬件、固件的载体或者其组合，包括但是不限于，电子设备，主机、服务器、计算设备、计算装置等，并且应用端202和/或应用端204可以是单台主机或者多台主机，单个服务器或者多个服务器，单个计算设备或者多个计算设备、单个计算装置或者多个计算装置等。第一节点212和第一节点214代表了至少一个第一节点，用于接收来自应用端的数据处理请求并且协调第二节点来执行对应的数据处理操作。第二节点222、第二节点224、第二节点226、第二节点228代表了至少一个第二节点，用于管理业务数据包括在第一节点的协调下，执行对业务数据的数据处理操作，从而完成对数据处理请求的响应。这里，业务数据指的是与来自应用端的数据处理请求相关的待处理数据，例如当应用端的数据处理请求是获取存储在第二节点222上的某个用户数据时，该用户数据就是业务数据。第二节点作为存储数据的节点，业务数据也存储在第二节点上，因此第二节点对各自存储其上的数据进行操作就是第二节点对各自管理的业务数据执行数据处理操作。

在一种可能的实施方式中，所述至少一个第一节点和所述至少一个第二节点基于用户态协议栈通信；所述第一节点，被配置为：基于所述用户态协议栈，接收来自应用端的数据处理请求，基于所述应用端的数据处理请求，向所述至少一个第二节点发送数据请求；所述第二节点，被配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过直接内存访问(direct memory access，DMA)或者所述第二节点之间通过远程直接内存访问(remote direct memory access，RDMA)对所述第一节点发送的数据请求进行处理。具体地，参阅图2所示的数据库或者数据处理系统：至少一个第一节点(第一节点212和第一节点214)，配置为：基于用户态协议栈，接收来自所述应用端的数据处理请求；至少一个第二节点(第二节点222、第二节点224、第二节点226、第二节点228)，配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过DMA或者所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。这里，第二节点可以各自通过DMA或者第二节点之前通过RDMA对所述第一节点发送的数据请求进行处理。其中，第二节点各自通过DMA对所述第一节点发送的数据请求进行处理，一般针对同一台物理机器的情况，例如单台服务器。第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理，一般针对的是第二节点不在同一台物理机器的情况，例如分布在多台服务器上，因此通过第二节点各自的通信接口，在第二节点之间相互通信时使用对应的接口来实现采用RDMA进行数据通信。此外，第一节点是基于自身算法去协调第二节点，第二节点基于DMA或者第二节点之间通过RDMA来对数据请求进行处理。也就是说，所述第一节点还配置为：基于所述用户态协议栈，根据所述应用端的数据处理请求协调所述第二节点，从而使得所述第二节点各自通过DMA对所述第一节点发送的数据请求进行处理。在一些实施例中，第一节点可以基于任意合适的算法、模型来协调第二节点，例如参考节点间的通信需求、通信协议之间的适配性等，在此不做具体限定。这里，第二节点基于DMA或者第二节点之间通过RDMA来对数据请求进行处理，或者类似的内存管理机制、内存访问、数据读取等技术，实现了将数据从一个系统快速移动到另一个系统(当后一个系统和前一个系统都位于本地时是DMA，当后一个系统位于相对于前一个系统的远端时是RDMA)。相对于通过TCP/IP协议来处理数据通信从而导致数据拷贝以及频繁的系统调用，通过DMA或者RDMA来执行数据处理操作，例如进行数据读取操作、数据写入操作或者数据查询操作，可以做到零拷贝也即是应用程序能够直接执行数据传输且不涉及网络软件栈。如此，第一节点，例如第一节点212和第一节点214，基于用户态协议栈来接收来自所述应用端的数据处理请求，使得该用户态协议栈可以满足应用端的第一通信需求和兼容应用端，例如应用端202和应用端204的个性化需求，例如应用端202可能对应语音通话的应用场景而应用端204可能对应视频播放的应用场景。对于应用端202的语音通话的应用场景而言，相关的第一通信需求可能具有大量短连接，也就是会话时间短且频繁建立和结束会话的特点，这可能体现为大量的数据量小且频次高的数据；而对于应用端204的视频播放的应用场景而言，相关的第一通信需求可能具有相对较少的长连接，也就是会话时间较长(视频播放的时长通常长于语音会话的时长)，且相对不那么频繁地建立和结束会话的特点，这可能体现为数据量相对较大且频次相对较低的数据。也就是说，取决于具体的应用端的需求及应用场景，应用端的第一通信需求表现为在报文长短、发生频次及数据量大小等方面具有不同的特点。此外，应用端也可能有优先采用的或者默认采用的通信协议、安全协议、数据加解密方式、报文转送方式等技术规范或者技术细节，这些也反映在应用端的第一通信需求上。并且，因为数据库如图2所示的数据库，只能被动地接受来自应用端的数据库事务或者数据处理请求，因此一般需要单方面地去适应应用端的要求也就是要求由数据库去满足应用端的第一通信需求(包括以下一项或者多项：会话特点、应用场景、报文长短、发生频次及数据量大小等、还有用户优先采用或者默认采用的通信协议、安全协议、数据加解密方式、报文转送方式等技术规范或者技术细节，以及其它合适的应用端的通信需求)。如上所述，第一节点基于用户态协议栈来接收来自所述应用端的数据处理请求，使得该用户态协议栈可以兼容应用端的第一通信需求。并且可以实现直接将主机节点内存中的数据包映射到用户态。此外，用户态协议栈可以采用库函数调用而不需要涉及系统调用，从而减小了性能开销。下面结合图3来进一步详细说明，第一节点基于满足应用端的第一通信需求的用户态协议栈来接收来自所述应用端的数据处理请求的有益技术效果。

请参阅图3，图3为本申请实施例提供的数据库的第一节点与应用端之间的数据通信的示意图。如图3所示，应用端302的数据处理请求，通过应用端操作系统304处理后下发到应用端网卡306，然后经应用端网卡306利用网络301传输到第一节点网卡316。这里，应用端网卡306和第一节点网卡316，以及本申请所提及的网卡，指的是用于网络通讯功能例如报文转发、数据转发、网络与本地之间的数据上下行等的设备，包括但是不限于，网卡(network interface card，NIC)，网络接口控制器(network interface controller，NIC)，网络接口控制器，网络适配器(network adapter)，局域网接收器(LAN adapter)等。第一节点网卡316从网络301接收到来自应用端302的数据处理请求。第一节点312基于满足应用端302的第一通信需求的用户态协议栈313来接收来自所述应用端的数据处理请求，也就是绕过第一节点操作系统314。为此，图3中用虚线框来示出第一节点操作系统314。换句话说，第一节点312，基于满足应用端302的第一通信需求的用户态协议栈313来接收来自所述应用端302的数据处理请求，使得该用户态协议栈313可以兼容应用端302的第一通信需求。并且用户态协议栈313使得不需要通过第一节点操作系统314进行数据包的拷贝，而是直接将主机节点如第一节点312内存中的数据包映射到用户态。此外，用户态协议栈313可以采用库函数调用而不需要涉及通过第一节点操作系统314进行系统调用，从而减小了性能开销。

继续参阅图1，至少一个第二节点，例如图2所示的第二节点222、第二节点224、第二节点226和第二节点228，被配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过直接内存访问DMA或者所述第二节点之间通过远程直接内存访问RDMA对所述第一节点发送的数据请求进行处理。如上所述，第二节点基于DMA或者第二节点之间通过RDMA来对数据请求进行处理，意味着通过DMA或者RDMA来执行数据处理操作，例如进行数据读取操作、数据写入操作或者数据查询操作，可以做到零拷贝也即是应用程序能够直接执行数据传输且不涉及网络软件栈。例如，从第一节点发出的数据能够被直接发送到第二节点内存的内存空间或者某个第二节点能够直接从另一个第二节点的内存空间里接收数据。此外，通过DMA或者RDMA来对所管理的业务数据执行数据处理操作，还可以实现内核旁路，也就是说应用程序可以直接在用户态执行数据传输而不需要在内核态与用户态之间做上下文切换。此外，通过DMA或者RDMA来对所管理的业务数据执行数据处理操作，还可以减少主机干预。例如，通过RDMA来对所管理的业务数据执行数据处理操作时，应用程序可以访问远程主机内存而不消耗远程主机中的任何处理器算力，远程主机内存也能够被读取而不需要远程主机上的进程或者处理器资源参与。并且，相对于通过TCP/IP协议来处理数据通信所导致的将数据以流(flow)的形式进行传输，通过DMA或者RDMA来对所管理的业务数据执行数据处理操作可以做到基于事务的消息，也就是将数据以数据包的形式发送，而不是流，从而消除了应用程序将流切割为不同消息/事务的需求。下面结合图4来进一步详细说明，第二节点配置为管理业务数据并且可通过DMA对所管理的业务数据执行数据处理操作的有益技术效果。

请参阅图4，图4为本申请实施例提供的数据库的第二节点之间的数据通信的示意图。如图4所示，第二节点402和第二节点412之间的数据通信或者数据交互通过各自的虚拟内存RDMA实现而绕过各自的操作系统。具体地，第二节点402通过虚拟内存RDMA 403来与第二节点网卡406进行数据交互或者数据通信从而绕过第二节点操作系统404，第二节点412通过虚拟内存RDMA 413来与第二节点网卡416进行数据交互或者数据通信，从而绕过第二节点操作系统414。为此，图4中用虚线框分别示出第二节点操作系统404和第二节点操作系统414。如上所述，第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理，一般针对的是第二节点不在同一台物理机器的情况，例如分布在多台服务器上，因此通过第二节点各自的通信接口，在第二节点之间相互通信时使用对应的接口来实现采用RDMA进行数据通信。这里，第二节点402和第二节点412被视为不在同一台物理机器上，因此第二节点402和第二节点412之间通过RDMA对所述第一节点发送的数据请求进行处理。第二节点网卡406和第二节点网卡416之间通过网络401进行通信。当数据库事务或者数据处理请求涉及到多个第二节点之间的协作，一般由在用户空间或者用户态下的应用发起RDMA读写请求，然后该RDMA读写请求作为数据传输请求的一部分，经网络401传输到远程的网卡，例如第二节点网卡406和第二节点网卡416。结合上面提到的，第一节点基于满足应用端的第一通信需求的用户态协议栈来接收数据处理请求，这意味着可以通过用户态协议栈，做到由用户态下的应用发起RDMA读写请求来协调第二节点，例如第二节点402和第二节点412，从而各自通过DMA对所管理的业务数据执行数据处理操作，或者第二节点之间通过RDMA对各自存储并管理的业务数据进行处理如此，第二节点，例如第二节点402和第二节点412，配置为管理业务数据并且可通过DMA，例如图4所示的虚拟内存RDMA 403和虚拟内存RDMA 413，对所管理的业务数据执行数据处理操作，可以做到零拷贝，也即是应用程序能够直接执行数据传输且不涉及网络软件栈，还可以实现内核旁路以及减少主机干预，并且节省远程主机处理器资源。

继续参阅图1，所述至少一个第二节点中的一个或者多个第二节点与所述数据处理请求相关联。所述用户态协议栈还满足第二通信需求，所述第二通信需求用于所述至少一个第一节点协调所述一个或者多个第二节点，从而使得所述一个或者多个第二节点各自通过DMA执行与所述数据处理请求对应的数据处理操作。上面提到，第一节点，例如图2所示的第一节点212和第一节点214，基于满足应用端的第一通信需求的用户态协议栈来接收来自所述应用端的数据处理请求，这样有利于通过用户态协议栈兼容应用端，例如应用端202和应用端204的个性化需求。以图3为例，第一节点312，基于满足应用端302的第一通信需求的用户态协议栈313来接收来自所述应用端302的数据处理请求，使得该用户态协议栈313可以兼容应用端302的第一通信需求。并且用户态协议栈313使得不需要通过第一节点操作系统314进行数据包的拷贝，而是可以通过将第一节点312的内存中的数据包映射到用户态。此外，用户态协议栈313可以采用库函数调用而不需要涉及通过第一节点操作系统314进行系统调用，从而减小了性能开销。另一方面，至少一个第二节点，例如图2所示的第二节点222、第二节点224、第二节点226和第二节点228，配置为：管理业务数据并且可通过DMA对所管理的业务数据执行数据处理操作，这样有利于做到减少数据拷贝甚至做到零数据拷贝、内核旁路化、减少主机干预、节省远程主机处理器资源。以图4为例，第二节点402和第二节点412，配置为管理业务数据并且分别通过虚拟内存RDMA 403和虚拟内存RDMA 413，对所管理的业务数据执行数据处理操作，可以做到减少数据拷贝甚至做到零数据拷贝，也即是应用程序能够直接执行数据传输且不涉及网络软件栈，还可以实现内核旁路以及减少主机干预，并且节省远程主机处理器资源。在进行RDMA数据业务传输时，例如发起RDMA读写请求或者执行RDMA读操作或RDMA写操作，针对的是虚拟内存RDMA 403和虚拟内存RDMA 413，而硬件，如网卡，访问主机内存时采用的是物理地址。因此，为了实现通过用户态协议栈做到由用户态下的应用发起RDMA读写请求来协调第二节点，例如第二节点402和第二节点412，从而通过DMA对所管理的业务数据执行数据处理操作，用户态协议栈，例如图3所示的第一节点312的用户态协议栈313，应采用虚拟地址。而支持RDMA的网卡，例如第二节点网卡416采用物理地址(并且虚拟地址和物理地址之间应满足一定要求的映射关系)从而绕过系统内核进行数据传输，进而避免额外的数据转移和数据复制操作。因此，所述用户态协议栈，例如图3所示的第一节点312的用户态协议栈313，还满足第二通信需求；所述第二通信需求用于所述至少一个第一节点协调所述一个或者多个第二节点，从而使得所述一个或者多个第二节点各自通过DMA执行与所述数据处理请求对应的数据处理操作。这里，第二通信需求至少包括上述的，为了做到RDMA读操作和/或RDMA写操作而必须满足的虚拟地址和物理地址之间的映射关系，并且这样的映射关系在已经占用的业务数据被释放之前是不应改动的。具体的来说，应用程序，例如用户态协议栈，使用的是虚拟地址，而虚拟地址要映射到物理地址才能正确地读取和写入数据。为了保证将远程系统内存里的数据拉回到本地系统内存的RDMA读操作，以及将本地系统内存的数据推送到远程系统内存里的RDMA写操作能够正确执行，需要在数据传输过程中避免修改数据所在的主机内存，以及要保持物理地址和虚拟地址之间的映射关系是固定不变的。类似地，为了协调所述一个或者多个第二节点从，而使得所述一个或者多个第二节点各自通过DMA执行与所述数据处理请求对应的数据处理操作，还可能需要满足因为具体采用的DMA或者RDMA技术而需要提供的，例如数据格式、报文格式、通讯端口等各方面的要求，这一点取决于与所述数据请求相关联的所述一个或者多个第二节点(例如数据处理请求要查询、读取或者写入的数据所对应的第二节点)所具体采用的DMA或者RDMA技术的有关规范。因此，通过要求满足应用端的第一通信需求的用户态协议栈同时还满足第二通信需求，所述第二通信需求用于所述至少一个第一节点协调所述一个或者多个第二节点，从而使得所述一个或者多个第二节点各自通过DMA执行与所述数据处理请求对应的数据处理操作，促成了第一节点和第二节点之间的协议适配，同时还使得第一节点可以通过用户态协议栈来实现路由，例如，确定为了响应当前应用端的数据处理请求而适配的第一节点的IP地址及接口信息，以及第二节点的IP地址及接口信息，进而实现了通过用户态协议栈进行全用户态下的运算及操作来执行数据库的数据通信。

参阅图2、图3和图4，本申请实施例提供的数据处理系统(在一些实施例中是数据库)，该数据处理系统包括：至少一个第一节点和至少一个第二节点，其中所述至少第一节点和所述至少一个第二节点基于用户态协议栈通信；所述第一节点，被配置为：基于所述用户态协议栈，接收来自应用端的数据处理请求，基于所述应用端的数据处理请求，向所述至少一个第二节点发送数据请求；所述第二节点，被配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过直接内存访问DMA或者所述第二节点之间通过远程直接内存访问RDMA对所述第一节点发送的数据请求进行处理。如此，实现了通过用户态协议栈进行全用户态下的运算及操作来执行数据库的数据通信，有利于通过用户态协议栈兼容应用端的个性化需求并且减少系统调用等开销，还有利于减少数据拷贝、内核旁路化、减少主机干预、节省远程主机处理器资源，进而有利于改进数据库的数据通信从而避免性能损耗及提升整体系统性能。

在一种可能的实施方式中，所述至少一个第一节点还配置为：基于所述用户态协议栈，根据所述数据处理请求协调所述一个或者多个第二节点，从而使得所述一个或者多个第二节点各自通过DMA或者多个第二节点之间通过RDMA执行所述数据处理操作。

在一种可能的实施方式中，所述第一节点还配置为：基于所述用户态协议栈，根据所述应用端的数据处理请求协调所述第二节点，从而使得所述第二节点各自通过DMA对所述第一节点发送的数据请求进行处理。

在一种可能的实施方式中，所述第一通信需求包括所述应用端的第一通信协议，所述至少一个第一节点还配置为基于所述用户态协议栈接收所述第一通信协议。在一些实施例中，所述用户态协议栈至少基于所述第一通信协议的堆栈形式固化。这里，所述用户态协议栈至少基于所述第一通信协议的堆栈形式固化，类似于算法固化，就是将第一通信协议，例如TCP/IP协议或者任意应用端所采用或者偏好的通信协议，其中的流程和逻辑提取出来并以用户态堆栈形式进行固化，从而有利于执行所述用户态协议栈，进而完成所述应用端的数据处理请求所需要的某些功能，这些功能是原本的第一通信协议所提供的，这些功能可以是例如协议适配、路由、数据传输等。

在一种可能的实施方式中，所述第二通信需求包括第二通信协议，所述至少一个第一节点通过所述第二通信协议实现根据所述数据处理请求协调所述一个或者多个第二节点，从而使得所述一个或者多个第二节点各自通过DMA执行所述数据处理操作。在一些实施例中，所述用户态协议栈至少基于所述第二通信协议的堆栈形式固化。上面提到，为了协调所述一个或者多个第二节点从而使得所述一个或者多个第二节点各自通过DMA(也可以是RDMA)执行与所述数据处理请求对应的数据处理操作，还可能需要满足因为具体采用的DMA或者RDMA技术而需要提供的例如数据格式、报文格式、通讯端口等各方面的要求，这一点取决于与所述数据请求相关联的所述一个或者多个第二节点(例如数据处理请求要查询、读取或者写入的数据所对应的第二节点)所具体采用的DMA或者RDMA技术的有关规范。这些所述一个或者多个第二节点所具体采用的DMA或者RDMA技术的有关规范，可以体现在所述第二通信需求上，并且具体地体现在第二通信协议上。因此，将第二通信协议其中的流程和逻辑提取出来并以用户态堆栈形式进行固化，从而有利于根据所述用户态协议栈以完成原本的第二通信协议所提供的功能，也就是根据所述数据处理请求协调所述一个或者多个第二节点，从而使得所述一个或者多个第二节点各自通过DMA或者RDMA执行所述数据处理操作。在一些实施例中，所述至少一个第一节点还配置为：通过所述第二通信协议将所述数据处理请求发送给所述一个或者多个第二节点。

在一种可能的实施方式中，所述至少一个第一节点基于所述用户态协议栈进行的数据通信涉及所述至少一个第一节点的操作系统的用户空间并且不涉及所述操作系统的内核空间。如此，有利于通过所述用户态协议栈实现全用户态的运算及操作。

在一种可能的实施方式中，所述数据库或者所述数据处理系统是分布式数据库，所述第一节点是协调节点CN，所述第二节点是数据节点DN，所述CN可协调所述DN从而使得所述DN各自通过DMA或者所述DN之间通过RDMA对所述CN发送的数据请求进行处理。当该分布式数据库的各个DN是分散在不同服务器或主机上时，所述CN可协调所述DN从而使得所述DN通过远程直接内存访问RDMA对所管理的业务数据执行数据处理操作。在一些实施例中，所述第一通信需求基于传输控制协议/互联协议TCP/IP协议。在一些实施例中，所述用户态协议栈包括以堆栈形式固化的TCP/IP协议。这里，分布式数据库可以是例如图1所示的分布式数据库，第一节点可以对应图1所示的协调节点104，第二节点可以对应数据节点106和数据节点108。如上所述，图1所示的数据库的数据通信，包括与外部的用户102的数据通信以及数据库的节点之间的数据通信，具有各种不同的通信需求以及在报文长短、发生频次及数据量大小等方面具有不同的特点。通过图2至图4所示的数据库，包括本申请提供的各种实施例、实施方式、实现方式，可以迎合这些不同的通信需求，特别是兼容应用端如用户102的个性化需求，同时还满足第二节点(即数据节点)各自通过DMA(第二节点或者DN位于同一台物理机器上)或者第二节点之间通过RDMA(第二节点或者DN位于不同物理机器上)执行所述数据处理操作的需求，从而同时做到了在CN节点上使用用户态协议栈实现与客户端程序(如用户102或者应用端)的网络通信，使得分布式数据库在兼容客户端程序的前提下降低网络通信带来的内核处理性能损耗，以及在DN节点上应用DMA技术和RDMA技术从而避免了操作系统的调用、用户态和内核态切换及数据拷贝所带来的性能损耗。

在一种可能的实施方式中，所述数据库是单机数据库，所述第一节点是本地数据节点，所述第二节点是相对于所述应用端的另一应用端。在一些实施例中，所述第一通信需求基于局域网通信协议或者内部总线通信协议。在一些实施例中，所述用户态协议栈包括以堆栈形式固化的局域网通信协议或者内部总线通信协议。针对单机数据库(也可以理解为包括位于同一个局域网或者内部网络的节点所构建的数据库)的情况，第二节点可以通过DMA特别是本地的DMA来执行所述数据处理操作。实践中，有时候存在同一个主机上的不同存储区域或者不同分区需要采用不同的安全标准、访问机制，例如两个不同的操作系统各自所在的区域，或者两种不同安全级别的区域(如可信执行环境(trusted executionenvironment，TEE)和不可信执行环境)，再例如两种不同访问限制的区域(如基于SGX技术的内核级安全访问限制)，这些情况下，应用端和另一应用端之间适合通过第一节点如本地数据节点，来完成数据处理请求的发起和响应。另外，有时候不同的应用端之间存在需要同步或者主次备份的情况，例如不同应用端如某个应用端和另一应用端都是第一节点的备份，这时候也适合建立起在应用端之间通过第一节点如本地数据节点来完成数据拷贝、数据转移等数据处理请求。如上所述，在分布式数据库下需要同时兼顾应用端的个性化需求(对应第一通信需求例如TCP/IP协议)和协调第二节点以应用RDMA或者DMA的需求(对应第二通信需求)类似地，在单机数据库下也需要同时兼顾应用端的个性化需求(对应第一通信需求，例如局域网通信协议或者内部总线通信协议)和协调另一应用端以应用DMA的需求(对应第二通信需求)。因此，通过用户态协议栈进行全用户态下的运算及操作来执行数据库，例如分布式数据库和单机数据库的数据通信，有利于改进数据库的数据通信从而避免性能损耗及提升整体系统性能。

在一种可能的实施方式中，所述第一通信需求，包括来自所述应用端的第一通信协议，所述第二通信需求，包括用于所述至少一个第一节点根据所述来自应用端的数据处理请求，协调所述一个或者多个第二节点的第二通信协议，所述用户态协议栈至少基于第一通信协议和所述第二通信协议的堆栈形式固化。如上所述，所述至少一个第一节点基于用户态协议栈和至少一个第二节点通信。所述第一节点，基于所述用户态协议栈，接收来自应用端的数据处理请求；所述第一节点，基于所述用户态协议栈，基于所述应用端的数据处理请求，向所述至少一个第二节点发送数据请求。在一些实施例中，所述用户态协议栈从多种预设用户态协议栈中选择。这里，所述用户态协议栈用于第一节点和第二节点之间的通信，以及所述第二节点基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过DMA或者所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。因此，可以事先按照不同的应用端的不同需求以及节点之间通信的需求，按照其可能的组合情况，例如第一通信协议和第二通信协议的可能组合，进行封装得到不同的预设用户态协议栈。然后从多种预设用户态协议栈中选择所述用户态协议栈，并且基于所选择的用户态协议栈来完成上述的操作和步骤。用户态协议栈扮演了在应用端的第一通信需求和用于协调第二节点的第二通信需求之间的桥梁，也就是促成了第一通信需求和第二通信需求各自所代表的协议适配，同时还使得第一节点可以通过用户态协议栈来实现路由，例如确定为了响应当前应用端的数据处理请求而适配的第一节点的IP地址及接口信息，以及第二节点的IP地址及接口信息，进而实现了通过用户态协议栈进行全用户态下的运算及操作来执行数据库的数据通信。应用端的需求虽然是难以预料的，但是有可能可以确定其可能的变化范围。而另一方面，数据库的第二节点，例如数据节点，各自所采用的DMA或者RDMA技术的有关规格是可以预先确定的，这意味着，不同的应用端的不同需求以及节点之间通信的需求，其中的可行的可能的排列组合或者根据经验、历史数据、机器学习模型等预测的高概率(如高于某个阈值)的组合，确定多种预设用户态协议栈，从而可以预先对这些多种预设用户态协议栈进行有关逻辑、算法、流程的固化，这样就提高了整体系统运行效率。

在一种可能的实施方式中，所述用户态协议栈通过代理通信库进行接口封装，所述代理通信库用于自适应选择用于所述第一节点和所述第二节点之间通信的用户态协议栈。在一些实施例中，所述代理通信库还用于对TCP/IP协议栈和RDMA进行接口封装。在一些实施例中，所述代理通信库包括统一化通信模型接口。代理通信库将传统TCP/IP接口，用户态协议栈接口以及RDMA接口进行封装，然后在代理通信库内部，根据数据库部署配置文件中的各个CN节点和各个DN节点的IP或者端口信息来自适应选择合适的通信协议进行数据传输。因此，通过代理通信库实现接口统一调配，以及使得所述用户态协议栈可以适配不同数据以兼容应用端的需求。节点的变化，例如新的节点的增加或者现有节点的退出，可以通过更新代理通信库来体现节点的最新状态，还可以通过更新代理通信库来体现应用端的需求的变化。图7为本申请实施例提供的代理通信库的示意图。如图7所示，代理通信库700将TCP/IP接口702，用户态协议栈接口704以及RDMA接口706进行封装。数据库部署配置文件710包括CN节点712的IP/端口信息和CN节点714的IP/端口信息；数据库部署配置文件710还包括DN节点722的IP/端口信息和DN节点724的IP/端口信息。代理通信库700可以根据数据库部署配置文件710所包括的各个CN节点的IP/端口信息和数据库部署配置文件720所包括的各个DN节点的IP/端口信息来自适应选择合适的通信协议进行数据传输。应当理解的是，图7所示的代理通信库700仅为示例性，数据库部署配置文件可以包括任意数量的CN节点和DN节点的IP/端口信息。

图5为本申请实施例提供的数据处理方法的流程示意图。所述数据处理方法应用于数据处理系统，所述数据处理系统包括：至少一个第一节点和至少一个第二节点，所述至少一个第一节点和所述至少一个第二节点基于用户态协议栈通信。如图5所示，数据处理方法包括以下步骤。

步骤S502：所述第一节点，基于所述用户态协议栈，接收来自应用端的数据处理请求。

步骤S504：所述第一节点，基于所述应用端的数据处理请求，向所述至少一个第二节点发送数据请求。

请参阅图5所示的数据处理方法，在一种可能的实施方式中，所述第二节点被配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过DMA或者所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。如此，实现了通过用户态协议栈进行全用户态下的运算及操作来执行数据库的数据通信，有利于通过用户态协议栈兼容应用端的个性化需求并且减少系统调用等开销，还有利于减少数据拷贝、内核旁路化、减少主机干预、节省远程主机处理器资源，进而有利于改进数据库的数据通信从而避免性能损耗及提升整体系统性能。

在一种可能的实施方式中，所述第一节点配置为：基于所述用户态协议栈，根据所述应用端的数据处理请求协调所述第二节点，从而使得所述第二节点各自通过DMA或者使得所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。

在一种可能的实施方式中，所述至少一个第一节点基于所述用户态协议栈进行的数据通信涉及所述至少一个第一节点的操作系统的用户空间，并且不涉及所述操作系统的内核空间。

在一种可能的实施方式中，所述第一节点和所述第二节点均属于分布式数据库，所述第一节点是CN，所述第二节点是DN，所述CN可协调所述DN从而使得所述DN各自通过DMA或者所述DN之间通过RDMA对所述CN发送的数据请求进行处理。

在一种可能的实施方式中，所述用户态协议栈包括以堆栈形式固化的传输控制协议/互联协议TCP/IP协议。

在一种可能的实施方式中，所述第一节点和所述第二节点均属于单机数据库，所述第一节点是本地数据节点，所述第二节点是相对于所述应用端的另一应用端。

在一种可能的实施方式中，所述用户态协议栈包括以堆栈形式固化的局域网通信协议或者内部总线通信协议。

在一种可能的实施方式中，所述用户态协议栈从多种预设用户态协议栈中选择。

在一种可能的实施方式中，所述用户态协议栈通过代理通信库进行接口封装，所述代理通信库用于自适应选择用于所述第一节点和所述第二节点之间通信的用户态协议栈。

在一种可能的实施方式中，所述代理通信库还用于对TCP/IP协议栈和RDMA进行接口封装。

在一种可能的实施方式中，所述代理通信库包括统一化通信模型接口。以上所提及的数据处理方法，包括各种实施例，实现方式，实施方式及变种，其有关原理、细节及有益技术效果，可以参考数据库的实施例，实现方式，实施方式及变种，在此不再赘述。

参见图6，图6是本申请实施例提供的一种计算设备的结构示意图，计算设备可以是服务器，该计算设备600包括：一个或者多个处理器610、通信接口620以及存储器630。所述处理器610、通信接口620以及存储器630通过总线640相互连接。可选地，该计算设备600还可以包括输入/输出接口650，输入/输出接口650连接有输入/输出设备，用于接收用户设置的参数等。该计算设备600能够用于实现上述的本申请实施例中设备实施例或者系统实施例的部分或者全部功能；处理器610还能够用于实现上述的本申请实施例中方法实施例的部分或者全部操作步骤。例如，该计算设备600执行各种操作的具体实现可参照上述实施例中的具体细节，如处理器610用于执行上述方法实施例中部分或者全部步骤或者上述方法实施例中的部分或者全部操作。再例如，本申请实施例中，计算设备600可用于实现上述装置实施例中一个或者多个部件的部分或者全部功能，此外通信接口620具体可用于为了实现这些装置、部件的功能所必须的通信功能等，以及处理器610具体可用于为了实现这些装置、部件的功能所必须的处理功能等。应当理解的是，图6的计算设备600可以包括一个或者多个处理器610，并且多个处理器610可以按照并行化连接方式、串行化连接方式、串并行连接方式或者任意连接方式来协同提供处理能力，或者多个处理器610可以构成处理器序列或者处理器阵列，或者多个处理器610之间可以分成主处理器和辅助处理器，或者多个处理器610之间可以具有不同的架构如采用异构计算架构。另外，图6所示的计算设备600，相关的结构性描述及功能性描述是示例性且非限制性的。在一些示例性实施例中，计算设备600可以包括比图6所示的更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者具有不同的部件布置。

处理器610可以有多种具体实现形式，例如处理器610可以包括中央处理器(central processing unit，CPU)、图形处理器(graphic processing unit，GPU)、神经网络处理器(neural-network processing unit，NPU)、张量处理器(tensor processingunit，TPU)或数据处理器(data processing unit，DPU)等一种或多种的组合，本申请实施例不做具体限定。处理器610还可以是单核处理器或多核处理器。处理器610可以由CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application-specific integratedcircuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(generic array logic，GAL)或其任意组合。处理器610也可以单独采用内置处理逻辑的逻辑器件来实现，例如FPGA或数字信号处理器(digital signal processor，DSP)等。通信接口620可以为有线接口或无线接口，用于与其他模块或设备进行通信，有线接口可以是以太接口、局域互联网络(local interconnect network，LIN)等，无线接口可以是蜂窝网络接口或使用无线局域网接口等。

存储器630可以是非易失性存储器，例如，只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。存储器630也可以是易失性存储器，易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhancedSDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。存储器630也可用于存储程序代码和数据，以便于处理器610调用存储器630中存储的程序代码执行上述方法实施例中的部分或者全部操作步骤，或者执行上述设备实施例中的相应功能。此外，计算设备600可能包含相比于图6展示的更多或者更少的组件，或者有不同的组件配置方式。总线640可以是快捷外围部件互连标准(peripheral component interconnect express，PCIe)总线，或扩展工业标准结构(extended industry standard architecture，EISA)总线、统一总线(unified bus，Ubus或UB)、计算机快速链接(compute express link，CXL)、缓存一致互联协议(cachecoherent interconnect for accelerators，CCIX)等。总线640可以分为地址总线、数据总线、控制总线等。总线640除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

本申请实施例还提供一种系统，该系统包括多个计算设备，每个计算设备的结构可以参照上述图6所描述的计算设备的结构。该系统可实现的功能或者操作可以参照上述方法实施例中的具体实现步骤和/或上述装置实施例中所描述的具体功能，在此不再赘述。本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，当所述计算机指令在计算机设备(如一个或者多个处理器)上运行时可以实现上述方法实施例中的方法步骤。所述计算机可读存储介质的处理器在执行上述方法步骤的具体实现可参照上述方法实施例中所描述的具体操作和/或上述装置实施例中所描述的具体功能，在此不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。本申请实施例可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(如软盘、硬盘、磁带)、光介质、或者半导体介质。半导体介质可以是固态硬盘，也可以是随机存取存储器，闪存，只读存储器，可擦可编程只读存储器，电可擦可编程只读存储器，寄存器或任何其他形式的合适存储介质。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述。可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并或删减；本申请实施例系统中的模块可以根据实际需要进行划分、合并或删减。如果本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (23)

1.一种数据处理系统，其特征在于，所述数据处理系统包括：至少一个第一节点和至少一个第二节点，其中所述至少一个第一节点和所述至少一个第二节点基于用户态协议栈通信；

所述第一节点，被配置为：基于所述用户态协议栈，接收来自应用端的数据处理请求，基于所述应用端的数据处理请求，向所述至少一个第二节点发送数据请求；

所述第二节点，被配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过直接内存访问DMA或者所述第二节点之间通过远程直接内存访问RDMA对所述第一节点发送的数据请求进行处理。

2.根据权利要求1所述的数据处理系统，其特征在于，所述第一节点还配置为：基于所述用户态协议栈，根据所述应用端的数据处理请求协调所述第二节点，从而使得所述第二节点各自通过DMA或者使得所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。

3.根据权利要求1所述的数据处理系统，其特征在于，所述至少一个第一节点基于所述用户态协议栈进行的数据通信涉及所述至少一个第一节点的操作系统的用户空间，并且不涉及所述操作系统的内核空间。

4.根据权利要求1所述的数据处理系统，其特征在于，所述数据处理系统是分布式数据库，所述第一节点是协调节点CN，所述第二节点是数据节点DN，所述CN可协调所述DN从而使得所述DN各自通过DMA或者所述DN之间通过RDMA对所述CN发送的数据请求进行处理。

5.根据权利要求4所述的数据处理系统，其特征在于，所述用户态协议栈包括以堆栈形式固化的传输控制协议/互联协议TCP/IP协议。

6.根据权利要求1所述的数据处理系统，其特征在于，所述数据处理系统是单机数据库，所述第一节点是本地数据节点，所述第二节点是相对于所述应用端的另一应用端。

7.根据权利要求6所述的数据处理系统，其特征在于，所述用户态协议栈包括以堆栈形式固化的局域网通信协议或者内部总线通信协议。

8.根据权利要求1所述的数据处理系统，其特征在于，所述用户态协议栈从多种预设用户态协议栈中选择。

9.根据权利要求1所述的数据处理系统，其特征在于，所述用户态协议栈通过代理通信库进行接口封装，所述代理通信库用于自适应选择用于所述第一节点和所述第二节点之间通信的用户态协议栈。

10.根据权利要求9所述的数据处理系统，其特征在于，所述代理通信库还用于对TCP/IP协议栈和RDMA进行接口封装。

11.根据权利要求9所述的数据处理系统，其特征在于，所述代理通信库包括统一化通信模型接口。

12.一种数据处理方法，其特征在于，所述数据处理方法应用于数据处理系统，所述数据处理系统包括：至少一个第一节点和至少一个第二节点，所述至少一个第一节点和所述至少一个第二节点基于用户态协议栈通信；所述数据处理方法包括：

所述第一节点，基于所述用户态协议栈，接收来自应用端的数据处理请求；

所述第一节点，基于所述应用端的数据处理请求，向所述至少一个第二节点发送数据请求。

13.根据权利要求12所述的数据处理方法，其特征在于，所述第二节点被配置为：基于所述用户态协议栈，接收第一节点发送的所述数据请求，并且各自通过DMA或者所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。

14.根据权利要求13所述的数据处理方法，其特征在于，所述第一节点配置为：基于所述用户态协议栈，根据所述应用端的数据处理请求协调所述第二节点，从而使得所述第二节点各自通过DMA或者使得所述第二节点之间通过RDMA对所述第一节点发送的数据请求进行处理。

15.根据权利要求13所述的数据处理方法，其特征在于，所述至少一个第一节点基于所述用户态协议栈进行的数据通信涉及所述至少一个第一节点的操作系统的用户空间，并且不涉及所述操作系统的内核空间。

16.根据权利要求13所述的数据处理方法，其特征在于，所述第一节点和所述第二节点均属于分布式数据库，所述第一节点是CN，所述第二节点是DN，所述CN可协调所述DN从而使得所述DN各自通过DMA或者所述DN之间通过RDMA对所述CN发送的数据请求进行处理。

17.根据权利要求16所述的数据处理方法，其特征在于，所述用户态协议栈包括以堆栈形式固化的传输控制协议/互联协议TCP/IP协议。

18.根据权利要求13所述的数据处理方法，其特征在于，所述第一节点和所述第二节点均属于单机数据库，所述第一节点是本地数据节点，所述第二节点是相对于所述应用端的另一应用端。

19.根据权利要求18所述的数据处理方法，其特征在于，所述用户态协议栈包括以堆栈形式固化的局域网通信协议或者内部总线通信协议。

20.根据权利要求13所述的数据处理方法，其特征在于，所述用户态协议栈从多种预设用户态协议栈中选择。

21.根据权利要求13所述的数据处理方法，其特征在于，所述用户态协议栈通过代理通信库进行接口封装，所述代理通信库用于自适应选择用于所述第一节点和所述第二节点之间通信的用户态协议栈。

22.根据权利要求21所述的数据处理方法，其特征在于，所述代理通信库还用于对TCP/IP协议栈和RDMA进行接口封装。

23.根据权利要求21所述的数据处理方法，其特征在于，所述代理通信库包括统一化通信模型接口。

Images