CN114254036A - 数据处理方法以及系统 - Google Patents

Abstract

本说明书实施例提供数据处理方法以及系统，其中所述数据处理方法，应用于分布式数据处理系统的数据处理节点，包括：接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求；将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

Description

数据处理方法以及系统

技术领域

本说明书实施例涉及计算机技术领域，特别涉及一种数据处理方法。本说明书一个或者多个实施例同时涉及一种数据处理系统，一种计算设备，以及一种计算机可读存储介质。

背景技术

数据库采用多主MPP(Massive Parallel Processing)架构。该系统由两组计算机节点组成：主节点和数据节点。数据库依赖于一个称为全局事务管理器(GTM)的组件来支持快照隔离。尽管GTM组件可以通过多进程或多线程实现以提高其并行性，但它本质上是中心化的，并且随着并发事务数量的增加与GTM组件的连接数量会大幅度地增加，不仅会对GTM组件的运行造成较大的压力，也会成为整个分布式数据库系统严重的系统瓶颈。

发明内容

有鉴于此，本说明书施例提供了一种数据处理方法。本说明书一个或者多个实施例同时涉及一种数据处理系统，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种数据处理方法，应用于分布式数据处理系统的数据处理节点，包括：

接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求；

将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

根据本说明书实施例的第二方面，提供了一种数据处理系统，所述数据处理系统包括数据处理节点，所述数据处理节点包括：

请求接收模块，被配置为接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求；

代理模块，被配置为将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

根据本说明书实施例的第三方面，提供了一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，其中，所述处理器执行所述计算机可执行指令时实现所述数据处理方法的步骤。

根据本说明书实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现所述数据处理方法的步骤。

本说明书一个实施例提供的数据处理方法，应用于分布式数据处理系统的数据处理节点，包括：接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求；将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

具体的，通过在数据处理节点中对接收到的客户端发送的多个数据处理请求进行限流处理，按照一定数量的数据处理请求，分批次地处理由客户端发送的所有数据处理请求，能够减少数据处理节点的请求处理的压力，并且，后续将目标数据处理请求转发至全局事务管理器中也能提高全局事务管理器的处理效率，提升整个分布式数据处理系统的处理性能。

附图说明

图1是本说明书一个实施例提供的一种数据处理方法的多主分布式数据库架构；

图2是本说明书一个实施例提供的一种数据处理系统的整体架构图；

图3是本说明书一个实施例提供的一种数据处理方法应用于分布式数据处理系统的数据处理节点的流程图；

图4是本说明书一个实施例提供的一种数据处理方法的共享内存区域的结构示意图；

图5是本说明书一个实施例提供的一种数据处理方法的共享内存区域的处理插槽各种状态转换示意图；

图6是本说明书一个实施例提供的一种数据处理装置的结构示意图；

图7是本说明书一个实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本说明书一个或多个实施例涉及的名词术语进行解释。

事务：在数据库管理系统中，事务是单个逻辑或工作单元，有时由多个操作组成。在数据库中以一致模式完成的任何逻辑计算都称为事务。一个例子是从一个银行账户到另一个银行账户的转账：完整的交易需要从一个账户中减去要转账的金额，然后将相同的金额添加到另一个账户中。

数据库事务：根据定义，数据库事务必须是原子的(它必须完整地完成或没有任何影响)、一致的(它必须符合数据库中现有的约束)、隔离的(它不能影响其他事务)和持久的(它必须写入持久存储)。数据库从业者经常使用首字母缩写词ACID来指代数据库事务的这些属性。

分布式数据库：是将数据存储在不同物理位置的数据库。它可能存储在位于同一物理位置(例如数据中心)的多台计算机中；或者可能分散在互连的计算机网络上。

多主架构：是构建分布式数据库系统的流行方式。在这种架构中，分布式数据库系统由两组计算机节点组成：主节点和数据节点。每个主节点都保留了系统目录和元数据(例如，表和索引定义)的最新副本。数据库的数据存储在多个数据节点中，受用户指定的分区和/或复制策略的约束。

数据库会话：表示应用程序(或客户端)与存储其持久对象的数据库之间的连接。通常通过TCP网络协议建立连接。一旦建立了会话，客户端应用程序就可以通过与数据库的连接发送SQL语句来查询和操作数据库中的数据。在数据库系统方面，数据库可以使用进程或线程来接收和服务来自会话的所有SQL语句。一旦客户端应用程序与会话断开连接，数据库系统就会取消分配与会话关联的任何资源(例如处理进程或线程)。

多版本并发控制(MVCC)：多版本并发控制(MCC或MVCC)，是数据库管理系统常用的一种并发控制方法，用于提供对数据库的并发访问。当MVCC数据库需要更新一条数据时，它不会用新数据覆盖原始数据项，而是创建数据项的更新版本。因此存储了多个版本。每个事务看到的版本取决于实现的隔离级别。MVCC实现的最常见的隔离级别是快照隔离。使用快照隔离，事务观察事务开始时的数据状态。

快照隔离：快照隔离是保证在一个事务中进行的所有读取都将看到数据库的一致快照(实际上它读取的是在它开始时存在的最后提交的值)，并且只有在自己所做的更新与自快照开始以后来自其他事物所做的更新没有冲突的情况下，该事务的更新才能成功提交。

代理(代理服务器)：在计算机网络中，代理服务器是一种服务器应用程序或设备，它充当客户端请求的中介，从提供这些资源的服务器寻求资源。因此，代理服务器在请求服务时代表客户端运行，可能会掩盖对资源服务器的请求的真实来源。客户端不是直接连接到可以满足请求资源(例如文件或网页)的服务器，而是将请求定向到代理服务器，代理服务器评估请求并执行所需的网络事务。这是一种简化或控制请求复杂性的方法，或提供额外的好处，例如负载平衡、隐私或安全性。

数据库采用多主MPP(Massive Parallel Processing)架构。该系统由两组计算机节点组成：主节点和数据节点。每个主节点都保留了系统目录和元数据(例如，表和索引定义)的最新副本。数据库的数据存储在多个数据节点中，受用户指定的分区和/或复制策略的约束。

