CN105446993A - 跨库事务处理方法及装置 - Google Patents

Abstract

本发明提供一种跨库事务处理方法及装置。该方法包括：接收业务请求，业务请求包括业务交易涉及的交易信息；根据交易信息，分别记录业务交易涉及的多个数据库参与业务交易的行为信息，并将业务交易的处理状态标记为待提交状态，待提交状态是指所有数据库均满足参与业务交易的条件后可以对每个数据库进行操作的业务处理状态；在待提交状态下，根据每个数据库参与业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与业务交易的行为达到一致为止。本发明技术方案可以实现对跨库事务的处理。

Description

跨库事务处理方法及装置

【技术领域】

本发明涉及数据库技术领域，尤其涉及一种跨库事务处理方法及装置。

【背景技术】

数据库拆分是一种提升***容量的有效方式，主要是把在一个数据库中处理的数据按照某种规则分拆到多个数据库中，降低单个数据库的压力。目前数据库拆分包括垂直拆分和水平拆分。其中，垂直拆分是按照功能划分，把不同功能的数据分别放到不同的数据库中；水平拆分是将一张表的数据拆分到多张同样的表中，一般采用哈希(hash)散列等方式保证拆分结果的均匀性。

在上述分库的应用场景中，有可能涉及到跨库事务，即需要在不同数据库之间进行操作的事务。跨库事务要求满足一致性，即对不同数据库的操作结果要么都成功要么都失败，否则就会出现错误。由于在现有垂直拆分或水平拆分方式下很少出现跨库事务，所以现有技术中尚不存在处理跨库事务的成熟方案。

【发明内容】

本发明的多个方面提供一种跨库事务处理方法及装置，用以实现跨库事务的处理。

本发明的一方面，提供一种跨库事务处理方法，包括：

接收业务请求，所述业务请求包括业务交易涉及的交易信息；

根据所述交易信息，分别记录所述业务交易涉及的多个数据库参与所述业务交易的行为信息，并将所述业务交易的处理状态标记为待提交状态，所述待提交状态是指所有数据库均满足参与所述业务交易的条件后可以对每个数据库进行操作的业务处理状态；

在所述待提交状态下，根据每个数据库参与所述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与所述业务交易的行为结果达到一致为止。

本发明的另一方面，提供一种跨库事务处理装置，包括：

接收模块，用于接收业务请求，所述业务请求包括业务交易涉及的交易信息；

第一处理模块，用于根据所述交易信息，分别记录所述业务交易涉及的多个数据库参与所述业务交易的行为信息，并将所述业务交易的处理状态标记为待提交状态，所述待提交状态是指所有数据库均满足参与所述业务交易的条件后可以对每个数据库进行操作的业务处理状态；

第二处理模块，用于在所述待提交状态下，根据每个数据库参与所述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与所述业务交易的行为结果达到一致为止。

在本发明技术方案中，接收业务请求后，根据业务请求包括的交易信息，分别记录业务交易涉及的多个数据库参与该业务交易的行为信息，并将该业务交易的处理状态标记为待提交状态，在待提交状态下，根据上述记录的行为信息分别对每个数据库进行至少一次操作，直到所有数据库参与业务交易的行为结果达到一致。通过记录每个数据库参与业务交易的行为信息，并对业务交易的处理状态进行标记，可以保证多次执行每个数据库参与业务交易的行为直到所有数据库参与业务交易的行为结果达到一致，因此，不会出现某些数据库的提交结果成功某些数据库的提交结果不成功的情况，保证了事务提交结果的一致性。

【附图说明】

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

图1为本发明一实施例提供的跨库事务处理方法的流程示意图；

图2为本发明另一实施例提供的跨库事务处理方法的流程示意图；

图3为本发明又一实施例提供的跨库事务处理方法的流程示意图；

图4为本发明又一实施例提供的跨库事务处理方法的流程示意图；

图5为本发明一实施例提供的跨库事务处理装置的结构示意图；

图6为本发明另一实施例提供的跨库事务处理装置的结构示意图。

【具体实施方式】

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

