CN112000444B - 数据库事务处理方法、装置、存储介质和电子设备 - Google Patents

Abstract

本申请实施例提供的数据库事务处理方法、装置、存储介质和电子设备，涉及通信技术领域，当获取到待处理的数据库事务时，从已注册的多个数据库实例中选择处理所述数据库事务的至少两个目标数据库实例；向每个目标数据库实例发送所述数据库事务，以使各个目标数据库实例启动对应的数据库操作分别处理所述数据库事务；若所述至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将所述相同处理结果确定为所述数据库事务的事务处理结果。由于多个数据库实例可以独立执行数据库事务，即使其中一个数据库实例发生故障，也不会造成业务系统的业务中断，可以保证业务系统无损地响应业务请求。

Description

数据库事务处理方法、装置、存储介质和电子设备

技术领域

本申请涉及通信技术领域，更具体地说，涉及一种数据库事务处理方法、装置、存储介质和电子设备。

背景技术

数据容灾，指建立一个异地的数据系统，该系统是本地关键应用数据的一个可用复制。在本地数据及整个应用系统出现灾难时，系统至少在异地保存有一份可用的关键业务的数据。

目前的数据容灾方案通常采用主备切换的方式，即部署一个主机和至少一个备机。主机为业务系统提供数据库服务，主机执行业务系统的业务后，将执行结果同步至备机。当主机发生故障时，通过将数据库服务的虚拟IP地址映射到备机，由备机对业务系统继续提供数据库服务。但是，这种数据容灾模式，仅能保证业务系统无需感知“主备切换”，但主备切换过程对业务系统的业务是有损的，比如，用户可以查询已有业务，但不能发起新业务。对于业务连续性要求较高的业务系统，不可控的短暂“业务中断”也有着较高的业务风险。

发明内容

为解决相关技术存在的技术问题，本申请实施例提供一种数据库事务处理方法、装置、存储介质和电子设备，可以实现数据库多活，无需主备切换，避免发生业务系统的业务中断，保证业务系统无损地响应业务请求。

为达到上述目的，本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种数据库事务处理方法，包括：

当获取到待处理的数据库事务时，从已注册的多个数据库实例中选择处理所述数据库事务的至少两个目标数据库实例；

向每个目标数据库实例发送所述数据库事务，以使各个目标数据库实例启动对应的数据库操作分别处理所述数据库事务；

若所述至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将所述相同处理结果确定为所述数据库事务的事务处理结果。

第二方面，本申请实施例提供一种数据库事务处理装置，包括：

选择单元，用于当获取到待处理的数据库事务时，从已注册的多个数据库实例中选择处理所述数据库事务的至少两个目标数据库实例；

事务发送单元，用于向每个目标数据库实例发送所述数据库事务，以使各个目标数据库实例启动对应的数据库操作分别处理所述数据库事务；

确定单元，用于若所述至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将所述相同处理结果确定为所述数据库事务的事务处理结果。

在一种可选的实施例中，所述选择单元还用于：

根据已注册的各个数据库实例所注册的数据库事务类型，确定注册所述数据库事务的目标数据库事务类型的候选数据库实例；

从所述候选数据库实例中选择至少两个目标数据库实例。

在一种可选的实施例中，所述装置还包括第一结果反馈单元，用于：

在向所述数据库事务对应的客户端反馈所述事务处理结果失败且接收到所述客户端发送的查询指令时，分别向每个目标数据库实例发送处理结果查询指令，以查询所述每个目标数据库实例的处理结果；

若所述至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将所述相同处理结果确定为所述数据库事务的事务处理结果；

向所述客户端发送所述数据库事务的事务处理结果。

在一种可选的实施例中，所述装置还包括设定条件确定单元，用于：

确定所述至少两个目标数据库实例的处理结果中具有相同处理结果的第一数据库实例的数量；

若所述第一数据库实例的数量与所述至少两个目标数据库实例的总数之比不小于设定比例阈值，或者所述第一数据库实例的数量达到设定数量阈值，则确定满足所述设定条件。

在一种可选的实施例中，所述装置还包括共识补偿单元，用于：

当所述至少两个目标数据库实例中，存在处理结果与所述相同处理结果不同的第二数据库实例时，对所述第二数据库实例进行注销并标记为不可用；

向所述第二数据库实例发送共识补偿指令，以使所述第二数据库实例根据所述共识补偿指令获取所述第一数据库实例中的任一个数据库实例的处理结果，以将所述待处理的数据库事务的处理结果更新为所述相同处理结果。

在一种可选的实施例中，所述装置还包括注册单元，用于：

接收所述第二数据库实例在将所述待处理的数据库事务的处理结果更新为所述相同处理结果后发送的注册信息，对所述第二数据库实例进行注册并标记为可用。

在一种可选的实施例中，所述装置还包括注销单元，用于：

若所述至少两个目标数据库实例的处理结果中相同处理结果的数量不满足设定条件时，将所述至少两个目标数据库实例进行注销并标记为不可用。

在一种可选的实施例中，所述装置还包括第二结果反馈单元，用于：

将所述数据库事务的事务处理结果进行存储；

在向所述数据库事务对应的客户端反馈事务处理结果失败且接收到所述客户端发送的查询指令时，向所述客户端发送存储的事务处理结果。

在一种可选的实施例中，所述装置还包括超时反馈单元，用于：

若在设定时间内未接收到所述至少两个目标数据库实例发送的处理结果，向所述数据库事务对应的客户端反馈处理超时信息。

第三方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时，实现第一方面的数据库事务处理方法。

第四方面，本申请实施例还提供一种电子设备，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器实现第一方面的数据库事务处理方法。

本申请实施例的数据库事务处理方法、装置、存储介质和电子设备，通过部署多个已注册的数据库实例，针对一个数据库事务，可以从已注册的多个数据库实例中选择能够处理该数据库事务的至少两个目标数据库实例，由至少两个目标数据库实例分别处理该数据库事务，如果各个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将该相同处理结果确定为数据库事务的事务处理结果。从而使一个数据库事务对应多个数据库实例，各个数据库实例之间无需配置数据复制关系，可以独立执行数据库事务，即使其中一个数据库实例发生故障，也不会造成业务系统的业务中断，保证业务系统无损地响应业务请求。

附图说明

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