客户端连接到其中一个主机(例如，通过TCP网络协议)以建立数据库会话，然后可以通过该连接提交SQL语句。对于来自客户端的每条SQL语句，相应的主节点都会解析该SQL语句，生成优化的查询计划，并将查询计划分派到数据节点执行。每个数据节点用本地存储的数据执行主节点发送的查询计划，必要时相互交换中间数据，最后将查询结果发送回主节点。主节点合并组装最终查询结果并发回客户端。

具体可参见图1，图1示出了本说明书实施例提供的一种数据处理方法的多主分布式数据库架构。

图1中分布式数据库架构为具有两个主数据库节点的分布式数据库，分别为主节点1和主节点2，每个主节点对应具有两个客户端，主节点1对应的客户端分别为客户端1和客户端2，主节点2对应的客户端分别为客户端3和客户端4，同时，两个主节点所对应的数据节点分别为数据节点1、数据节点2、数据节点3、数据节点4，且该多主分布式数据库架构中还具有全局事务管理器(GTM)。

具体实施时，图1中每组矩形代表用于在一个数据库会话中运行事务的进程或线程。数据库支持符合SQL标准的ACID属性的数据库事务。事实上，任何提交给数据库的SQL语句都是在一个数据库事务中执行的。此类事务要么由客户端通过BEGIN/COMMIT/ABORT语句显式指定，要么由数据库系统在客户端未显示指定事务范围时为单个SQL语句隐式和内部创建。

数据库中的事务通常涉及为事务的SQL语句创建和调度查询计划的阶段，以及执行查询的多个数据节点。如果事务包含修改系统目录和元数据的DDL(数据定义语言)语句(例如，CREATE TABLE)，则事务也将跨越系统中的所有其他主数据。由于事务涉及多个分布式计算机节点，因此使用分布式事务协议来确保事务满足ACID属性。特别是，数据库采用标准的两阶段提交协议。主节点充当分布式事务的协调器，所涉及的数据节点(分节点)和其他主节点充当参与者。当事务中的工作完成时，协调器启动称为“准备”(或“投票”)的第一阶段：它要求每个参与者投票是否应该提交事务；每个参与者根据其本地执行结果以自己的投票(提交或中止)进行回复。如果协调器收到所有参与者的提交投票，那么它启动称为“提交”的第二阶段：它要求所有参与者在本地提交事务，一旦所有参与者都确认他们已完成，协调器提交分布式事务。如果协调器在准备阶段收到参与者的任何中止投票，它会要求所有参与者在本地中止事务并中止分布式事务。

进一步地，数据库依赖于一个称为全局事务管理器(GTM)的组件来支持快照隔离，这是用于管理并发事务的多版本并发控制机制的流行变体。GTM是分布式数据库中的中心化服务，负责为事务分配唯一标识符，跟踪分布式事务的状态(状态为进行中、已提交或已中止)，并生成分布式快照。

当一个主节点开始一个分布式事务时，它会向GTM发送一个请求，要求将新事务注册到GTM并为这个事务分配一个唯一的标识符(称为全局事务ID或简称GXID)。全局事务ID唯一标识一个事务。每当事务在数据库表中插入或修改行时，行数据的一个版本就会存储在表中，其中包含数据有效负载和事务ID。事务ID在内部实现为对数据库用户透明的隐藏列。

交易在GTM注册后，GTM将其状态设置为进行中。稍后当相应的主节点提交或中止事务时，主节点通知GTM更改，GTM相应地设置事务状态。

当主节点将事务中的查询分派到数据节点(Remove)时，它会向GTM发送一个分布式快照请求。分布式快照的内容指明了当时正在进行哪些事务(根据其全局事务ID)。为了计算分布式快照，GTM检查其事务状态的跟踪记录并返回当前所有的活动事务的ID。这种分布式快照与查询计划一起发送到数据节点。当一个数据节点执行查询并需要访问表中的行时，它使用分布式快照来确定该行的某个版本对于当前事务是否可见。例如，如果执行中的事务ID列在分布式快照中的进行中事务集中，则当前事务不应读取此版本，否则将从未提交的事务中读取数据并违反隔离属性。

尽管GTM组件可以通过多进程或多线程实现以提高其并行性，但它本质上是中心化的，并且随着并发事务数量的增加会成为严重的系统瓶颈。为高并发扩展GTM的主要障碍有两个：

第一，在多主分布式数据库中，假设每个主节点最多可以接受N个客户端会话，并且有M个主节点，那么系统在任何时候最多可以有N x M个并发会话。如果每个会话都与GTM建立自己的TCP连接，则GTM将需要处理最多N x M个连接。在高并发的大型部署中，这可能会超过单台机器的TCP连接限制。由于拥有多个主节点的全部好处是为客户端提供超出单台机器容量的可扩展连接点，因此将每个会话连接到集中式GTM将违背多主架构的基本目的。

第二，即使GTM可以从单个会话中为这么多连接提供服务，它也会失去提高效率的大量机会。比如，假设在同一个主节点上有K个并发会话，并且它们都在执行只读事务。只读事务是不修改或插入任何数据的事务。如果每个会话与GTM建立自己的连接，并从自己的连接发送分布式快照请求，GTM将收到K个这样的请求，计算K次分布式快照并将K个结果发回。然而，这是多余且不必要的，GTM可以使用计算的第一个分布式快照作为对来自这些只读事务的所有K个并发快照请求的响应。如果主节点可以将K个并发请求合并为一个请求，让GTM只计算一次分布式快照，然后将返回的结果取出，我们可以将网络消息的数量和GTM完成的工作量减少K倍，并将它们返回给K个事务。即使对于来自同一个主节点的不同并发请求(例如，一个session正在请求全局事务ID，另一个session正在请求分布式快照)，批量发送这些请求通常比从单独的连接单独发送它们更有效。

然而，对于上述第一个问题，在现有技术中可能会认为UDP等无连接网络协议可以克服连接限制，但结果是增加了系统实现的复杂性，以确保与GTM的可靠通信。此外，使用UDP根本无助于解决第二个问题。

在后续的分布式数据处理系统的发展中，Postgres-XL是一个多主分布式数据库，也采用了集中式全局事务管理器(GTM)。Postgres-XL中的GTM作为一个多线程的独立进程实现，负责事务ID分配、事务状态跟踪和分布式快照计算。主节点上的用户数据库会话可以直接连接到GTM以请求事务ID、通知状态更改或请求分布式快照。或者，数据库可以部署多个GTM代理进程，并让用户的数据库会话连接到其中一个GTM代理。GTM代理将请求转发到GTM服务器并将响应发送回用户会话。