在单数据库的应用场景中，当数据库的容量达到瓶颈后，通常是将数据库中的数据拆分到多个数据库中，以应对更高容量的服务需求。拆分方法包括垂直拆分和水平拆分。对于账务业务来说，由于业务模型非常简单，主要提供做账服务及账务信息查询服务。其中做账服务包括存入(如银行的现金存入，或其他银行向本行的跨行打款)、提现(如银行的现金提款，或向他行汇款)以及转账(如银行内部客户间的资金划拨)。因此，对于账务业务来说无法做到业务的垂直剥离，所以不适合采用垂直拆分的方式。为达到将账务服务的事务热点及存储热点均匀分散到各分库上，对于账务数据可以采用水平拆分的方式。本实施例针对账务数据提供了一种新的水平拆分方法，即按照账号编号做拆分。

假设账号编号的生成规则为：6位业务前缀+10位递增编号，则账号编号生成范例如下表1示：

表1

后10位递增编号的生成方式为每产生一个新的账号编号，在上一个账号编号的基础上加1递增。

基于上述，若期望将数据库由1个拆成100个，则用账号编号按100取模，得到的结果作为数据库水平拆分的依据，通过这种方式就可以将根据账号编号将账务数据平均拆分到100个数据库中。若容量要求进一步提升，亦可考虑进一步对账号编号按1000取模，这样就可以按照账号编号将账务数据由1个数据库拆分到1000个数据库中。值的说明的是，具体按多大数值对账号编号取模，可根据实际业务规模对容量的要求评估决定。

举例说明，假设活期账号对应的账务数据需要由原来的1个库拆分到100个库中。对账号编号M：1000010009988012，账号编号N：1000010239168099分别进行100取模，则账号编号M的取模运算结果为：1000010009988012％100＝12；账号编号N的取模运算结果为：1000010239168099％100＝99。则根据运算结果，我们需要将账号编号M的账务数据置入编号为12的数据库，库名可设为ACCOUNT_12；账号编号N的账务数据置入编号为99的数据库，库名可设为ACCOUNT_99。

无论是对上述账务业务进行分库后，还是对现有技术中的分库场景，都会出现跨库事务，对于账务业务分库后出现跨库事务的场景更多。例如，对于两个客户的账户资金划拨来说，账号编号M转账100元给账号编号N，账号编号M和账号编号N的账务数据在不同的数据库中，于是出现了跨库事务。

对于账号编号M和账号编号N发生的一笔转账，必须做出如下保证：

账号编号M扣款成功，账号编号N加款成功，对外返回转账成功结果；

账号编号M扣款失败，账号编号N未加款，对外返回转账失败结果；

而如下情况则禁止出现：

账号编号M扣款成功，账号编号N未加款；

账号编号M未扣款，账号编号N加款成功；

也就是说，转账过程中账号编号M扣款及账号编号N加款这件事必须满足一致性，要么同时成功，要么同时失败，否则会出现资金处理出错。由于现有技术不存在解决上述问题的技术方案，本发明实施例提供一种跨库事务处理方法。

图1为本发明一实施例提供的跨库事务处理方法的流程示意图。如图1所示，该方法包括：

101、接收业务请求，该业务请求包括业务交易涉及的交易信息。

102、根据上述交易信息，分别记录上述业务交易涉及的多个数据库参与业务交易的行为信息，并将上述业务交易的处理状态标记为待提交(C)状态，该C状态是指所有数据库均满足参与上述业务交易的条件后可以对每个数据库进行操作的业务处理状态。

103、在上述C状态下，根据每个数据库参与上述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与上述业务交易的行为结果达到一致为止。

本实施例的执行主体可以是跨库事务处理装置，例如可以是各种需要处理跨库事务的服务器或客户端等。

例如，跨库事务处理装置可以接收业务交易***发送的业务请求，但并不限于业务交易***一种。业务请求包括业务交易涉及的交易信息。举例说明，对于转账业务，交易信息包括但不限于流入账户、流出账户和交易金额等信息。

跨库事务处理装置接收到业务请求后，可以对该业务请求进行解析，从中获取交易信息。然后，跨库事务处理装置根据该交易信息，分别记录该业务交易涉及的多个数据库参与该业务交易的行为信息。由于是跨库事务，因此该业务交易至少涉及两个数据库，也就是说所述多个数据库是指两个或两个以上的数据库。通过记录每个数据库参与该业务交易的行为信息，并对业务处理状态进行标记，这样可以在特定业务处理状态(例如C状态)下，在某个或某些数据库参与该业务交易的行为结果与其他数据库参与上述业务交易的行为结果不一致，例如该数据库参与业务交易的行为结果为失败，但其他数据库参与业务交易的行为结果为成功时，通过提取记录的该数据库参与业务交易的行为信息重新对该数据库进行操作，直到该数据库参与该业务交易的行为结果与其他数据库参与上述业务交易的行为结果一致为止。