图1为本申请实施例提供的一种数据库事务处理方法的软件框架的架构示意图；

图2为本申请实施例提供的另一种数据库事务处理方法的软件框架的架构示意图；

图3为本申请实施例提供的一种数据库事务处理方法的应用场景示意图；

图4为本申请实施例提供的一种数据库事务处理方法的信令交互图；

图5为本申请实施例提供的一种数据库事务处理方法的流程图；

图6为本申请实施例提供的另一种数据库事务处理方法的流程图；

图7为本申请实施例提供的一种数据库事务处理装置的结构示意图；

图8为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

下面对本申请实施例中涉及的部分概念进行介绍。

SOA（Service-Oriented Architecture ，面向服务架构），它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

微服务 (Microservices) ，是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic)的 API 集相互通信。

服务发现，可以通过服务名找到提供服务的实例地址和端口，主要用于解决如何获取服务实例地址问题。近年来随着容器技术的兴起，大量服务分散在系统各处，服务彼此之间调用都需要通过服务发现来实现。服务发现是分布式系统中不可或缺的关键组件，常用于构建服务发现解决方案的开源框架，如Zookeeper、 Etcd、Consul等。

共识算法，泛指在计算机科学领域解决协商一致问题的若干协议，该协议用于就分布式系统的当前状态下达成一致协议。共识算法主要用于实现一个涉及多个分布式节点的可靠性，这些节点包含相同的信息。本申请实施例中的多个数据库实例可以看作多个分布式节点，这些数据库实例包含相同的数据。

数据库实例，是一个逻辑意义上的概念，可用于存储数据、提供数据库事务服务等，硬件架构上通常包括有用于存储数据的物理介质、用于执行数据库事务服务逻辑的处理器等。

下文中所用的词语“示例性”的意思为“用作例子、实施例或说明性”。作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。

文中的术语“第一”、“第二”仅用于描述目的，而不能理解为明示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

本申请实施例涉及云技术和大数据处理。云技术（Cloud technology）是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，是基于云计算模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

在本申请实施例中，各个数据库实例的注册信息、数据库事务对应的操作数据和事务处理结果等需要后台的云服务器提供存储资源进行存储，确定数据库事务的事务处理结果等运算也可以通过云计算实现。

大数据（Big data）是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。随着云时代的来临，大数据也吸引了越来越多的关注，大数据需要特殊的技术，以有效地处理大量的较长时间段内的数据。本申请实施例中的各个数据库实例的注册信息、数据库事务对应的操作数据和事务处理结果等保存在数据库中。

数据库(Database)，简而言之可视为电子化的文件柜——存储电子文件或电子数据的处所，是以一定方式将数据储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。数据库管理系统（英语：Database Management System，简称DBMS）是为管理数据库而设计的软件系统，具有存储、截取、安全保障、备份等基础功能。

目前采用主备切换的数据容灾模式，仅能保证业务系统无需感知“主备切换”，但主备切换过程对业务系统的业务是有损的，比如，用户可以查询已有业务，但不能发起新业务。对于业务连续性要求较高的业务系统，不可控的短暂“业务中断”也有着较高的业务风险。

为了改善上述情况，本申请实施例提供一种数据库事务处理方法、装置、存储介质和电子设备，可以实现数据库多活，无需主备切换，避免发生业务系统的业务中断，保证业务系统无损地响应业务请求。

下面首先对实现本申请实施例的数据库事务处理方法的软件框架进行详细介绍。

本申请实施例提供的数据库事务处理方法，在软件框架层面，不需要依赖数据库提供的数据复制技术，而是采用SOA的服务分层、微服务架构的服务注册/发现和“共识算法”等技术，实现数据库的多活，即一个业务数据对象对应一组数据库实例，一组数据库实例可以作为一个数据库分组，数据库实例之间不用配置数据复制关系。下面以图1所示的一个由3个数据库实例构成的数据库分组为例，介绍一下软件框架的架构。

示例性地，如图1所示，构建独立的持久层，该持久层可以封装数据映射和数据库操作，对业务层提供事务性的服务，这是SOA的一种常见模式，在此基础之上，本申请实施例构建一个执行代理层，执行代理层包括多个执行代理，每个执行代理可以对持久层提供事务性的服务。具体地说，每个业务数据对象对应的服务可以由多个执行代理提供，每个执行代理操作该业务数据对象的一个数据库实例，即每个业务数据对象在系统中可以映射到多个数据库实例中，这些数据库实例保持数据一致。

例如，用户管理服务中的“用户登录”可以理解为一个独立的服务，持久层将服务请求“广播”到对应的多个执行代理上，每个执行代理可以通过数据库执行用户登录的服务，将用户登录的数据存储在对应的用户数据库，或者数据库中的用户分库中。从而实现对持久层提供用户登录的服务。

本申请实施例中，在持久层与执行代理层之间引入微服务架构的服务注册/发现能力，微服务架构包括服务注册中心，每个执行代理启动后，向服务注册中心发送注册信息进行注册，该注册信息可以包括该执行代理供服务的实例地址和端口、支持的服务等。持久层通过服务注册中心可以自动发现每个执行代理提供的服务，即通过服务发现可以获得数据库分组对应的多个目标执行代理，例如图1中的数据库分组对应三个目标执行代理，分别为执行代理EPx_1、执行代理EPx_2、执行代理EPx_3，每个目标执行代理可以操作对应的数据库，即EPx_1、EPx_2、EPx_3分别操作数据库DBx_1、数据库DBx_2、数据库DBx_3。

在一些实施例中，当持久层接收到业务层发送的某个业务数据对象时，需要操作该业务数据对象，即为该业务对象提供服务，此时，持久层可以并行（同时独立地）调用所有执行代理中注册了该服务的多个目标执行代理，例如图1中的三个执行代理EPx_1、EPx_2、EPx_3。所调用的每个目标执行代理执行操作该业务数据对象对应的代码，并操作对应的数据库，然后向持久层返回执行结果。

如果各个目标执行代理都可以正常操作业务数据对象，那么各个目标执行代理的执行结果应该是相同的，该相同的执行结果为正确的执行结果。但是如果某个目标执行代理在操作业务数据对象时出现异常，例如该目标执行代理发生故障或者操作错误，此时，该目标执行代理可能无法返回执行结果，或者返回的执行结果是错误的。因此，持久层在接收到各个目标执行代理返回的执行结果后，可以确定具有相同执行结果的目标执行代理的数量是否满足设定条件，如果满足，则可以将该相同执行结果作为最终的业务处理结果，将业务处理结果返回给业务层。