由此可知，Postgres-XL是使用代理模块来提高中心化GTM的可扩展性，但还会具有四个明显的缺陷：第一，Postgres-XL中的GTM代理仅支持TCP连接和与主节点上用户数据库会话的通信。即使GTM代理和用户的数据库会话运行在同一个主节点上，它们也通过TCP相互通信。由于额外的内存副本和不必要的网络堆栈开销，这种通信的效率低于其他基于共享内存的通信机制。第二，当有多个GTM代理时，Postgres-XL没有指定如何以负载平衡的方式将用户的数据库会话分配给这些GTM代理。第三，当Postgres-XL中的GTM代理同时收到多个并发请求时，它会将这些请求打包成一条消息并发送给GTM服务器，并解压GTM服务器发回的所有响应。但是，Postgres-XL中的GTM代理不会检测或消除冗余并发请求(例如来自并发只读事务的多个分布式快照请求)。第四，Postgres-XL不允许单个数据库会话选择是直接连接还是通过GTM代理连接到GTM。该设置是系统范围的，不能在不重新启动数据库系统的情况下动态更改。这不灵活，不能支持多个用户需要同时使用不同的连接方式到GTM的情况。例如，数据库系统可能会限制普通用户的数据库会话使用GTM代理，但允许高优先级用户或系统管理员使用GTM专用连接来处理紧急或维护任务。而本说明书提供的数据处理方法将允许单个用户会话动态选择是直接连接GTM还是使用GTM代理，相比较与Postgres-XL，该方法将会更加灵活运用，可以更好地服务于混合使用的场景。

综上，本说明书实施例提供的数据处理方法，提出了一种基于代理的方法，以解决多主分布式数据库中集中式GTM的可扩展性挑战，需要说明的是，本说明书提出的方法并不限于数据库中使用的特定分布式事务协议(如Two-Phase Commit)和并发控制机制(如Snapshot Isolation)，可广泛适用于任何采用集中事务管理的多主分布式数据库。

在本说明书中，提供了一种数据处理方法，本说明书同时涉及一种数据处理系统，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图2示出了根据本说明书一个实施例提供的一种数据处理系统的整体架构图。

需要说明的是，本说明书实施例提供的数据处理方法提出使用代理模块，来提高多主分布式数据库中集中式全局事务管理器(GTM)的持久性和可扩展性。具体的，所述数据处理系统包括数据处理节点，其中，所述数据处理节点包括：请求接收模块，被配置为接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求；代理模块，被配置为将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

图2中分布式数据处理系统的整体架构为具有两个主数据库节点的分布式数据库，分别为主节点1(master1)和主节点2(master2)，每个主节点均对应具有两个客户端，主节点1对应的客户端分别为客户端1和客户端2，主节点2对应的客户端分别为客户端3和客户端4，同时，两个主节点所对应的数据节点分别为数据节点1、数据节点2、数据节点3、数据节点4，且该多主分布式数据库架构中还具有全局事务管理器(GTM)，需要说明的是，在主节点1和主节点2中分别配置了代理模块，同时，主节点中接收客户端发送的数据处理请求的模块与代理模块之间，通过共享内存区域进行通信连接。

实际应用中，分布式数据库中的每个主节点都配备了一组代理模块的进程或线程。每个代理模块在部署它的主数据库节点上为一个或多个用户数据库会话提供服务。每个用户数据库会话都可以动态选择直接或间接通过同一主数据库节点上的代理模块连接到GTM。当数据库会话选择使用代理并需要向GTM发出请求(例如，分配全局事务ID或获取分布式快照)时，它会将请求处理给相应的代理模块并等待其返回响应。收到来自用户数据库会话的至少一个请求后，如果还没有建立连接，代理模块会与GTM建立连接，并发送用户数据库会话发出的请求。GTM处理每个请求，并将响应发送回代理模块。对于从GTM收到的每个响应，代理模块确定它属于哪个数据库会话并将响应发送回数据库会话。代理模块和用户数据库会话通过高效的共享内存机制进行通信。进一步地，当有多个代理模块时，我们的方法以负载平衡的方式将用户会话分配给这些GTM的代理模块。代理模块会自动检测并消除并发事务对GTM的冗余请求，以减少到GTM的网络流量和GTM执行的工作量。又或者，本方法允许单个用户会话动态选择是直接连接到GTM还是使用GTM代理模块，能够更加灵活地服务于这种混合使用场景。

本说明书实施例提供的数据处理系统，在集中式全局事务管理器管理的多主分布式数据库中，利用配置在主数据库节点中的代理模块，基于高效的共享内存机制对接收到的数据处理请求进行限流处理，且在配置了多个代理模块的情况下，以负载均衡的方式将数据处理请求分配至代理模块，进而代理模块帮助GTM减少了数据冗余请求，也减少了全局事务管理的网络流量和GTM执行的工作量；进一步地，也允许单个用户会话动态选择是直接连接到GTM还是使用GTM代理模块，能够更加灵活地服务于这种混合使用场景。

参见图3，图3示出了本说明书一个实施例提供的一种数据处理方法应用于分布式数据处理系统的数据处理节点的流程图，具体包括以下步骤：

需要说明的是，本实施例提供的数据处理方法可适用于任何采用集中事务管理的多主分布式数据库，在此不做过多限定。

步骤302：接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求。

具体实施时，分布式数据处理系统的数据处理节点可以理解为分布式数据库的主节点，即数据写入节点，能够进行数据的读取、数据的写入等，而现有技术中主节点在接收多个客户端发送的多个数据处理请求之后，将该多个数据处理请求会直接转发至集中事务管理的全局事务管理器中，进而执行后续的数据事务的执行，但由于多个数据处理请求都直接与全局事务管理相连接，可能会导致由于全局事务管理器的连接数量过多而出现的系统崩溃的状态；由此，本说明书实施例提供的数据处理方法，在分布式数据库的主节点中就对多个数据处理请求进行限流处理，以便于能够减少全局事务管理器执行数据处理请求的数量。

