用于事务处理的方法和装置与流程

本说明书的实施例涉及信息技术领域，具体地，涉及用于事务处理的方法、装置、计算设备和机器可读存储介质。

背景技术：

在计算机科学中，锁是一种同步机制，其通常用于在并发环境中保证被操作的共享数据的正确性和一致性。例如，在多个事务针对同一数据的情况下，在执行每个事务之前都需要对该数据加锁，而在执行完成之后释放锁。显然，这样的锁机制可能引起一定的处理延迟，影响处理吞吐量。

技术实现要素：

考虑到现有技术的上述问题，本说明书的实施例提供了用于分布式系统的事务处理的方法、装置、计算设备和机器可读存储介质。

一方面，本说明书的实施例提供了一种用于事务处理的方法，包括：接收要针对相同的目标数据来处理的多个事务；获取所述目标数据并存储在本地；按照所述多个事务的接收顺序，基于所述目标数据分别处理所述多个事务；在确定所述多个事务被成功执行的情况下，通知事务执行成功。

另一方面，本说明书的实施例提供了一种用于事务处理的装置，包括：接收单元，其接收要针对相同的目标数据来处理的多个事务；获取单元，其获取所述目标数据并存储在本地；执行单元，其按照所述多个事务的接收顺序，基于所述目标数据分别处理所述多个事务；通知单元，其在确定所述多个事务被成功执行的情况下，通知事务执行成功。

另一方面，本说明书的实施例提供了一种计算设备，包括：至少一个处理器；与所述至少一个处理器进行通信的存储器，其上存储有可执行代码，所述可执行代码在被所述至少一个处理器执行时使得所述至少一个处理器实现以上方法。

另一方面，本说明书的实施例提供了一种机器可读存储介质，其存储有可执行代码，所述可执行代码在被执行时使得机器执行以上方法。

附图说明

通过结合附图对本说明书的实施例的更详细的描述，本说明书的实施例的上述以及其它目的、特征和优势将变得更加明显，其中，在本说明书的实施例中，相同的附图标记通常代表相同的元素。

图1是根据一个实施例的用于事务处理的方法的示意性流程图。

图2示出了分布式系统的一个简单的示例性场景。

图3a是根据一个实施例的事务处理过程的示意性流程图。

图3b是在图2的示例场景下基于锁机制的事务处理过程的示意图。

图3c是在图2的示例场景下根据本文的实施例的事务处理过程的示意图。

图4是根据一个实施例的用于事务处理的装置的示意性框图。

图5是根据一个实施例的用于事务处理的计算设备的硬件结构图。

具体实施方式

现在将参考各实施例讨论本文描述的主题。应当理解的是，讨论这些实施例仅是为了使得本领域技术人员能够更好地理解并且实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者例子的限制。可以在不脱离权利要求书的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个实施例可以根据需要，省略、替换或者添加各种过程或组件。

如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其它实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其它的定义，无论是明确的还是隐含的，除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。

虽然目前锁机制已经广泛应用于各个业务领域的事务处理，但是锁机制的缺点也比较明显，比如带来一定的延迟，影响处理吞吐量等。

鉴于此，本文的实施例提供了一种用于事务处理的技术方案。下面结合具体实施例进行描述。

图1是根据一个实施例的用于事务处理的方法的示意性流程图。例如，图1的方法可以由服务器来执行。

如图1所示，在步骤102中，可以接收要针对相同的目标数据来处理的多个事务。

在本文中，事务可以具有本领域公知的含义。例如，事务可以是指作为一个整体的一系列操作，其要么都成功要么都失败。

在步骤104中，可以获取目标数据并且将其存储在本地。

在步骤106中，可以按照多个事务的接收顺序，基于目标数据来分别处理多个事务。

在步骤108中，可以在确定多个事务被成功执行的情况下，通知事务执行成功。

具体而言，在本文的实施例中，由于接收到的多个事务是针对同一目标数据，所以可以将目标数据存储在本地，然后按照多个事务的接收顺序，来分别针对目标数据处理多个事务。在这种情况下，将无需采用锁机制，从而能够避免由于锁机制引入的延迟，由此有效地提升处理吞吐量。实际上，这种方案也可以理解为采用单核cpu在本地串行化地处理针对同一目标数据的多个事务，因此无需使用锁机制来对目标数据进行加锁。