在一种可选的实施方式中，上述设定条件可以是：具有相同执行结果的目标执行代理的数量与目标执行代理的总数之比不小于设定比例阈值。该设定比例阈值可以根据需要进行设置，例如可以设置为1/2、3/5等，本实施例对此不作限定。

在另一种可选的实施方式中，上述设定条件可以是：具有相同执行结果的目标执行代理的数量不小于数量阈值，该数量阈值可以与目标执行代理的总数有关，例如设定一个共识阈值，数量阈值可以为该共识阈值与目标执行代理的总数的乘积。上述共识阈值可以与上述设定比例阈值相同，根据需要进行设置，例如可以设置为1/2、3/5等，本实施例对此不作限定。

当多个目标执行代理中，存在执行结果与上述相同执行结果不同的目标执行代理时，持久层可以调用该目标执行代理的补偿服务，通过补偿服务可以将该目标执行代理的执行结果更新为上述相同执行结果，以实现各个目标执行代理的执行结果的一致性。当该目标执行代理无法将执行结果更新为上述相同执行结果时，可以注销其执行业务数据对象的服务。

在上述实施例中，持久层并发调用多个目标执行代理直到实现各个目标执行代理的执行结果一致的过程，可以理解为数据库分组达成共识的过程，得到的业务处理结果可以理解为共识结果。

本实施例通过服务注册/发现的方式，可以进行执行代理的动态调整，由于针对一个业务数据对象，一个执行代理可以对应一个数据库，因此，执行代理的动态调整可以理解为数据库的动态调整。利用共识机制，实现各个数据库的数据的一致性，从而使得每个数据库都可以提供服务，包括数据操作和数据查询等，实现数据库的多活。并且，本实施例可以允许多个数据库中的一些数据库发生故障，实现数据库的容灾。因此，即使其中一个数据库发生故障，也不会造成业务系统的业务中断，保证业务系统无损地响应业务请求。

下面以三个目标执行代理组成的数据库分组为例，从上述软件框架层面，对数据库分组达成共识的过程进行详细说明，如图2所示的软件框架层面的数据库分组达成共识的架构示意图，该共识过程可以包括如下步骤：

1、持久层在接收到业务层发送的某个业务数据对象时，通过服务注册中心，获取注册了该业务数据对象对应的服务的三个目标执行代理；持久层可以利用线程并行发起同步阻塞调用，或者发起异步服务调用，即并发调用这三个目标执行代理。

2、三个目标执行代理收到持久层的服务调用后，开启数据库事务，然后执行上述业务数据对象对应的服务所对应的SQL（Structured Query Language，结构化查询语句）语句，操作对应的数据库，执行成功后，可以提交事务，向持久层返回执行结果。

数据库可以设置数据库表，简称FTX表，该数据库表可以用来存储当前执行的业务数据对象对应的服务名、业务ID、当前时间、SQL及参数、执行结果等数据，一个业务数据对象可以对应一条记录。

3、持久层接收到三个目标执行代理返回的执行结果后，实时检查这三个目标执行代理的执行结果是否满足上述实施例中的预设条件，例如共识阈值可以设置为1/2，或者设定比例阈值设置为1/2，需要满足以下设定条件：具有相同执行结果的目标执行代理的数量应该不小于3*1/2=3/2，由于3/2小于2，具有相同执行结果的目标执行代理的数量为两个即可以满足设定条件。因此，持久层在接收到两个相同执行结果后，可以将该相同执行结果作为上述业务数据对象的最终执行结果，即得到达成共识的业务处理结果。

例如，持久层接收到两个相同执行结果后，如果还未接收到第三个目标执行代理返回的执行结果，此时无需等待第三个目标执行代理返回的执行结果，即可以向业务层返回业务处理结果。因此，可以允许第三个目标执行代理的执行结果发生异常，即允许三个数据库实例中的一个数据库实例发生故障，但不影响业务处理结果。

4、持久层根据接收到的两个相同执行结果确定业务处理结果，并向业务层返回业务处理结果后，如果还未接收到第三个目标执行代理返回的执行结果，此时，持久层可以启动异步处理机制，继续等待第三个目标执行代理返回的执行结果，等待结果可能存在以下三种情况：

a、 第三个目标执行代理返回的执行结果与达成共识的业务处理结果一致，可以不对执行结果进行处理。

b、 第三个目标执行代理返回的执行结果与达成共识的业务处理结果不一致，此时可以启动第三个目标执行代理的共识补偿机制，下面对该共识补偿机制进行详细说明。

在一些实施例中，持久层启动第三个目标执行代理的共识补偿机制后，可以注销该目标执行代理已注册的业务数据对象的操作服务，并标记为不可用，此时可以认为该目标执行代理发生故障。第三个目标执行代理进行共识补偿的过程如下：

第三个目标执行代理（例如EPx_3）可以通过服务注册中心，获取到自身所属的数据库分组中的其他两个目标执行代理，例如EPx_1、 EPx_2，向EPx_1和 EPx_2发起并发查询，例如同时独立地向EPx_1和EPx_2发送查询报文，该查询报文中可以包括本地数据库的数据库表的最新记录，例如记录tx0，EPx_1和EPx_2分别向EPx_3返回各自的数据库表中比记录tx0更加新的记录（可以包含tx0）；从EPx_1和EPx_2中选择其中一个，例如选择记录最新（即记录的时间最新）的一个。以选择EPx_1为例，EPx_3按照EPx_1的数据库表，对记录tx0和比记录tx0更加新的记录逐个发起明细查询，并调用本地的业务数据对象的操作逻辑执行相应的操作。