值得说明的是，所有数据库参与上述业务交易的行为结果达到一致可以是所有数据库参与上述业务交易的行为结果均成功，或者可以是所有数据库参与上述业务交易的行为结果均失败。

跨库事务处理装置除了记录上述多个数据库参与该业务交易的行为信息之外，还会对业务交易的处理状态进行标记。例如在刚开始处理时，可以将该业务交易的处理状态标记为开始(P)状态；又例如，在做好准备工作，即记录到每个数据库参与该业务交易的行为信息后，可以将该业务交易的处理状态标记为C状态，意味着所有数据库均满足参与上述业务交易的条件，可以对每个数据库进行操作，也就是即将进入事务提交阶段。通过对业务交易的处理状态进行标记，只有前一处理状态完成后才能进入下一处理状态，防止处理过程发生错误。

进一步，在一可选实施方式中，如果所有数据库参与上述业务交易的行为结果达到一致是指所有数据库参与上述业务交易的行为结果均成功，则跨库事务处理装置还可以在所有数据库中部分数据库参与上述业务交易的行为结果成功时，删除该部分数据库参与业务交易的行为信息。这样做的好处是：当存在其他数据库参与业务交易的行为结果失败时，跨库事务处理装置重新从记录的信息中只能获取上述行为结果失败的数据库参与业务交易的行为信息，并且也只会对参与行为结果失败的数据库进行操作，有利于减轻跨库事务处理装置的处理负担，并且有利于提高处理效率。

进一步，跨库事务处理装置还可以在上述所有数据库参与上述业务交易的行为结果均成功，即上述业务交易完成后，将业务交易的处理状态标记为完成(S)状态。这样，在S状态下，跨库事务处理装置就会知道该业务交易已经成功，不再执行任何操作。

由此可见，本实施例提供的方法，通过记录每个数据库参与业务交易的行为信息，并对业务交易的处理状态进行标记，可以在所有数据库均满足参与业务交易的条件后可以对每个数据库执行操作的业务处理状态下，保证多次执行每个数据库参与业务交易的行为直到所有数据库参与业务交易的行为结果达到一致为止，因此，不会出现某些数据库的提交结果成功某些数据库的提交结果不成功的情况，保证了事务提交结果的一致性。

可选的，上述步骤103的一种实施方式包括：跨库事务处理装置可以在将上述业务交易的处理状态标记为待提交状态之后，按照预设的时间长度进行等待；当预设的时间长度结束后，执行上述步骤103所述的操作，即在预设的时间长度结束后，在待提交状态下，根据每个数据库参与上述业务交易的行为信息对每个数据库再执行至少一次操作，直到所有数据库参与上述业务交易的行为结果达到一致性为止的操作。在本实施方式中，通过设置等待的时间长度，业务交易的提交阶段可以缓做或临时被暂停，这样可以将业务交易的提交阶段放到事务较少的时间段来执行，有利于均衡跨库事务处理装置的处理负担，尤其是在事务高峰期可以极大的缓解跨库事务处理装置的压力。

对于跨库事务来说，更多涉及的是两个数据库之间的交互，即使跨库事务涉及到两个以上数据库，但是在某一时刻一般还是两个数据库之间的交互，基于此，本发明以下实施例以跨库事务涉及两个数据库为例进行说明。为便于描述，将这两个数据库分别记为第一数据库和第二数据库。

图2为本发明另一实施例提供的跨库事务处理方法的流程示意图。如图2所示，该方法包括：

201、接收业务请求，该业务请求包括业务交易涉及的交易信息。

202、标记业务交易的处理状态为P状态。

203、根据上述交易信息，判断上述业务交易涉及的第一数据库是否满足参与上述业务交易的条件，如果是，即第一数据库满足参与上述业务交易的条件，则执行步骤204；如果否，即第一数据库不满足参与上述业务交易的条件，则执行步骤208。

204、记录第一数据库参与上述业务交易的行为信息，并继续执行步骤205。