实际应用中，分布式数据库的主节点接收到客户端发送的多个数据处理请求之后，将根据多个数据处理请求的数量确定同一时间处理的目标处理数量，并通过该目标处理数量对上述多个数据处理请求进行限流处理，进而筛选出目标数据处理请求；例如，分布式数据库的主节点接收了1000个数据处理请求，根据该1000个数据处理请求确定主节点在同一时间只能处理100个数据处理请求，因此，对该1000个数据处理请求进行限流处理，仅从1000个数据处理请求中按照请求的顺序获取100个数据处理请求作为目标数据处理请求。

而在分布式数据库的主节点接收到客户端的多个数据处理请求之前，数据库系统允许每个单独的用户会话动态指定是否使用代理模块或专用链接到GTM来执行会话中的事务；具体的，所述接收客户端发送的多个数据处理请求之前，还包括：

所述请求接收模块基于预设项目需求判断是否启动所述数据处理节点中的代理模块，若是，则向客户端发送数据处理指令，其中，所述数据处理指令为将所述客户端发送的请求转发至代理模块处理的指令。

需要说明的是，分布式数据库系统为了提高数据处理能力，以及减少全局事务管理器的事务处理压力，则可在分布式数据库的主节点中配置代理模块，代理处理多个数据处理请求，以减少全局事务管理器的网络流量和执行的工作量。

具体实施时，分布式数据库主节点中的请求接收模块还可根据不同的项目需求，确定是否启动该主节点中配置的代理模块，若确定基于该项目需求，需要大量的数据处理请求进行处理的情况下，则可同意启动代理模块，该主节点可向客户端发送数据处理指令，其中，该数据处理指令为将客户端发送的请求转发至代理模块处理的指令。

实际应用中，当数据库会话动态更改其连接模式时，它将遵循以下两个步骤之一：如果它当前与GTM有直接连接并且现在选择使用代理，则它关闭与GTM的连接，并获取共享内存通信槽以与代理交互。如果它当前使用共享内存通信槽，现在选择直接连接到GTM，那么它放弃共享内存通信槽，并建立到GTM的新的直接连接。数据库系统可能会设置配额或限制来限制哪些用户或会话可以使用直接连接到GTM。

本说明书实施例提供的数据处理方法，分布式数据库处理系统还可基于实际的项目需求，动态确定是否要使用配置在主节点中的代理模块，进而提高分布式数据处理系统的处理效率。

进一步地，所述数据处理节点包括请求接收模块、共享内存区域以及代理模块；

所述基于所述多个数据处理请求的数量确定目标处理数量之前，还包括：

所述请求接收模块基于所述共享内存区域与所述代理模块建立通信连接。

需要说明的是，在分布式数据库的主节点中包括请求接收模块、代理模块以及共享内存区域，代理模块是配置在主节点中，且代理模块可以代理主节点对数据处理请求进行限流处理的模块。

实际应用中，主节点中的请求接收模块可通过共享内存区域，与配置在主节点的代理模块建立通信连接，便于后续代理模块可从共享内存区域中获取请求接收模块发送的数据处理请求。

本说明书实施例提供的数据处理方法，在采用集中式全局事务管理器的多主分布式数据库中，每个主节点可配置代理模块，用于收集、组合和转发来自该主节点上用户会话的GTM请求，并将返回的响应返回至客户端，且代理模块与用户会话之间的通信是通过主节点上的高效共享内存机制运行的，以提高数据处理的效率。

更进一步地，可基于共享内存区域中的待分配处理插槽的数量，进而确定代理模块同一时间内处理数据处理请求的目标处理数量；具体的，基于所述多个数据处理请求的数量确定目标处理数量，包括：

所述请求接收模块基于所述多个数据处理请求的数量在所述共享内存区域中确定待分配处理插槽的数量，并将所述待分配处理插槽的数量作为目标处理数量。

实际应用中，分布式数据库系统可为每个主节点上分配一个共享内存区域，专用于用户的数据库会话和代理之间的数据交换，如果数据库系统是在单个进程中使用多个线程来实现的，那么这个共享内存区域可以分配在数据库系统中所有线程都可以访问的堆内存上，包括用户数据库会话线程和代理线程。如果数据库系统实现为多个进程，则可以在底层操作系统提供的共享内存区域上分配此共享内存区域，并使其可用到多个进程。

具体实施时，主节点中的请求接收模块可基于接收到的多个数据处理请求的数量，在共享内存区域中确定能够为多个数据处理请求分配的待处理插槽的数量，在初始化的状态下，待分配处理插槽的数量意味着同一时间内代理模块处理数据处理请求的数量。

本说明书实施例提供的数据处理方法，通过在共享内存区域中确定待分配处理插槽的数量，确定目标处理数量，以便于后续代理模块基于目标处理数量对多个数据处理请求进行限流处理。

为了使得代理模块对多个数据处理请求进行限流处理，可将数据处理请求放置于共享内存区域的处理插槽中；具体的，所述根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求，包括：

所述请求接收模块根据所述目标处理数量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中；

所述代理模块从所述待分配处理插槽中获取与所述目标处理数量相同的数据处理请求，并将所述数据处理请求作为目标数据处理请求。

实际应用中，分布式数据库主节点中的请求接收模块基于确定的目标处理数量，将与该目标处理数量相同的数据处理请求放置于共享内存区域的待分配处理插槽中，表示代理模块可在同一时间处理的数据处理请求在待分配的处理插槽中，进而实现对多个数据处理请求的限流处理，然后，代理模块可从待处理插槽中获取与该目标处理数量相同的数据处理请求，并将获取到的数据处理请求作为目标数据处理请求。

本说明书实施例提供的数据处理请求，通过将数据处理请求放置于共享内存区域的待分配处理插槽，且代理模块从待分配处理插槽中获取数据处理请求，实现对多个数据处理请求的限流处理，以提高分布式数据处理系统的数据处理效率。

基于上述代理模块对多个数据处理请求详细的限流处理过程，本实施例提供了数据处理方法用于与代理模块进行通信的共享内存区域的结构图，可参见图4，图4示出了本说明书一实施例提供的一种数据处理方法的共享内存区域的结构示意图。