在一些实施方式中，每个目标执行代理对应的数据库的数据库表中可以存储对应记录的Hash，例如按照时间顺序生成记录的Hash并存储。比如，持久层调用目标执行代理服务的超时时间设置为1分钟，则可以在00:05生成00:03:00到00:03:59这一分钟里发生的记录的Hash。考虑到业务数据对象的并发，上述EPx_3在向EPx_1和EPx_2发起并发查询时，查询报文中可以携带最新记录tx0按照时间顺序生成的Hash，EPx_1和EPx_2比对该Hash，如果Hash比对结果一致，则可以返回含该Hash对应的后面的记录，否则，可以返回空。如果收到的空响应的数量超过阈值，则说明该Hash对应的记录有不一致的数据，此时可以继续使用时间上更晚（比如00:04）的Hash去查询，以此类推。

另外，如果EPx_1和EPx_2返回的数据库表中未包含tx0，则说明EPx_3的数据库表中的tx0需要回滚（即程序或数据处理错误，将程序或数据恢复到上一次正确的记录），此时可以调用本地数据库事务的回滚操作逻辑，对tx0进行回滚。

当EPx_3的数据库表中的记录更新至EPx_1返回的数据库表中的最新记录时，EPx_3可以将其业务数据对象的操作服务注册到服务注册中心，由于在EPx_3注册过程中，EPx_1可能接收到新的服务调用，即执行新的业务数据对象，因此，EPx_3在注册的同时可以拷贝EPx_1的后台线程继续运行，当发现所查询的记录中的业务ID与自身的服务接口收到的业务ID相同时，可以停止拷贝EPx_1的后台线程。至此，EPx_3从故障中恢复，可以正常提供数据库服务。

c、在设定时间内未收到第三个目标执行代理返回的执行结果，即调用超时，此时可以调用该目标执行代理提供的查询服务，对其执行结果进行查询，如果查询到执行结果，可以根据步骤a）和步骤b）进行处理；如果没有查询到执行结果，则可以等待一个超时时间（设定时间）后再进行查询，具体可以根据需要设置查询次数。

例如，可以设置查询次数为3，当第3次调用该目标执行代理提供的查询服务后，仍没有查询到执行结果，持久层可以将该目标执行代理设置为不可用，不再向其发送新的业务数据对象，例如交易请求。

本申请实施例以三个目标执行代理组成的数据库分组为例，对其达成共识的过程进行上述说明。需要说明的是，数据库分组还可以包括更多的目标执行代理，本申请实施例对此不作限定。

由上述步骤可知，对于每个目标执行代理，其除了可以操作业务数据对象对应的服务之外，还应该提供该服务对应的共识补偿服务以及查询服务等。另外，如果该服务支持幂等性，即相同的业务请求，请求多次返回的执行结果一致；也可以不提供查询服务，直接再次调用业务数据对象的服务。

通过上述数据库分组达成共识的过程，可以在同组的数据库之间保持业务数据对象的执行结果的一致性，使得物理部署上没有关系的多个数据库，既实现了业务数据的同步复制，又实现了每个数据库独立提供完整的数据库服务，包括操作服务、查询服务等。比如，可以实现无延迟的查询服务，当持久层收到业务层的查询请求时，可以从最近一次操作业务数据对象时达成共识的目标执行代理中选择任意一个目标执行代理，发起查询服务。

本申请实施例通过数据库的冗余设置和上述共识阈值的设置，使得数据库系统可以抵御连续的多次数据库故障。下面以三个数据库实例组成的数据库分组，共识阈值为1/2的场景为例，对数据库系统抵御数据库故障的能力进行如下说明。

（1）三个数据库实例同时提供数据库服务时，可以允许第一次故障，即三个数据库实例中的一个数据库实例发生故障，可以将其对应的目标执行代理的服务进行注销，此时该数据库分组中的剩余两个数据库实例还可以正常提供数据库服务；

（2）剩余两个数据库实例同时提供数据库服务，此时可以允许第二次故障，即剩余两个数据库实例中的一个出现异常，例如可以是其对应的目标执行代理返回执行结果失败，也可以是返回执行结果超时，由于另外一个数据库实例对应的目标执行代理还可以成功返回执行结果，即相同执行结果的数量为1，仍可以满足预设条件，即具有相同执行结果的目标执行代理的数量1不小于共识阈值与目标执行代理总数的乘积2*1/2，所以也可以达成共识，即另外一个数据库实例还可以正常提供数据库服务。

上述三个数据库实例组成的数据库分组，共识阈值为1/2的场景只是示例性的。本申请实施例可以根据实际情况，设置数据库分组中数据库实例的数量以及对应的共识阈值，以满足不同的数据库容灾需求，在此不作限定。

在一些实施例中，为了避免由于网络连通性造成的数据库调用、服务调用的异常情况，或者由于网络传输抖动造成的数据库调用、服务调用超时等情况，可以将执行代理与其对应的数据库靠近部署，例如可以部署在同一个服务器中，尽量减少两者间网络质量的影响，另外，持久层在调用执行代理超时时，还可以启动超时查询机制，从而保证服务调用的执行。

在另一些实施例中，上述达成共识的数据库可以作为查询库，对外提供查询服务。下面针对由于异常状况造成的，无法通过达成共识的数据库对外提供查询服务的两种场景进行示例性说明。

在一种场景下，持久层的服务调用进程或者线程由于异常被终止，例如由于代码异常、内存溢出、主机故障等造成的异常，或者由于持久层与业务层存在网络问题，使得业务层未收到业务数据对象的业务处理结果；当业务层向持久层发起查询请求时，持久层已经没有服务调用的上下文，因此即使多个目标执行代理的执行结果已经达成共识，在持久层处理查询的进程或者线程中，也无法获取共识结果。

在一种可选的实施方式中，持久层可以并发调用多个目标执行代理的查询服务，多个目标执行代理各自读取对应数据库的数据库表中的该业务数据对象对应的执行结果，并向持久层返回各自的执行结果。此时，持久层可以执行与上述步骤1至步骤4达成共识的过程类似的过程，对查询返回的多个执行结果进行共识，并将共识结果返回给业务层。

具体地说，系统可以进一步优化，通过在持久层引入缓存服务，记录未达成共识的业务数据对象，当命中缓存时，则执行上述达成共识的过程，当达成共识后，可以删除该业务数据对象对应的缓存；否则，如果未达成共识，可以直接从当前任一可用的目标执行代理中查询到执行结果。

在另一种可选的实施方式中，在多个目标执行代理的执行结果已经达成共识的情况下，持久层可以将共识结果进行存储，可以将共识结果进行缓存，当接收到业务层发起的查询请求时，可以向业务层返回存储的共识结果。