205、根据上述交易信息，判断上述业务交易涉及的第二数据库是否满足参与上述业务交易的条件；如果是，即第二数据库满足参与上述业务交易的条件，则执行步骤206，如果否，即第二数据库不满足参与上述业务交易的条件，则执行步骤208。

206、记录第二数据库参与上述业务交易的行为信息，并将上述业务处理的处理状态标记为C状态，并执行步骤207。

该C状态意味着所有数据库均满足参与上述业务交易的条件，可以对每个数据库进行操作。

207、在上述C状态下，根据第一数据库参与上述业务交易的行为信息对第一数据库进行至少一次操作，并根据第二数据库参与上述业务交易的行为信息对二数据库进行至少一次操作，直到第一数据库和第二数据库参与上述业务交易的行为结果达到一致为止。

可选的，跨库事务处理装置可以设置定时机制，即定时按照每个数据库参与业务交易的行为信息对每个据库进行操作，直到所有数据库参与上述业务交易的行为结果达到一致为止。

208、将上述业务交易的处理状态标记为回滚(R)状态，并对之前的操作进行回滚处理。

在此说明，当由步骤203转到步骤208时，这里的回滚操作主要是指对步骤203及之前的操作进行回滚。当由步骤205转到步骤208时，这里的回滚操作主要是指对步骤205及之前的操作进行回滚。

本实施例提供的方法，通过记录每个数据库参与业务交易的行为信息，并对业务交易的处理状态进行标记，可以在所有数据库均满足参与业务交易的条件后可以对每个数据库执行操作的业务处理状态下，保证多次执行每个数据库参与业务交易的行为直到所有数据库参与业务交易的行为结果达到一致为止，因此，不会出现某些数据库的提交结果成功某些数据库的提交结果不成功的情况，保证了事务提交结果的一致性。

图3为本发明又一实施例提供的跨库事务处理方法的流程示意图。如图3所示，该方法包括：

301、接收业务请求，该业务请求包括业务交易涉及的交易信息。

302、分配可唯一标识上述业务交易的业务请求号，对应存储该业务请求号和上述业务交易涉及的第一数据库的标识，并标记上述业务交易的处理状态为P状态。

在本实施例中，为业务交易分配业务请求号，用于唯一标识一个业务交易过程。通过对应存储业务请求号和第一数据库的标识，用以记录该业务交易的参与者。

303、根据上述交易信息，判断上述业务交易涉及的第一数据库是否满足参与上述业务交易的条件，如果是，即第一数据库满足参与上述业务交易的条件，则执行步骤304；如果否，即第一数据库不满足参与上述业务交易的条件，则执行步骤310。

304、记录第一数据库参与上述业务交易的行为信息，并继续执行步骤305。

在本实施例中，可以将第一数据库参与上述业务交易的行为信息与上述业务交易的业务请求号对应存储，以便于区分不同业务交易对应的行为信息。

305、对应存储上述业务请求号和上述业务交易涉及的第二数据库的标识，并继续执行步骤306。

同理，这里将上述业务交易涉及的第二数据库的标识与业务请求号对应存储，用以记录该业务交易的参与者。

306、根据上述交易信息，判断上述业务交易涉及的第二数据库是否满足参与上述业务交易的条件；如果是，即第二数据库满足参与上述业务交易的条件，则执行步骤307，如果否，即第二数据库不满足参与上述业务交易的条件，则执行步骤310。

307、记录第二数据库参与上述业务交易的行为信息，并将上述业务处理的处理状态更新为C状态，并继续执行步骤308。

C状态是指所有数据库均满足参与上述业务交易的条件后可以对每个数据库进行操作的业务处理状态。

在本实施例中，可以将第二数据库参与上述业务交易的行为信息与上述业务交易的业务请求号对应存储，以便于区分不同业务交易对应的行为信息。

308、在上述C状态下，根据第一数据库参与上述业务交易的行为信息对第一数据库进行至少一次操作，并根据第二数据库参与上述业务交易的行为信息对二数据库进行至少一次操作，直到第一数据库和第二数据库参与上述业务交易的行为结果均成功为止，以完成上述业务交易，并继续执行步骤309。

本实施例以第一数据库和第二数据库参与上述业务交易的行为结果达到一致是指第一数据库和第二数据库参与上述业务交易的行为结果均成功为例，但不限于此。