在一个实施例中，在步骤104中，可以从存储目标数据的共享存储位置读取目标数据，例如，可以通过有线或无线等方式从共享存储位置(比如，网络数据库或网络存储器等)读取目标数据。然后，可以将目标数据存储在本地。此时，并不对共享存储位置处的目标数据执行加锁处理。

可见，这种方式能够有效避免锁机制带来的延迟。

在一个实施例中，为了便于说明，将多个事务中的前后接收到的两个事务分别称为第一事务和第二事务。第二事务可以是紧接在第一事务之后接收到的。在处理第二事务时，第二事务所基于的数据是经过第一事务操作后的数据结果。

例如，假设顺序地接收到事务1至事务n(n可以为大于1的正整数)。那么，在步骤106中，可以基于目标数据处理事务1，得到处理后的数据结果1；然后，可以基于数据结果1来处理事务2，得到处理后的数据结果2；随后，可以基于数据结果2来处理事务3，得到处理后的数据结果3；以此类推，直到处理完成事务n。

这种方式不仅能够快速地完成事务1至事务n的处理，而且能够保证数据的正确性和一致性。

在一个实施例中，在步骤102中，可以从相同的客户端接收多个事务。也就是说，多个事务可以是来自同一客户端。那么，相应地，在步骤108中，可以向该客户端发送事务执行成功响应。

在另一实施例中，在步骤102中，可以从多个客户端接收多个事务中的相应事务。也就是说，多个事务可以是来自多个不同的客户端。在这种情况下，在步骤108中，可以向这些客户端分别发送事务执行成功响应。

在一个实施例中，图1的方法可以应用于分布式系统中。分布式系统一般可以包括多个独立的服务器，这些服务器可以作为整体对外提供服务。为了便于说明，图2示出了分布式系统的一个简单的示例性场景。在图2的示例中，分布式系统可以作为整体为客户端提供服务。此外，应当理解的是，为了简化描述，在图2中示出了3个服务器a、b和c；然而，在实践中，可以存在其它数量的服务器，本文对此不作限定。

在图2的示例中，服务器a、b、c可以形成分布式系统，并且可以彼此通过有线或无线等方式进行通信。

目前，在分布式系统里，通常使用两阶段提交算法，以确保所有服务器在进行事务提交时的正确性和一致性。在两阶段提交算法中，第一阶段可以包括对目标数据进行事务处理，第二阶段可以包括事务提交或回滚操作。

为了保证事务的原子性，在第一阶段中通常需要将目标数据进行加锁操作。例如，假设事务1至事务n均是针对相同的目标数据进行操作，因此，在事务1的第一阶段任务之前，需要针对事务1，使用锁机制获取数据的控制权，然后多个服务器a、b和c分别执行事务1的第一阶段任务。在事务1的第一阶段任务完成之后进行解锁，然后针对事务2对该数据进行加锁处理，使得多个服务器a、b和c针对该数据执行事务2的任务，以此类推，直到多个服务器a、b和c完成事务n的第一阶段任务为止。

在这个过程中，可能存在一定的网络延迟，这种延迟可能影响数据的更新速度，尤其是在各个服务器位于不同的数据中心甚至在不同的城市的情况下。

例如，在图2的示例中，假设由于锁机制，事务请求到达服务器a、b和c的总延时为1毫秒，每个服务器处理事务的时间为1微秒，这样，该系统的吞吐量可能最多为1000个事务/秒。

而本文的实施例可以有效地改善分布式系统的吞吐量。例如，在本文的一个实施例中，图1的方法可以由分布式系统的多个服务器中的主服务器来执行。

如目前所已知的，在分布式系统的多个服务器中，可以通过一定的选举机制定期、不定期地或者基于任何适当的触发事件来选举出主服务器(leader)，而其余服务器可以被称为从服务器(follower)。

主服务器可以对外与分布式系统的客户端进行通信(例如，通过有线或无线的方式)，并且可以通过与从服务器进行通信来进行协调管理。

在这种情况下，主服务器在接收到多个事务之后，可以向其余服务器分别转发多个事务，以使得其余服务器按照前述接收顺序来基于目标数据执行多个事务。

例如，主服务器可以以并行的方式向其余服务器转发多个事务。其余服务器接收到多个事务之后，可以按照步骤106中提到的接收顺序，来针对目标数据执行多个事务。

可以理解的是，各个服务器在执行多个事务时，同样可以将目标数据存储到本地，进而执行多个事务。