另一个场景是，多个目标执行代理的执行结果无法达成共识，即不论是返回的正确执行结果的数量，还是返回的错误执行结果的数量都没有达到设定数量阈值，也就是在设定的共识时间窗口中，作为共识中的“关键少数”的一个或者多个目标执行代理一直超时，例如，对于三个目标执行代理的场景，如果持久层接收到两个不同的执行结果，那么第三个执行结果属于上述“关键少数”。此时，持久层可以返回超时信息给业务层，由业务层通过该业务数据对象的查询服务获取最终结果。

在一些实施例中，除了部署上述已注册的执行代理对应的数据库，来参与上述达成共识的过程之外，还可以根据数据异步复制的需求，部署并不注册业务数据对象对应的服务的执行代理，该执行代理不参与上述达成共识的过程，该执行代理可以拷贝达成共识的执行代理的执行结果，通过其对应的数据库来进行数据备份。该执行代理和其对应的数据库既可以作为在线数据库的冷备，防止数据丢失，又可以用于数据离线处理。另外，通过替换数据库操作引擎，还可以支持各种数据库类型，即异步复制的数据库可以不同于参与共识的数据库。

综上所述，本申请实施例通过软件框架层面的数据库多活和结果达成共识的过程，解除了相关技术中主数据库和备数据库之间的数据库部署、配置层面的耦合，实现了数据库操作的热插拔，即可以通过服务注册/发现的方式动态调整数据库的数量，从而支持数据库操作层面的多活容灾。

除此之外，本申请实施例还具有以下有益效果：

一、提升了数据库的输入输出IO能力；以Mysql数据库为例，因为不再依赖其全同步、半同步、异步复制等技术进行主数据库到备数据库的复制，所以可以不再生成和传输Binlog，Binlog为MySQL数据库的二进制日志，用于记录用户对数据库操作的SQL语句信息。

二、支持不同类型的数据库；虽然推荐参与共识的数据库使用相同类型，且配置基本相当，但并不限制使用多种类型的数据库。

三、增加了数据篡改的发现可能；例如，传统的防篡改一般是针对账户余额、交易金额等字段进行特殊处理，本申请实施例还可以在上述共识过程中发现更多的篡改，比如，篡改了数据关联关系，或者业务开关等；而对于相关技术中采用主数据库和备数据库进行数据容灾的方案，这种篡改如果发生在主数据库，篡改动作会被自动复制到备数据库，不容易发现数据篡改。

在上述软件框架的基础上，下面结合本申请实施例的应用场景进行说明，参见图3所示，该应用场景中包括终端设备300、应用服务器100和多个数据库服务器200，终端设备300可以理解为上述软件框架的业务层，应用服务器100可以理解为上述软件框架的持久层，数据库服务器200可以理解为上述软件框架中的执行代理，执行代理对应的数据库也可以部署在数据库服务器200中。终端设备300和应用服务器100之间可以通过通信网络进行通信，应用服务器100和多个数据库服务器200之间也可以通过通信网络进行通信。该通信网络可以是有线网络或无线网络，本申请对此不做限制。

其中，终端设备300可以是手机、台式电脑、平板电脑、各类可穿戴设备等具有通信功能的终端。终端设备300上可以安装用于实现各种业务的客户端，各种业务通常涉及数据库事务。终端设备300可以通过通信网络与应用服务器100连接，应用服务器100和数据库服务器200都可以是一台服务器或由若干台服务器组成的服务器集群或云计算中心，或者是一个虚拟化平台。多个数据库服务器200可以部署在不同的地点，每个数据库服务器200可以通过数据库实例提供对应的数据库服务，一个数据库实例可以提供一个数据库服务，每个数据库服务可以操作一个数据库事务，数据库服务器200可以向应用服务器100进行服务注册，可以选择多个数据库服务器200为终端设备300上的业务提供数据库服务。

用户可以通过终端设备向应用服务器发起业务请求，该业务请求具体可以涉及业务数据对象，该业务数据对象可以理解为数据库事务，应用服务器可以选择多个数据库服务器处理该数据库事务，具体可以参照图4所示的信令交互图进行数据库事务处理。其中，应用服务器可以是图3中所示的应用服务器100，终端设备可以是图3中所示的终端设备300，数据库服务器可以是图3中所示的数据库服务器200。数据库事务处理过程包括如下步骤：

步骤S401，终端设备向应用服务器发送待处理的数据库事务。

具体地说，终端设备上可以安装客户端，该客户端可以向应用服务器发送待处理的数据库事务，例如数据库事务可以是交易请求等，涉及数据库的数据操作。

步骤S402，应用服务器在获取到待处理的数据库事务时，从已注册的多个数据库服务器中选择处理数据库事务的至少两个目标数据库服务器。

在一些实施例中，多个数据库服务器可以分别预先向应用服务器发送注册信息，以在应用服务器上进行注册，该注册信息可以包括数据库服务器的地址和端口，支持的数据库事务类型等信息。具体可以参见上述实施例的软件框架中，执行代理启动后，向服务注册中心发送注册信息进行注册的过程。其中的服务注册中心可以部署在持久层所在的应用服务器中，也可以部署在另外的应用服务器中，本申请实施例对此不作限定。

步骤S403，应用服务器向每个目标数据库服务器发送数据库事务。

步骤S404，每个目标数据库服务器执行对应的数据库操作分别处理数据库事务。

上述软件框架中的执行代理和对应的数据库可以部署于数据库服务器中，因此，目标执行代理可以理解为目标数据库服务器，而目标数据库服务器可以通过操作数据库实例启动对应的数据库操作分别处理数据库事务。该数据库实例可用于存储数据、提供数据库事务服务等，硬件架构上通常包括有用于存储数据的物理介质、用于执行数据库事务服务逻辑的处理器等。

步骤S405，每个目标数据库服务器向应用服务器发送处理结果。

需要说明的是，每个目标数据库服务器在得到处理结果后可以主动向应用服务器发送处理结果，也可以在接收到应用服务器发送的查询指令后，向应用服务器发送处理结果，本申请实施例对此不作限定。

步骤S406，若至少两个目标数据库服务器的处理结果中相同处理结果的数量满足设定条件时，应用服务器将相同处理结果确定为数据库事务的事务处理结果。