309、删除第一数据库的标识、第一数据库参与业务交易的行为信息、第二数据库的标识以及第二数据库参与业务交易的行为信息，并将上述业务交易的处理状态更新为S状态。

310、将上述业务交易的处理状态标记为R状态，并对之前的操作进行回滚处理。

在此说明，若由步骤303转到步骤310，则这里的回滚处理具体是将上述步骤302中存储的业务请求号及第一数据库的标识以及所标记的P状态等信息全部删除。

若由步骤306转到步骤310，则这里的回滚处理具体是将上述步骤302中存储的业务请求号及第一数据库的标识以及所标记的P状态信息、上述步骤304中记录的第一数据库参与上述业务交易的行为信息、以及上述步骤305中存储的业务请求号及第二数据库的标识等信息全部删除。值得说明的是，若在上述步骤303中也执行了有关操作，则这里回滚操作还需要回退步骤303中所执行的操作。

在一可选实施方式中，可以通过独立的数据库存储上述与业务请求有关的信息，例如上述业务请求号、第一数据库的标识、第二数据库的标识、第一数据库参与业务交易的行为信息、第二数据库参与业务交易的行为信息、业务交易的处理状态等。

进一步，为了便于对上述信息进行管理，可以通过不同的表进行管理。例如，可以通过第一信息表记录上述业务请求号和业务交易的处理状态；通过第二信息表记录第一数据库的标识、第二数据库的标识、第一数据库参与业务交易的行为信息和第二数据库参与业务交易的行为信息。

第一信息表和第二信息表分别如下表2和表3所示。

表2

表3

在一可选实施方式中，上述业务交易可以是账务***中的转账业务。上述交易信息包括流出账户、流入账户和交易金额。

基于此，上述步骤102的一种具体实施方式包括：

根据流出账户确定业务交易涉及的第一数据库，根据交易金额向第一数据库申请对流出账户中的金额进行冻结。

如果流出账户中的可用金额大于或等于交易金额，确定第一数据库满足参与转账业务的条件，并从流出账户中冻结交易金额，记录第一数据库参与账务转账业务的行为信息；

根据流入账户确定业务交易涉及的第二数据库，并向第二数据库申请检查流入账户是否合法；

如果流入账户合法，确定第二数据库满足参与账务转账业务的条件，记录第二数据库参与转账业务的行为信息，并将转账业务的处理状态标记为C状态。

以转账业务为例，则本发明技术方案的详细实施流程如图4所示。图4为本发明又一实施例提供的跨库事务处理方法的流程示意图。如图4所示，该方法包括：

401、接收业务请求，该业务请求包括转账业务涉及的交易信息，该交易信息包括流出账户、流入账户和交易金额。

402、根据上述交易信息中的流出账户，确定上述转账业务涉及的第一数据库。

具体的，确定上述流出账户所在的数据库作为第一数据库。

403、分配可唯一标识上述转账业务的业务请求号，对应存储该业务请求号和上述第一数据库的标识，并标记上述转账业务的处理状态为P状态。

结合上述表2和表3，则可以将转账业务的业务请求号存储到表2中，并将转账业务的当前处理状态P标记在表2中；将表3中业务请求号设置成与表2中的相同，并将第一数据库的标识存储到表3中。

404、根据上述交易信息中的流出账户和交易金额，申请冻结第一数据库中流出账户中上述交易金额。

具体的，该步骤是申请从流出账户中冻结上述交易金额。

405、判断上述冻结操作是否成功；如果是，则执行步骤406；如果否，则执行步骤415。

具体的，判断流出账户中的可用金额是否大于或等于上述交易金额，如果是，则上述冻结操作成功；如果否，则上述冻结操作失败。

在此说明，如果判断流出账户中的可用金额是否大于或等于上述交易金额之外，还可以判断流出账户是否满足其他规则，例如还可以校验流出账户当前的状态是否处于支付状态等。本领域技术人员可以根据实际应用场景，在本实施例提供的有关校验方式的基础上进行适应性扩展。

406、记录第一数据库参与转账业务的行为信息。

具体的，第一数据库参与转账业务的行为信息可以是：流出账户，交易金额，交易预处理的状态是冻结状态。，通过这些信息可以说明流出账户对外的可用金额需要减去上述交易金额，以及表明了后续需要解冻并扣减的金额。可选的，可以将上述第一数据库参与转账业务的行为信息记录到表3中参与者的标识字段中，但不限于此。