图4中，共享内存区域包括两个部分，其中，一个部分是一组通信槽，通信槽中的每个插槽分配给一个用户数据库会话，并用于该用户数据库会话与代理交换GTM请求和响应。另一个部分为代理薄记，一个代理模块使用阵列的每个单元来跟踪各种状态。通信槽的数量是根据单个主节点上的最大用户数据库会话数设置的，这样可以保证每个用户数据库会话都有一个专用的共享内存通信槽。

实际应用中，共享内存区域中可能会有较多的处理插槽，但是需要对处理插槽进行配置后，才可使用，且在配置的过程中，还需要花费一些资源成本，因此如何高效地利用已经配置好的处理插槽，是节省资源成本的有效方式，进而，本实施例采用的方式为依据处理插槽中的信号量，确定该处理插槽的状态，是否是被占用的状态，在代理模块从处理插槽中获取数据处理请求之后，则该处理插槽即恢复为空闲状态，可为该处理插槽分配下一个数据处理请求；具体的，所述请求接收模块根据所述目标处理数量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中，包括：

所述请求接收模块基于所述目标处理数量确定所述共享内存区域的每个待分配处理插槽的信号量；

基于所述信号量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中，并修改所述待分配处理插槽中的通信状态。

需要说明的是，代理模块使用信号量，是来通知用户数据库会话有关插槽状态更改的信息，例如，代理模块将使用信用量唤醒等待响应准备好的用户会话，应该注意的是，信号量在每次数据交换的过程中可能会不同，比如，代理模块和用户数据库会话是单独的进程，它可以用POSIX信号量系统调用来实现，或者如果代理模块和用户数据库会话是同一进程中的不同线程，它可以作为pthead条件变量来实现。

具体实施时，分布式数据库主节点的请求接收模块可基于目标处理数量确定出共享内存区域的每个待分配处理插槽的信号量，并基于信号量将与所述目标处理数量相同的数据处理请求放置于共享内存区域的待分配处理插槽中，同时，还需修改待分配处理插槽的通信状态，便于后续根据待分配处理插槽的通信状态确定处理插槽是否能够放置数据处理请求。

实际应用中，插槽状态表示插槽的当前状态，在用户数据库会话和代理模块之间的通信期间，插槽会在各种状态之间转换，参见图5，图5示出了本说明书实施例提供的数据处理方法的共享内存区域的处理插槽各种状态转换示意图。

图5中表示各种插槽状态的转换示意图，分别有FREE(该插槽未被任何用户数据库会话使用)、EMPTY(插槽已分配给数据库用户会话，但尚未存放任何请求)、REQUEST_AVAIL(请求已存入插槽)、WAIT_RESPONSE(代理已经向GTM发送了请求，正在等待GTM的响应)、RESPONSE_AVAIL(未完成请求的响应已存储在槽中并准备好供数据库用户会话接收)、ERROR(服务当前请求时出错)、FREEING(插槽已被数据库会话放弃，并准备好回收)。

本实施例可以用户数据库会话获取共享内存通信槽的过程、用户数据库会话放弃通信槽的过程、用户数据库会话通过共享内存通信槽发送请求并接收响应的过程为例，说明插槽状态转换的过程：

用户数据库会话获取共享内存通信槽的过程如下：步骤1：获取通信槽阵列的排他锁；步骤2：遍历通信槽数组，找到状态为FREE的槽。若找到，则执行步骤3，若找不到该插槽，则执行步骤7；步骤3：将插槽的状态更改为EMPTY；步骤4：根据下一节描述的负载均衡策略分配一个代理来服务这个槽，并将这个槽的数组索引添加到代理的槽索引数组中。步骤5：解除对通讯槽阵列的排他锁；步骤6：安排一个回调函数，该函数将在此会话结束时执行以放弃获取的插槽；步骤7：返回是否成功获取通信槽。

一旦获得了通信槽，用户数据库会话就会继续使用它，直到会话结束。用户数据库会话放弃通信槽的过程如下：步骤1：将插槽的状态更改为FREEING；步骤2：在对应代理的记账数据中设置信号量(Semaphore)，通知代理槽状态的变化；代理将处理插槽的回收。

用户数据库会话通过共享内存通信槽发送请求并接收响应的过程如下：步骤1：将请求存入通信槽的Request buffer中。请求被格式化并序列化为连续的字节序列，通信槽的索引作为请求的一部分存储；步骤2：将插槽的状态更改为REQUEST_AVAIL；步骤3：在对应代理的记账数据中设置Semaphore，通知代理新请求的到来；步骤4：等待通信槽中的信号量以获取来自代理的通知；步骤5：收到代理模块(proxy)的Semaphore通知后，检查插槽状态：(1)如果状态为RESPONSE_AVAIL，表示该插槽的Response buffer中有响应；在这种情况下，将插槽状态更改为EMPTY并返回响应。(2)如果状态为ERROR，则将插槽状态更改为EMPTY并返回错误。(3)如果状态为REQUEST_AVAIL或WAIT_RESPONSE，则返回步骤4继续等待。

需要说明的是，数据处理请求是一个较大的缓冲区，可以存储对GTM的单个请求，当用户互数据库会话需要向GTM发出请求时，他会构造请求并将其存入请求缓冲区，然后代理模块从缓冲区读取请求并将其发送到GTM进行处理，用户数据库会话可以将请求格式化并序列化为特定的格式。而数据的响应的另一个缓冲区，能够存储来自GTM的单个响应，当代理模块收到来自GTM的响应时，他将响应存储到缓冲区，并通过插槽的信号量通知用户数据库会话其可用性。共享内存通信槽阵列受读写锁保护，该锁本身也驻留在共享内存区域中。当用户数据库会话需要获取一个槽时，它以写(或说独占)模式获取此锁，并选择一个空闲槽供使用。每个代理重复扫描通信槽以查找未完成的请求和已被数据库会话放弃并因此应回收的时隙；代理在扫描之前以读取(或说共享)模式获取此锁。

本说明书实施例提供的数据处理方法，通过信号量可以确定插槽的当前状态，且后续通过记录插槽的通信状态，能够实现高效地分配数据处理请求，便于后续提升处理数据处理请求的效率。

此外，在共享内存区域中还具有薄记数据的部分，该薄记数据是记录对应的代理模块的状态，比如和代理模块是连接状态还是断开状态，同时还会记录插槽的索引数据，记录有多少个插槽被使用，有多少个插槽被闲置，也即是说，共享内存区域中的薄记数据是记录代理模块本身的状态；具体的，所述请求接收模块根据所述目标处理数量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中之后，还包括：