具体地说，如果至少两个目标数据库服务器都可以正常处理数据库事务，那么各个目标数据库服务器的处理结果应该是相同的，将该相同的处理结果作为事务处理结果。但是如果某个目标数据库服务器在处理数据库事务时出现异常，例如该目标数据库服务器发生故障或者操作错误，此时，应用服务器可能无法接收到该目标数据库服务器发送的处理结果，或者接收到的该目标数据库服务器发送的处理结果是错误的。因此，应用服务器在接收到各个目标数据库服务器发送的处理结果后，可以确定具有相同处理结果的目标数据库服务器的数量是否满足设定条件，如果满足，则可以将该相同处理结果作为最终的事务处理结果，将事务处理结果返回给对应的客户端。

该步骤S406可以理解为应用服务器对至少两个目标数据库服务器的处理结果达成共识的过程，具体与上述软件框架中，持久层对多个目标执行代理的执行结果达成共识的过程类似。

在一种可选的实施例中，确定至少两个目标数据库服务器的处理结果中相同处理结果的数量满足设定条件，包括以下步骤：

A、确定至少两个目标数据库服务器的处理结果中具有相同处理结果的第一数据库服务器的数量。

B、若第一数据库服务器的数量与至少两个目标数据库服务器的总数之比不小于设定比例阈值，或者第一数据库服务器的数量达到设定数量阈值，则确定满足设定条件。

其中，设定数量阈值可以与至少两个目标数据库服务器的总数有关，例如设定一个共识阈值，设定数量阈值可以为该共识阈值与至少两个目标数据库服务器的总数的乘积。该共识阈值可以与上述设定比例阈值相同，具体可以根据需要进行设置，例如可以设置为1/2、3/5等，本实施例对此不作限定。

示例性地，至少两个目标数据库服务器以三个目标数据库服务器为例，例如设定比例阈值可以设置为1/2，此时，需要满足以下设定条件：具有相同处理结果的第一数据库服务器的数量应该不小于3*1/2=3/2，由于3/2小于2，第一数据库实例的数量为两个即可以满足设定条件。因此，应用服务器在接收到两个相同处理结果后，可以将该相同处理结果作为数据库事务的事务处理结果。

步骤S407，应用服务器向终端设备发送数据库事务的事务处理结果。

在一些实施例中，至少两个目标数据库服务器以三个目标数据库服务器为例，如果设定比例阈值设置为1/2，应用服务器在接收到两个相同处理结果后，已经可以确定数据库事务的事务处理结果，即该相同处理结果，如果还未接收到第三个目标数据库服务器返回的处理结果，此时可以不需要等待第三个目标数据库服务器返回的处理结果，即可以向客户端返回事务处理结果。因此，可以允许第三个目标数据库服务器的处理结果发生异常，即允许三个目标数据库服务器中的一个目标数据库服务器发生故障，但不影响业务处理结果，不会造成业务系统的业务中断，保证业务系统无损地响应业务请求。

图5示出了本申请实施例提供的一种数据库事务处理方法中，应用服务器侧的处理流程图，可以由图1中的应用服务器100执行。如图5所示，数据库事务处理方法包括以下步骤：

步骤S501，当获取到待处理的数据库事务时，从已注册的多个数据库实例中选择处理数据库事务的至少两个目标数据库实例。

其中，数据库实例具体可以部署在上述数据库服务器中。多个数据库实例可以分别预先向应用服务器发送注册信息，以在应用服务器上进行注册，该注册信息可以包括数据库实例的地址和端口，以及数据库实例支持的数据库事务类型等信息。

步骤S502，向每个目标数据库实例发送数据库事务，以使各个目标数据库实例启动对应的数据库操作分别处理数据库事务。

步骤S503，若至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将相同处理结果确定为数据库事务的事务处理结果。

该步骤S503具体可以参照上述步骤S406中，应用服务器对至少两个目标数据库服务器的处理结果达成共识的过程，其中，确定至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件，具体可以通过以下方式实现：

首先确定至少两个目标数据库实例的处理结果中具有相同处理结果的第一数据库实例的数量；若第一数据库实例的数量与至少两个目标数据库实例的总数之比不小于设定比例阈值，或者第一数据库实例的数量达到设定数量阈值，则可以确定满足上述设定条件。

本申请实施例的数据库事务处理方法，通过部署多个已注册的数据库实例，针对一个数据库事务，可以从已注册的多个数据库实例中选择能够处理该数据库事务的至少两个目标数据库实例，由至少两个目标数据库实例分别处理该数据库事务，如果各个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将该相同处理结果确定为数据库事务的事务处理结果。从而使一个数据库事务对应多个数据库实例，各个数据库实例之间无需配置数据复制关系，可以独立执行数据库事务，即使其中一个数据库实例发生故障，也不会造成业务系统的业务中断，保证业务系统无损地响应业务请求。

在一些实施例中，如图6所示，步骤S501具体可以通过以下步骤实现：

步骤S601，当获取到待处理的数据库事务时，根据已注册的各个数据库实例所注册的数据库事务类型，确定注册数据库事务的目标数据库事务类型的候选数据库实例。

该步骤S601具体可以对应于上述实施例的软件框架中的微服务注册/发现能力，数据库事务类型可以理解为服务类型。

具体地说，应用服务器可以获取已注册的各个数据库实例的注册信息，由上述可知，每个数据库实例的注册信息可以包括该数据库实例支持的数据库事务类型，即该数据库实例能够处理的数据库事务类型。在确定待处理的数据库事务的目标数据库事务类型后，根据已注册的各个数据库实例各自支持的数据库事务类型，从各个数据库实例中确定能够处理该目标数据库事务类型的候选数据库实例。

步骤S602，从所述候选数据库实例中选择至少两个目标数据库实例。

在一种可选的实施方式中，可以将所有的候选数据库实例作为目标数据库实例，也可以选择部分候选数据库实例（至少两个）作为目标数据库实例。

在一些实施例中，应用服务器还可以执行以下步骤：

1）在向数据库事务对应的客户端反馈事务处理结果失败且接收到客户端发送的查询指令时，分别向每个目标数据库实例发送处理结果查询指令，以查询每个目标数据库实例的处理结果。