407、根据上述交易信息中的流入账户，确定上述转账业务涉及的第二数据库，对应存储上述业务请求号和第二数据库的标识。

具体的，确定流入账户所在的数据库作为第二数据库。在确定第二数据库后，可以将第二数据库的标识存储到表3中。

408、判断第二数据库中的流入账户是否合法，如果是，执行步骤409，如果否，执行步骤415。

409、记录第二数据库参与转账业务的行为信息，将上述转账业务的处理状态更新为C状态。

具体的，第二数据库参与转账业务的行为信息可以是：流入账户，交易金额，交易的预处理状态是待转入。可以将表2中业务的处理状态更新为C状态。C状态是指所有数据库均满足参与上述业务交易的条件后可以对每个数据库进行操作的业务处理状态。

可选的，可以将上述第二数据库参与转账业务的行为信息记录到表3中参与者的标识字段中，但不限于此。

410、在确定上述转账业务的处理状态为C状态时，将第一数据库中流出账户中冻结的交易金额解冻，并扣除该交易金额。

在此说明，在C状态下，跨库事务处理装置可以多次执行将第一数据库中流出账户中冻结的交易金额解冻，并扣除该交易金额的操作，直到从流出账户中成功扣除该交易金额为止。

411、删除第一数据库的标识及第一数据库参与转账业务的行为信息。

412、在第二数据库中流入账户中增加上述交易金额。

具体的，跨库事务处理装置可以在C状态下，多次执行在第二数据库中流入账户中增加上述交易金额的操作，直到在流入账户中成功增加上述交易金额为止。

413、删除第二数据库的标识及第二数据库参与转账业务的行为信息。

414、将上述转账业务的处理状态更新S状态。

415、将转账业务的处理状态标记为R状态，并对之前的操作进行回滚处理。

若由步骤405转到该步骤415，则这里的回滚处理具体是指将上述表2和表3中的数据删除，并反馈交易资金冻结失败的信息。

若由步骤408转到该步骤415，则这里的回滚处理具体是指将上述表2和表3中的数据删除，将流出账户中冻结的交易金额还原。

在该实施例中，在开始之前还可以包括按照前述方法将流出账户和流入账户存储到对应的数据库中。具体的：对所述流出账户的账号编号进行取模运算，根据取模结果将该流出账户存储到第一数据库中；对流入账户的账号编号进行取模运算，根据取模结果将该流入账户存储到第二数据库中。

本实施例提供的方法，通过记录每个数据库参与业务交易的行为信息，并对业务交易的处理状态进行标记，可以在所有数据库均满足参与业务交易的条件后可以对每个数据库执行操作的业务处理状态下，保证多次执行每个数据库参与业务交易的行为直到成功，因此，不会出现某些数据库的提交结果成功某些数据库的提交结果不成功的情况，保证了事务提交结果的一致性。

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

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

图5为本发明一实施例提供的跨库事务处理装置的结构示意图。如图5所示，该装置包括：接收模块51、第一处理模块52和第二处理模块53。

接收模块51，用于接收业务请求，该业务请求包括业务交易涉及的交易信息。

第一处理模块52，与接收模块51连接，用于根据接收模块51接收的业务请求中的交易信息，分别记录该业务交易涉及的多个数据库参与该业务交易的行为信息，并将该业务交易的处理状态标记为待提交状态。该待提交状态是指所有数据库均满足参与上述业务交易的条件后可以对每个数据库进行操作的业务处理状态。

第二处理模块53，与第一处理模块52连接，用于在第一处理模块52标记的待提交状态下，根据第一处理模块52记录的每个数据库参与上述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与上述业务交易的行为结果达到一致为止。

在一可选实施方式中，如图6所示，该装置还包括：删除模块54和标记模块55。

删除模块54，与第二处理模块53连接，用于如果所有数据库参与上述业务交易的行为结果达到一致是指所有数据库参与上述业务交易的行为结果均成功，则在上述所有数据库中部分数据库参与上述业务交易的行为结果成功时，删除该部分数据库参与上述业务交易的行为信息。

标记模块55，与第二处理模块53连接，用于在所有数据库参与上述业务交易的行为结果均成功后，将上述业务交易的处理状态标记为完成状态。