所述请求接收模块基于所述与目标处理数量相同的数据处理请求，在所述共享内存区域中的代理薄记中记录所述待分配处理插槽的状态，并记录与所述代理模块的连接状态。

实际应用中，代理薄记可以理解为薄记数据(per-proxyData)，且在薄记数据中的单元数是根据主节点上的代理模块的数量设置的，每个代理模块的薄记数据包括以下字段：用户数据库会话使用信号量来通知代理模块新数据处理请求的到达或者通信槽的放弃，在收到通知时候，代理模块开始扫描通信时序以进行工作；代理标识(proxy_id)是拥有此薄记数据的代理的唯一标识；插槽的索引数据是由该代理模块服务的通信槽的索引数组，当主节点上有多个代理模块时，每个代理模块将服务一个插槽子集，其插槽索引数组标识这些插槽。

具体实施时，请求接收模块基于与目标处理数量相同的数据处理请求，在共享内存区域的代理薄记中记录待分配处理插槽的状态，同时，也可记录代理模块的状态。

本说明书实施例提供的数据处理方法，通过在共享内存区域的代理薄记中记录插槽的状态以及代理模块的状态，基于状态的转换与记录，不仅能够减少并发访问的冲突，也能减少资源开销。

步骤304：将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

实际应用中，分布式数据处理节点将确定的目标数据处理请求转发至全局事务管理器，在全局事务管理器对该数据处理请求进行处理之后，再向分布式数据处理节点返回对目标数据处理请求进行处理的处理结果，并将该处理结果返回至每个数据处理请求对应的客户端。

进一步地，所述将所述目标数据处理请求转发至全局事务管理器，包括：

所述代理模块在确定与所述全局事务管理器建立通信连接的情况下，基于所述通信连接将所述目标数据处理请求转发至所述全局事务管理器。

实际应用中，分布式数据库的主节点中的代理模块在确定与全局事务管理器建立通信连接的情况下，则将目标数据处理请求通过该通信连接转发至全局事务管理器

在确定目标数据处理请求的类型为分布式快照请求后，请求接收模块还可接收全局事务管理器返回的计算分布式快照请求的结果；具体的，所述将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，包括：

所述请求接收模块在确定所述目标数据处理请求为分布式快照请求的情况下，将所述分布式快照请求转发至所述全局事务管理器；

所述请求接收模块接收所述全局事务管理器计算所述每个分布式快照请求的结果。

实际应用中，在请求接收模块确定目标处理处理请求为分布式快照请求之后，将该分布式快照请求发送到GTM，而GTM通过计算分布式快照来处理请求，并使用包含分布式快照和组合请求中包含的槽索引列表的响应来回复代理模块，在收到响应后，代理模块将分布式快照的副本存储到响应中包含的每个通信槽的响应缓冲区中。

进一步，本实施例还支持利用混合通信模式将分布式快照请求转发至全局事务管理器，步骤1：给定一组在等待队列里的通信槽里的新请求，代理将检查它们，并找到所有为只读事务发起的获取分布式快照的请求，以及为任何一种事务发起的获取事务ID的请求。步骤2:如果当前处理的这组事务确实包含多个为只读事务发起的获取分布式快照的请求，代理将合并它们，并构造一个新的联合请求。它的类型仍旧为分布式快照请求，并包含了一个槽索引列表，指明每个原始请求的来源是哪个通信槽。代理将这个新的联合请求发送给GTM。GTM计算出分布式快照后，把它以及收到的槽索引列表一起作为响应返回给代理。在收到GTM的响应后，代理拷贝消息中的分布式快照到每一个槽索引指向的通信槽的结果数据缓冲区。步骤3:同样的，如果当前处理的这组事务确实包含了多个获取事务ID的请求，代理也将合并它们，并构造一个新的联合请求，其类型仍旧为全局事务ID请求，同时包含了一个槽索引列表表明它们都是来源于哪个通信槽。这个联合请求发给GTM后，GTM分配一组连续的事务ID，把这一段连续事务ID的范围信息以及槽索引列表返回给代理。收到响应后，代理把该范围内的每个事务ID逐个写入到槽索引列表指向的每个索引的数据缓冲区。

此外，分布式数据库中的主节点中还可配置多个代理模块；具体的，所述请求接收模块基于共享内存区域与所述代理模块建立通信连接，包括：

所述请求接收模块基于预设配置数量确定与所述预设配置数量相同的两个或两个以上的代理模块，并基于共享内存区域与所述两个或两个以上的代理模块建立通信连接。

实际应用中，主节点上的代理模块数量是可配置的，当有多个代理时，我们的方法以负载平衡的方式将用户会话分配给这些GTM代理。假设每个主服务器上有K个代理。每当用户数据库会话需要获取通信槽时，它从头开始扫描通信槽数组(即数组中的第一个槽位)以找到状态为空闲的时隙。然后它通过计算确定哪个代理服务这个插槽：proxy id＝slotindex modulo K(即代理数量)；换句话说，插槽以静态循环方式分配给代理。这种分配是简单的、确定性的，并且通常会导致将工作平均分配给代理。更复杂的替代分配策略是可能的。例如，会话可能会检查和比较代理的插槽索引数组的长度，并选择服务最少插槽数的那个。

进一步地，当有多个代理模块的时，本实施例提出一种负载均衡的方式将用户会话分配给多个代理模块；具体的，所述将所述目标数据处理请求转发至全局事务管理器，包括：

所述请求接收模块基于预设负载平衡机制将所述目标数据处理请求分配至所述两个或两个以上的代理模块，所述代理模块将所述目标数据处理请求转发至全局事务管理器。

实际应用中，在请求接收模块基于预设负载平衡机制将目标数据处理请求分配至两个或两个以上的代理模块后，代理模块会自动检测并消除并发事务对GTM的冗余请求，以减少到GTM的网络流量和GTM执行的工作量。代理检查两种类型的并发请求，它们可以一起提供服务，因此可以被视为冗余。第一种类型是来自并发只读事务的分布式快照请求。GTM可以计算单个分布式快照并将其作为对所有这些请求的响应返回。因此，代理首先将多个并发的分布式快照请求呈现为单个组合消息，发送到GTM，并在收到响应后，将响应的副本返回给每个请求事务。第二种类型是从并发事务请求全局事务ID。GTM可以返回一个连续范围的全局事务ID，而不是为每个事务分配单独的ID，并让代理为每个请求事务处理一个。