应用服务器在通过上述步骤S503确定事务处理结果后，可以向数据库事务对应的客户端反馈该事务处理结果。在反馈过程中，可能由于网络连通性、网络传输抖动等网络质量问题或者其他异常状况造成反馈失败，此时，客户端无法接收到事务处理结果，但是可以向应用服务器发送查询指令进行查询。应用服务器在接收到该查询指令后，可以分别向每个目标数据库实例发送处理结果查询指令，以查询每个目标数据库实例的处理结果。

2）若至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将相同处理结果确定为数据库事务的事务处理结果。

该步骤与上述步骤S503相同，具体也可以参照上述步骤S406，在此不再赘述。

3）向客户端发送数据库事务的事务处理结果。

在另一些实施例中，应用服务器还可以执行以下步骤：

a）将数据库事务的事务处理结果进行存储；

b）在向数据库事务对应的客户端反馈事务处理结果失败且接收到客户端发送的查询指令时，向客户端发送存储的事务处理结果。

本实施例中，为了防止应用服务器向客户端反馈事务处理结果失败，例如上述由于网络质量问题或者其他异常状况造成的反馈失败，应用服务器在确定数据库事务的事务处理结果后，可以将事务处理结果进行存储，当接收到客户端发送的查询指令时，可以直接向客户端发送存储的事务处理结果，不需要重新向目标数据库实例发起查询，重新执行达成共识的过程。

在一种可选的实施例中，应用服务器还可以执行以下步骤：

（一）当至少两个目标数据库实例中，存在处理结果与相同处理结果不同的第二数据库实例时，对第二数据库实例进行注销并标记为不可用。

具体地说，应用服务器将至少两个目标数据库实例的处理结果达成共识后，即具有相同处理结果的第一数据库实例的数量满足设定条件，此时，如果存在处理结果与相同处理结果不同的第二数据库实例，即第二数据库实例未达成共识，可以认为第二数据库实例发生故障，将该第二数据库实例进行注销并标记为不可用后，第二数据库实例将不能再处理新的数据库事务。

（二）向第二数据库实例发送共识补偿指令，以使第二数据库实例根据共识补偿指令获取第一数据库实例中的任一个数据库实例的处理结果，以将待处理的数据库事务的处理结果更新为相同处理结果。

本申请实施例中，应用服务器可以对未达成共识的第二数据库实例进行共识补偿，具体可以启动第二数据库实例的共识补偿机制，该共识补偿机制具体可以参照上述实施例的软件框架中步骤b中的共识补偿机制，在此不再赘述。

在一种可选的实施例中，应用服务器还可以执行以下步骤：

接收第二数据库实例在将待处理的数据库事务的处理结果更新为相同处理结果后发送的注册信息，对第二数据库实例进行注册并标记为可用。

本申请实施例中，应用服务器可以将发生故障的第二数据库实例进行注销并标记为不可用，当第二数据库实例从故障中恢复后，第二数据库实例可以重新向应用服务器发送注册信息，由应用服务器对第二数据库实例进行注册并标记为可用，此时第二数据库实例可以重新处理新的数据库事务。因此，本申请实施例可以支持故障数据库实例的自动下线和上线。

在一种可选的实施例中，应用服务器还可以执行以下步骤：

若至少两个目标数据库实例的处理结果中相同处理结果的数量不满足设定条件时，将至少两个目标数据库实例进行注销并标记为不可用。

具体地说，若上述第一数据库实例的数量与至少两个目标数据库实例的总数之比小于设定比例阈值，或者第一数据库实例的数量小于设定数量阈值时，可以认为至少两个目标数据库实例的处理结果无法达成共识，可以将至少两个目标数据库实例进行注销并标记为不可用，此时需要对至少两个目标数据库实例进行查看和修复。

在一种可选的实施例中，应用服务器还可以执行以下步骤：

若在设定时间内未接收到至少两个目标数据库实例发送的处理结果，向数据库事务对应的客户端反馈处理超时信息。

当客户端接收到处理超时信息时，可以向应用服务器发起查询指令，由应用服务器向至少两个目标数据库实例发送处理结果查询指令。如果没有查询到处理结果，则可以等待一个超时时间（设定时间）后再进行查询，具体可以根据需要设置查询次数 。

例如，可以设置查询次数为3，当第3次调用至少两个目标数据库实例提供的查询服务后，仍没有查询到处理结果，应用服务器可以将至少两个目标数据库实例进行注销并设置为不可用，不再向其发送新的数据库事务。

在一些实施例中，本申请实施例除了部署上述已注册的数据库实例，来线上处理数据库事务（即参与上述达成共识的过程）之外，还可以根据数据异步复制的需求，部署不需要注册的数据库实例来进行数据冷备，未注册的数据库实例不需要线上处理数据库事务，即不参与上述达成共识的过程，而是通过拷贝达成共识的目标数据库实例的处理结果，既可以防止数据丢失，又可以用于数据离线处理。另外，通过替换数据库操作引擎，还可以支持各种数据库类型，即异步复制的数据库可以不同于参与共识的数据库实例对应的数据库。

与上述方法实施例基于同一发明构思，本申请实施例提供了一种数据库事务处理装置，可以部署在服务器中，如图7所示，该装置包括选择单元71、事务发送单元72和确定单元73；其中，

选择单元71，用于当获取到待处理的数据库事务时，从已注册的多个数据库实例中选择处理数据库事务的至少两个目标数据库实例；

事务发送单元72，用于向每个目标数据库实例发送数据库事务，以使各个目标数据库实例启动对应的数据库操作分别处理数据库事务；

确定单元73，用于若至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将相同处理结果确定为数据库事务的事务处理结果。

在一种可选的实施例中，选择单元71具体还可以用于：

获取已注册的各个数据库实例的注册信息，注册信息包括数据库实例支持的数据库事务类型；

根据待处理的数据库事务的目标数据库事务类型，在支持目标数据库事务类型的已注册数据库实例中选择至少两个目标数据库实例。

在一种可选的实施例中，装置还可以包括设定条件确定单元，用于：

在向数据库事务对应的客户端反馈事务处理结果失败且接收到客户端发送的查询指令时，分别向每个目标数据库实例发送处理结果查询指令；

若至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将相同处理结果确定为数据库事务的事务处理结果；

向客户端发送数据库事务的事务处理结果。