在一可选实施方式中，第二处理模块53具体可用于在将上述业务交易的处理状态标记为待提交状态之后，按照预设的时间长度进行等待，当该预设的时间长度结束后执行在待提交状态下，根据每个数据库参与业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与业务交易的行为结果达到一致为止的操作。

在一可选实施方式中，上述多个数据库包括第一数据库和第二数据库。

则第一处理模块52具体可用于根据上述交易信息，判断第一数据库是否满足参与上述业务交易的条件，如果第一数据库满足参与上述业务交易的条件，记录第一数据库参与上述业务交易的行为信息，根据上述交易信息，判断第二数据库是否满足参与上述业务交易的条件，如果第二数据库满足参与上述业务交易的条件，记录第二数据库参与上述业务交易的行为信息，并将上述业务处理的处理状态标记为待提交状态。

在一可选实施方式中，第一处理模块52还用于在第一数据库或者第二数据库不满足参与上述业务交易的条件时，将上述业务交易的处理状态标记为待回滚状态，并对之前的操作进行回滚处理。

在一可选实施方式中，上述业务交易为转账业务，上述交易信息包括流入账户、流出账户和交易金额。则第一处理模块52具体可用于根据述流出账户确定第一数据库，根据交易金额向第一数据库申请对流出账户中的金额进行冻结；如果流出账户中的可用金额大于或等于交易金额，确定第一数据库满足参与转账业务的条件，并从流出账户中冻结交易金额，记录第一数据库参与转账业务的行为信息；根据流入账户确定第二数据库，并向第二数据库申请检查流入账户是否合法；如果流入账户合法，确定第二数据库满足参与转账业务的条件，记录第二数据库参与转账业务的行为信息，并将转账业务的处理状态标记为待提交状态。

进一步，本实施例的装置还包括：第三处理模块，用于在接收模块51接收业务请求之前，对流出账户的账号编号进行取模运算，根据取模结果将流出账户存储到第一数据库中，并对流入账户的账号编号进行取模运算，根据取模结果将流入账户存储到第二数据库中。