通过代理模块进行消息缩减和分组的过程如下：步骤1：给定一组在等待队列里的通信槽里的新请求，代理将检查它们，并找到所有为只读事务发起的获取分布式快照的请求，以及为任何一种事务发起的获取事务ID的请求。步骤2:如果当前处理的这组事务确实包含多个为只读事务发起的获取分布式快照的请求，代理将合并它们，并构造一个新的联合请求。它的类型仍旧为分布式快照请求，并包含了一个槽索引列表，指明每个原始请求的来源是哪个通信槽。代理将这个新的联合请求发送给GTM。GTM计算出分布式快照后，把它以及收到的槽索引列表一起作为响应返回给代理。在收到GTM的响应后，代理拷贝消息中的分布式快照到每一个槽索引指向的通信槽的结果数据缓冲区。步骤3:同样的，如果当前处理的这组事务确实包含了多个获取事务ID的请求，代理也将合并它们，并构造一个新的联合请求，其类型仍旧为全局事务ID请求，同时包含了一个槽索引列表表明它们都是来源于哪个通信槽。这个联合请求发给GTM后，GTM分配一组连续的事务ID，把这一段连续事务ID的范围信息以及槽索引列表返回给代理。收到响应后，代理把该范围内的每个事务ID逐个写入到槽索引列表指向的每个索引的数据缓冲区。

进一步地，本说明书实施例中每个代理模块通过他们的通信槽为一个或多个用户数据库会话提供服务，其中，代理模块的工作流程如下：

步骤1：等待代理簿记数据的信号量以获取来自用户数据库会话的通知。收到通知后，转到步骤2；步骤2：获取通信槽阵列上的共享锁；步骤3：扫描每个插槽，其索引记录在代理的插槽索引数组中。这些是为此代理提供服务的插槽。对于每个这样的插槽，检查其状态。如果状态为FREEING，则将该插槽添加到名为freeing_slots的列表中；如果状态为REQUEST_AVAIL，则将该槽添加到另一个名为pending_requests的列表中；步骤4：对于freeing_slots列表中的每个槽，通过将其状态更改为FREE来回收它，或者从代理的插槽索引数组中删除此插槽；步骤5：解除对通讯槽阵列的锁定；步骤6：从pending_requests列表中的插槽发送请求：步骤6.1：如果有多个待处理请求，将它们合并为一个或多个组合请求，并将组合消息发送给GTM。否则，将单个请求发送到GTM。构建组合请求的细节将在后面描述。发送请求后，将插槽状态更改为WAIT_RESPONSE。如果代理发送请求失败，则将相应槽的状态更改为ERROR，将这些槽从pending_requests列表中删除，重新建立与GTM的连接，然后转到步骤1。步骤6.2：接收来自GTM的响应。GTM可能会返回对应于多个请求的组合响应，或单个响应。对于组合响应，从中构建单个响应。对于每个响应，将其存储到相应通信槽的响应缓冲区中，并将槽状态更改为RESPONSE_AVAIL。如果代理没有收到GTM的响应(例如，由于网络断开或GTM故障)，将相应的插槽状态设置为ERROR。一旦插槽的状态更改为RESPONSE_AVAIL或ERROR，设置插槽的信号量以通知数据库会话，并从pending_requests列表中删除插槽。当pending_requests列表为空时，转到步骤1。

基于此，数据库会话和代理都通过原子指令(例如，比较和交换)修改插槽状态。需要注意的是，一个通信槽的回收分两步完成：会话将槽状态设置为FREEING，然后代理回收它并将其状态设置为FREE。这种安排减少了对通信槽阵列的并发访问的冲突，从而减少了锁定开销。

综上，本说明书实施例提供的数据处理方法，在采用集中式全局事务管理器的多主分布式数据库中，每个主节点可配置数量的代理模块，用于收集、组合和转发来自该用户会话的GTM请求，并将返回的响应路由回用户会话。代理模块和用户会话之间的通信是通过主服务器上的高效共享内存机制进行的；一个master上的代理模块数量是可配置的。当有多个代理模块时，我们的方法以负载平衡的方式将用户会话分配给这些代理模块；代理自动检测并消除并发事务对GTM的冗余请求，以减少到GTM的网络流量和GTM执行的工作量；数据库系统允许每个单独的用户会话动态指定是否使用代理或专用连接到GTM来执行会话中的事务。

与上述方法实施例相对应，本说明书还提供了数据处理装置实施例，图6示出了本说明书一个实施例提供的一种数据处理装置的结构示意图。如图6所示，该装置应用于分布式数据处理系统的数据处理节点，包括：

请求接收模块602，被配置为接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求；

代理模块604，被配置为将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

所述请求接收模块602，进一步被配置为基于所述共享内存区域与所述代理模块建立通信连接。

所述请求接收模块602，进一步被配置为基于所述多个数据处理请求的数量在所述共享内存区域中确定待分配处理插槽的数量，并将所述待分配处理插槽的数量作为目标处理数量。

所述请求接收模块602，进一步被配置为根据所述目标处理数量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中；

所述代理模块604，进一步被配置为从所述待分配处理插槽中获取与所述目标处理数量相同的数据处理请求，并将所述数据处理请求作为目标数据处理请求。

所述代理模块604，进一步被配置为在确定与所述全局事务管理器建立通信连接的情况下，基于所述通信连接将所述目标数据处理请求转发至所述全局事务管理器。

所述请求接收模块602，进一步被配置为基于所述目标处理数量确定所述共享内存区域的每个待分配处理插槽的信号量；

基于所述信号量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中，并修改所述待分配处理插槽中的通信状态。

所述请求接收模块602，进一步被配置为基于所述与目标处理数量相同的数据处理请求，在所述共享内存区域中的代理薄记中记录所述待分配处理插槽的状态，并记录与所述代理模块的连接状态。

所述请求接收模块602，进一步被配置为在确定所述目标数据处理请求为分布式快照请求的情况下，将所述分布式快照请求转发至所述全局事务管理器；