在这种情况下，关于步骤108中提到的确定多个事务被成功执行，可以将多个服务器考虑在内。例如，如果主服务器确定多个服务器中的超过预定数量的服务器成功执行多个事务，则确定多个事务被成功执行。

例如，从服务器在完成多个事务的执行之后，可以向主服务器发送成功响应消息，以指示多个事务执行成功。

主服务器可以收集各个从服务器的成功响应消息，由此可以确定包括主服务器本身在内有多少服务器成功执行了这些事务。如果成功执行多个事务的服务器数量超过预定数量，那么可以确定多个事务被成功执行。

可见，本文的实施例能够显著提升分布式系统的吞吐量。

例如，如前所假设的，如果每个服务器处理每个事务所花费的时间是1微秒，并且此时并不存在锁机制带来的延迟，因此从理论上而言，本文的实施例使得分布式系统的吞吐量能够达到1000,000个事务/秒。

在本文的实施例中，分布式系统可以采用各种适用的协议来运行，比如raft协议。raft协议是本领域技术人员所已知的，此处不再详细描述。

在采用raft协议的情况下，上述预定数量可以是分布式系统中的多个服务器的总数量的一半。例如，在图2的示例中，如果有2个或3个服务器成功执行多个事务，则主服务器可以向客户端发送事务成功响应。

为了便于理解，下文结合具体示例进一步描述上述技术方案。应当明白的是，以下示例仅是为了帮助本领域技术人员更好地理解本文的技术方案，而非限制其范围。

图3a是根据一个实施例的事务处理过程的示意性流程图。

为了便于说明，下面将结合图2的示例场景来描述图3a的过程。另外，在图3a中，假设存在两个客户端和两个事务。然而，应当理解的是，本文的实施例并不限于图3a中给出的具体数量。此外，假设服务器a当前为分布式系统的主服务器。

如图3a所示，在步骤302a和304a中，服务器a分别从客户端1和客户端2先后接收到事务1和事务2。具体地，此处假设服务器a先接收到事务1，然后接收到事务2。

在步骤306a和308a中，服务器a可以将事务1和事务2分别转发给服务器b和c。

在步骤310a、312a和314a中，服务器a、b和c可以分别从存储目标数据的共享存储位置读取目标数据并且将其存储在本地，而不对目标数据执行加锁处理。

在步骤316a、318a和320a中，服务器a、b和c可以按照事务1和2的接收顺序，基于目标数据来分别执行事务1和事务2。

在图3a的示例中，假设服务器b和服务器c均成功执行了事务1和2，那么在步骤322a和324a中，服务器b和c可以分别向服务器a发送成功响应消息。

另外，假设服务器a本身也成功执行了事务1和2，则其可以确定三个服务器都成功执行了事务1和2。

那么在步骤326a中，服务器a可以向客户端1发送事务成功响应；而在步骤328a中，服务器a可以向客户端2发送事务成功响应。

应当理解的是，以上各个步骤的执行次序仅是示例性的，在其它情况下，各个步骤的执行次序可以变化。

为了更加容易理解本文的实施例与现有的锁机制之间的区别，以下仍然以图2的示例场景为例进行说明。在图3b和3c中，假设待处理的事务包括事务1至n，其均是针对相同的目标数据的。

图3b是在图2的示例场景下基于锁机制的事务处理过程的示意图。

如图3b所示，如果采用前述两阶段提交算法，那么需要基于锁机制来处理事务1至事务n。具体而言，在事务1的第一阶段任务之前，事务1可以首先通过锁机制获取目标数据的控制权。然后，事务1的第一阶段任务可以到达服务器a、b和c，使得服务器a、b和c执行事务1的第一阶段任务。

在完成事务1的第一阶段任务之后，解锁对目标数据的控制权。然后，事务2对目标数据加锁，使得服务器a、b、c执行事务2的第一阶段任务。以此类推，直到这些服务器都完成事务n的第一阶段任务。

然后，服务器a、b和c可以进行两阶段提交算法的第二阶段处理。

可见，在图3b中，由于锁机制以及网络延迟，可能导致分布式系统的数据处理速度降低，从而影响吞吐量。

图3c是在图2的示例场景下根据本文的实施例的事务处理过程的示意图。

在图3c的示例中，假设服务器a为主服务器。服务器a、b和c可以各自获取目标数据，在本地对目标数据来串行化执行事务1至n。