在一种可选的实施例中，装置还可以包括第一结果反馈单元，用于：

确定至少两个目标数据库实例的处理结果中具有相同处理结果的第一数据库实例的数量；

若第一数据库实例的数量与至少两个目标数据库实例的总数之比不小于设定比例阈值，或者第一数据库实例的数量达到设定数量阈值，则确定满足设定条件。

在一种可选的实施例中，装置还可以包括共识补偿单元，用于：

当至少两个目标数据库实例中，存在处理结果与相同处理结果不同的第二数据库实例时，对第二数据库实例进行注销并标记为不可用；

向第二数据库实例发送共识补偿指令，以使第二数据库实例根据共识补偿指令获取第一数据库实例中的任一个数据库实例的处理结果，以将待处理的数据库事务的处理结果更新为相同处理结果。

在一种可选的实施例中，装置还可以包括注册单元，用于：

接收第二数据库实例在将待处理的数据库事务的处理结果更新为相同处理结果后发送的注册信息，对第二数据库实例进行注册并标记为可用。

在一种可选的实施例中，装置还可以包括注销单元，用于：

若第一数据库实例的数量与多个数据库实例的总数之比小于设定比例阈值，或者第一数据库实例的数量小于设定数量阈值，将多个数据库实例进行注销并标记为不可用。

在一种可选的实施例中，装置还可以包括第二结果反馈单元，用于：

将数据库事务的事务处理结果进行存储；

在向数据库事务对应的客户端反馈事务处理结果失败且接收到客户端发送的查询指令时，向客户端发送存储的事务处理结果。

在一种可选的实施例中，装置还可以包括超时反馈单元，用于：

若在设定时间内未接收到多个数据库实例发送的处理结果，向数据库事务对应的客户端反馈处理超时信息。

与上述方法实施例和装置实施例基于同一发明构思，本申请实施例还提供了一种电子设备。该电子设备可以是应用服务器，如图1所示的应用服务器100。在该实施例中，电子设备的结构可以如图8所示，包括存储器101，通讯模块103以及一个或多个处理器102。

存储器101，用于存储处理器102执行的计算机程序。存储器101可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。

处理器102，可以包括一个或多个中央处理单元（central processing unit，CPU）或者为数字处理单元等等。处理器102，用于调用存储器101中存储的计算机程序时实现上述数据库事务处理方法。

通讯模块103用于与终端设备进行通信，获取语音数据。

本申请实施例中不限定上述存储器101、通讯模块103和处理器102之间的具体连接介质。本申请实施例在图8中以存储器101和处理器102之间通过总线104连接，总线104在图8中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线104可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例中的数据库事务处理方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (9)

1.一种数据库事务处理方法，其特征在于，应用于应用服务器，包括：

当获取到待处理的数据库事务时，从已注册的多个数据库实例中选择处理所述数据库事务的至少两个目标数据库实例；其中，所述已注册的多个数据库实例分别通过向所述应用服务器发送注册信息，以在所述应用服务器上进行注册，所述注册信息至少包括数据库事务类型；

向每个目标数据库实例发送所述数据库事务，以使各个目标数据库实例启动对应的数据库操作分别处理所述数据库事务；

若所述至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将所述相同处理结果确定为所述数据库事务的事务处理结果；

所述从已注册的多个数据库实例中选择处理所述数据库事务的至少两个目标数据库实例，包括：

根据已注册的各个数据库实例所注册的数据库事务类型，确定注册所述数据库事务的目标数据库事务类型的候选数据库实例；

从所述候选数据库实例中选择至少两个目标数据库实例。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在向所述数据库事务对应的客户端反馈所述事务处理结果失败且接收到所述客户端发送的查询指令时，分别向每个目标数据库实例发送处理结果查询指令，以查询所述每个目标数据库实例的处理结果；

若所述至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将所述相同处理结果确定为所述数据库事务的事务处理结果；

向所述客户端发送所述数据库事务的事务处理结果。

3.根据权利要求1或2所述的方法，其特征在于，所述至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件，包括：

确定所述至少两个目标数据库实例的处理结果中具有相同处理结果的第一数据库实例的数量；

若所述第一数据库实例的数量与所述至少两个目标数据库实例的总数之比不小于设定比例阈值，或者所述第一数据库实例的数量达到设定数量阈值，则确定满足所述设定条件。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

当所述至少两个目标数据库实例中，存在处理结果与所述相同处理结果不同的第二数据库实例时，对所述第二数据库实例进行注销并标记为不可用；

向所述第二数据库实例发送共识补偿指令，以使所述第二数据库实例根据所述共识补偿指令获取所述第一数据库实例中的任一个数据库实例的处理结果，以将所述待处理的数据库事务的处理结果更新为所述相同处理结果。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

接收所述第二数据库实例在将所述待处理的数据库事务的处理结果更新为所述相同处理结果后发送的注册信息，对所述第二数据库实例进行注册并标记为可用。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

将所述数据库事务的事务处理结果进行存储；

在向所述数据库事务对应的客户端反馈事务处理结果失败且接收到所述客户端发送的查询指令时，向所述客户端发送存储的事务处理结果。

7.一种数据库事务处理装置，其特征在于，应用于应用服务器，包括：

选择单元，用于当获取到待处理的数据库事务时，从已注册的多个数据库实例中选择处理所述数据库事务的至少两个目标数据库实例；其中，所述已注册的多个数据库实例分别通过向所述应用服务器发送注册信息，以在所述应用服务器上进行注册，所述注册信息至少包括数据库事务类型；

事务发送单元，用于向每个目标数据库实例发送所述数据库事务，以使各个目标数据库实例启动对应的数据库操作分别处理所述数据库事务；

确定单元，用于若所述至少两个目标数据库实例的处理结果中相同处理结果的数量满足设定条件时，将所述相同处理结果确定为所述数据库事务的事务处理结果；

所述选择单元，还用于：

根据已注册的各个数据库实例所注册的数据库事务类型，确定注册所述数据库事务的目标数据库事务类型的候选数据库实例；

从所述候选数据库实例中选择至少两个目标数据库实例。

8.一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，其特征在于：所述计算机程序被处理器执行时，实现权利要求1～6任一项所述的方法。

9.一种电子设备，其特征在于，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器实现权利要求1～6任一项所述的方法。

Images