所述请求接收模块602，进一步被配置为接收所述全局事务管理器计算所述每个分布式快照请求的结果。

所述请求接收模块602，进一步被配置为基于预设配置数量确定与所述预设配置数量相同的两个或两个以上的代理模块，并基于共享内存区域与所述两个或两个以上的代理模块建立通信连接。

所述请求接收模块602，进一步被配置为基于预设负载平衡机制将所述目标数据处理请求分配至所述两个或两个以上的代理模块，所述代理模块将所述目标数据处理请求转发至全局事务管理器。

所述请求接收模块602，进一步被配置为基于预设项目需求判断是否启动所述数据处理节点中的代理模块，若是，则向客户端发送数据处理指令，其中，所述数据处理指令为将所述客户端发送的请求转发至代理模块处理的指令。

本说明书实施例提供的数据处理装置，通过在数据处理节点中对接收到的客户端发送的多个数据处理请求进行限流处理，按照一定数量的数据处理请求，分批次地处理由客户端发送的所有数据处理请求，能够减少数据处理节点的请求处理的压力，并且，后续将目标数据处理请求转发至全局事务管理器中也能提高全局事务管理器的处理效率，提升整个分布式数据处理系统的处理性能。

上述为本实施例的一种数据处理装置的示意性方案。需要说明的是，该数据处理装置的技术方案与上述的数据处理方法的技术方案属于同一构思，数据处理装置的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。

图7示出了根据本说明书一个实施例提供的一种计算设备700的结构框图。该计算设备700的部件包括但不限于存储器710和处理器720。处理器720与存储器710通过总线730相连接，数据库750用于保存数据。

计算设备700还包括接入设备740，接入设备740使得计算设备700能够经由一个或多个网络760通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备740可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本说明书的一个实施例中，计算设备700的上述部件以及图7中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图7所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备700可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备700还可以是移动式或静止式的服务器。

其中，处理器720用于执行如下计算机可执行指令，所述处理器用于执行所述计算机可执行指令，其中，所述处理器执行所述计算机可执行指令时实现所述数据处理方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的数据处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现所述数据处理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的数据处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书实施例并不受所描述的动作顺序的限制，因为依据本说明书实施例，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书实施例所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书实施例的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims (14)

1.一种数据处理方法，应用于分布式数据处理系统的数据处理节点，包括：

接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求；

将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

2.根据权利要求1所述的数据处理方法，所述数据处理节点包括请求接收模块、共享内存区域以及代理模块；

所述基于所述多个数据处理请求的数量确定目标处理数量之前，还包括：

所述请求接收模块基于所述共享内存区域与所述代理模块建立通信连接。

3.根据权利要求2所述的数据处理方法，所述基于所述多个数据处理请求的数量确定目标处理数量，包括：

所述请求接收模块基于所述多个数据处理请求的数量在所述共享内存区域中确定待分配处理插槽的数量，并将所述待分配处理插槽的数量作为目标处理数量。

4.根据权利要求3所述的数据处理方法，所述根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求，包括：

所述请求接收模块根据所述目标处理数量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中；

所述代理模块从所述待分配处理插槽中获取与所述目标处理数量相同的数据处理请求，并将所述数据处理请求作为目标数据处理请求。

5.根据权利要求2或4所述的数据处理方法，所述将所述目标数据处理请求转发至全局事务管理器，包括：

所述代理模块在确定与所述全局事务管理器建立通信连接的情况下，基于所述通信连接将所述目标数据处理请求转发至所述全局事务管理器。

6.根据权利要求4所述的数据处理方法，所述请求接收模块根据所述目标处理数量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中，包括：

所述请求接收模块基于所述目标处理数量确定所述共享内存区域的每个待分配处理插槽的信号量；

基于所述信号量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中，并修改所述待分配处理插槽中的通信状态。

7.根据权利要求6所述的数据处理方法，所述请求接收模块根据所述目标处理数量将与所述目标处理数量相同的数据处理请求放置于所述共享内存区域的待分配处理插槽中之后，还包括：

所述请求接收模块基于所述与目标处理数量相同的数据处理请求，在所述共享内存区域中的代理薄记中记录所述待分配处理插槽的状态，并记录与所述代理模块的连接状态。

8.根据权利要求7所述的数据处理方法，所述将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，包括：

所述请求接收模块在确定所述目标数据处理请求为分布式快照请求的情况下，将所述分布式快照请求转发至所述全局事务管理器；

所述请求接收模块接收所述全局事务管理器计算所述每个分布式快照请求的结果。

9.根据权利要求2所述的数据处理方法，所述请求接收模块基于共享内存区域与所述代理模块建立通信连接，包括：

所述请求接收模块基于预设配置数量确定与所述预设配置数量相同的两个或两个以上的代理模块，并基于共享内存区域与所述两个或两个以上的代理模块建立通信连接。

10.根据权利要求9所述的数据处理方法，所述将所述目标数据处理请求转发至全局事务管理器，包括：

所述请求接收模块基于预设负载平衡机制将所述目标数据处理请求分配至所述两个或两个以上的代理模块，所述代理模块将所述目标数据处理请求转发至全局事务管理器。

11.根据权利要求10所述的数据处理方法，所述接收客户端发送的多个数据处理请求之前，还包括：

所述请求接收模块基于预设项目需求判断是否启动所述数据处理节点中的代理模块，若是，则向客户端发送数据处理指令，其中，所述数据处理指令为将所述客户端发送的请求转发至代理模块处理的指令。

12.一种数据处理系统，所述数据处理系统包括数据处理节点，所述数据处理节点包括：

请求接收模块，被配置为接收客户端发送的多个数据处理请求，基于所述多个数据处理请求的数量确定目标处理数量，并根据所述目标处理数量对所述多个数据处理请求进行限流处理，获得目标数据处理请求；

代理模块，被配置为将所述目标数据处理请求转发至全局事务管理器，并接收所述全局事务管理器对所述目标数据处理请求进行处理的处理结果，且将所述处理结果返回至每个数据处理请求对应的客户端。

13.一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，其中，所述处理器执行所述计算机可执行指令时实现权利要求1-11任意一项所述数据处理方法的步骤。

14.一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1-11任意一项所述数据处理方法的步骤。

Images