可见，这种方式无需使用锁机制，从而能够减轻网络延迟，由此显著提升分布式系统的吞吐量。

另外，应当理解的是，为了便于说明，在图3c中，服务器a、b或c看起来是同步地处理事务1至n，但是在实践中，各个服务器的处理进度可能未必是同步的。

图4是根据一个实施例的用于事务处理的装置的示意性框图。

如图4所示，装置400可以包括接收单元402、获取单元404、执行单元406和通知单元408。

接收单元402接收要针对相同的目标数据来处理的多个事务。

获取单元404获取目标数据并存储在本地。

执行单元406按照多个事务的接收顺序，基于目标数据分别处理所述多个事务。

通知单元408在确定多个事务被成功执行的情况下，通知事务执行成功。

在一个实施例中，获取单元404可以从存储目标数据的共享存储位置读取目标数据，然后将目标数据存储在本地，而不对共享存储位置处的目标数据执行加锁处理。

在一个实施例中，上述多个事务至少可以包括第一事务和第二事务，第二事务是紧接在第一事务之后接收的，第二事务所基于的数据可以是经过第一事务操作后的数据结果。

在一个实施例中，装置400可以是分布式系统所包括的多个服务器中的主服务器。

装置400还可以包括转发单元410。转发单元410可以向多个服务器中的其余服务器分别转发多个事务，以使得其余服务器按照上述接收顺序来基于目标数据执行多个事务。

在一个实施例中，如果通知单元408确定多个服务器中的超过预定数量的服务器成功执行多个事务，则确定多个事务被成功执行。

在一个实施例中，分布式系统可以是基于raft协议来运行的，并且预定数量为多个服务器的总数量的一半。

在一个实施例中，接收单元402可以从相同的客户端接收多个事务。在这种情况下，通知单元408可以向该客户端发送事务执行成功响应。

在一个实施例中，接收单元402可以从多个客户端分别接收多个事务中的相应事务。在这种情况下，通知单元408可以向多个客户端分别发送事务执行成功响应。

装置400的各个单元可以分别执行图1、3a和3c的方法实施例中的相应步骤，因此，为了描述的简洁，装置400的各个单元的具体操作和功能此处不再赘述。

装置400可以采用硬件实现，也可以采用软件实现，或者可以通过软硬件的组合来实现。例如，装置400在采用软件实现时，其可以通过其所在设备的处理器将存储器(比如非易失性存储器)中对应的可执行代码读取到内存中运行来形成。

图5是根据一个实施例的用于事务处理的计算设备的硬件结构图。如图5所示，计算设备500可以包括至少一个处理器502、存储器504、内存506和通信接口508，并且至少一个处理器502、存储器504、内存506和通信接口508经由总线510连接在一起。至少一个处理器502执行在存储器504中存储或编码的至少一个可执行代码(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器504中存储的可执行代码在被至少一个处理器502执行时，可以使得计算设备实现以上结合图1、3a和3c描述的各种过程。

计算设备500可以采用本领域任何适用的形式来实现，例如，其包括但不限于台式计算机、膝上型计算机、智能电话、平板计算机、消费电子设备、可穿戴智能设备等等。

本说明书的实施例还提供了一种机器可读存储介质。该机器可读存储介质可以存储有可执行代码，可执行代码在被机器执行时使得机器实现上面参照图1、3a和3c描述的方法实施例的具体过程。

例如，上述任一机器可读存储介质可以包括但不限于随机存取存储器(randomaccessmemory，ram)、只读存储器(read-onlymemory，rom)、电可擦除可编程只读存储器(electrically-erasableprogrammableread-onlymemory，eeprom)、静态随机存取存储器(staticrandomaccessmemory，sram)、硬盘、闪存等等。

应当理解的是，本说明书中的各个实施例均采用递进的方式来描述，各个实施例之间相同或相似的部分相互参见即可，每个实施例重点说明的都是与其它实施例的不同之处。例如，对于上述关于装置的实施例、关于计算设备的实施例以及关于机器可读存储介质的实施例而言，由于它们基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分别由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

在整个本说明书中使用的术语“示例性”意味着“用作例子、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

以上结合附图详细描述了本公开内容的实施例的可选实施方式，但是，本公开内容的实施例并不限于上述实施方式中的具体细节，在本公开内容的实施例的技术构思范围内，可以对本公开内容的实施例的技术方案进行多种变型，这些变型均属于本公开内容的实施例的保护范围。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的例子和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。