本实施例提供的跨库事务处理装置，通过记录每个数据库参与业务交易的行为信息，并对业务交易的处理状态进行标记，可以在所有数据库均满足参与业务交易的条件后可以对每个数据库执行操作的业务处理状态下，保证多次执行每个数据库参与业务交易的行为直到所有数据库参与业务交易的行为结果达到一致为止，因此，不会出现某些数据库的提交结果成功某些数据库的提交结果不成功的情况，保证了事务提交结果的一致性。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(RandomAccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (12)

1.一种跨库事务处理方法，其特征在于，包括：

接收业务请求，所述业务请求包括业务交易涉及的交易信息；

根据所述交易信息，分别记录所述业务交易涉及的多个数据库参与所述业务交易的行为信息，并将所述业务交易的处理状态标记为待提交状态，所述待提交状态是指所有数据库均满足参与所述业务交易的条件后可以对每个数据库进行操作的业务处理状态；

在所述待提交状态下，根据每个数据库参与所述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与所述业务交易的行为结果达到一致为止。

2.根据权利要求1所述的方法，其特征在于，如果所有数据库参与所述业务交易的行为结果达到一致是指所有数据库参与所述业务交易的行为结果均成功，所述方法还包括：

当所有数据库中部分数据库参与所述业务交易的行为结果成功时，删除所述部分数据库参与所述业务交易的行为信息；

在所有数据库参与所述业务交易的行为结果均成功后，将所述业务交易的处理状态标记为完成状态。

3.根据权利要求1所述的方法，其特征在于，在所述待提交状态下，根据每个数据库参与所述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与所述业务交易的行为结果达到一致为止，包括：

在将所述业务交易的处理状态标记为所述待提交状态之后，按照预设的时间长度进行等待；

当所述时间长度结束后执行在所述待提交状态下，根据每个数据库参与所述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与所述业务交易的行为结果达到一致为止的操作。

4.根据权利要求1所述的方法，其特征在于，所述多个数据库包括第一数据库和第二数据库；

所述根据所述交易信息，分别记录所述业务交易涉及的多个数据库参与所述业务交易的行为信息，并将所述业务交易的处理状态标记为待提交状态，包括：

根据所述交易信息，判断所述第一数据库是否满足参与所述业务交易的条件；

如果所述第一数据库满足参与所述业务交易的条件，记录所述第一数据库参与所述业务交易的行为信息；

根据所述交易信息，判断所述第二数据库是否满足参与所述业务交易的条件；

如果所述第二数据库满足参与所述业务交易的条件，记录所述第二数据库参与所述业务交易的行为信息，并将所述业务处理的处理状态标记为所述待提交状态。

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

在所述第一数据库或者所述第二数据库不满足参与所述业务交易的条件时，将所述业务交易的处理状态标记为待回滚状态，并对之前的操作进行回滚处理。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述业务交易为转账业务，所述交易信息包括流入账户、流出账户和交易金额；

所述根据所述交易信息，分别记录所述业务交易涉及的第一数据库和第二数据库参与所述业务交易的行为信息，并将所述业务交易的处理状态标记为待提交状态，包括：

根据所述流出账户确定所述第一数据库，根据所述交易金额向所述第一数据库申请对所述流出账户中的金额进行冻结；

如果所述流出账户中的可用金额大于或等于所述交易金额，确定所述第一数据库满足参与所述转账业务的条件，并从所述流出账户中冻结所述交易金额，记录所述第一数据库参与所述转账业务的行为信息；

根据所述流入账户确定所述第二数据库，并向所述第二数据库申请检查所述流入账户是否合法；

如果所述流入账户合法，确定所述第二数据库满足参与所述转账业务的条件，记录所述第二数据库参与所述转账业务的行为信息，并将所述转账业务的处理状态标记为所述待提交状态。

7.根据权利要求6所述的方法，其特征在于，所述根据所述交易信息，分别记录所述业务交易涉及的第一数据库和第二数据库参与所述业务交易的行为信息，并将所述业务交易的处理状态标记为待提交状态之前，包括：

对所述流出账户的账号编号进行取模运算，根据取模结果将所述流出账户存储到所述第一数据库中；

对所述流入账户的账号编号进行取模运算，根据取模结果将所述流入账户存储到所述第二数据库中。

8.一种跨库事务处理装置，其特征在于，包括：

接收模块，用于接收业务请求，所述业务请求包括业务交易涉及的交易信息；

第一处理模块，用于根据所述交易信息，分别记录所述业务交易涉及的多个数据库参与所述业务交易的行为信息，并将所述业务交易的处理状态标记为待提交状态，所述待提交状态是指所有数据库均满足参与所述业务交易的条件后可以对每个数据库进行操作的业务处理状态；

第二处理模块，用于在所述待提交状态下，根据每个数据库参与所述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与所述业务交易的行为结果达到一致为止。

9.根据权利要求8所述的装置，其特征在于，还包括：

删除模块，用于如果所有数据库参与所述业务交易的行为结果达到一致是指所有数据库参与所述业务交易的行为结果均成功，则当所有数据库中部分数据库参与所述业务交易的行为结果成功时，删除所述部分数据库参与所述业务交易的行为信息；

标记模块，用于在所有数据库参与所述业务交易的行为结果均成功后，将所述业务交易的处理状态标记为完成状态。

10.根据权利要求8所述的装置，其特征在于，所述第二处理模块具体用于在将所述业务交易的处理状态标记为所述待提交状态之后，按照预设的时间长度进行等待，当所述时间长度结束后执行在所述待提交状态下，根据每个数据库参与所述业务交易的行为信息对每个数据库进行至少一次操作，直到所有数据库参与所述业务交易的行为结果达到一致为止的操作。

11.根据权利要求8或9或10所述的装置，其特征在于，所述多个数据库包括第一数据库和第二数据库；

所述第一处理模块具体用于根据所述交易信息，判断所述第一数据库是否满足参与所述业务交易的条件，如果所述第一数据库满足参与所述业务交易的条件，记录所述第一数据库参与所述业务交易的行为信息，根据所述交易信息，判断所述第二数据库是否满足参与所述业务交易的条件，如果所述第二数据库满足参与所述业务交易的条件，记录所述第二数据库参与所述业务交易的行为信息，并将所述业务处理的处理状态标记为所述待提交状态。

12.根据权利要求11所述的装置，其特征在于，所述第一处理模块还用于在所述第一数据库或者所述第二数据库不满足参与所述业务交易的条件时，将所述业务交易的处理状态标记为待回滚状态，并对之前的操作进行回滚处理。