CN106651367A - 基于分布式事务的账务处理方法及设备 - Google Patents

Abstract

本申请的目的是提供一种基于分布式事务的账务处理方法及设备，具体地，首先根据本次账务处理中所有账户的净发生额确定风险账户，其中所述风险账户为本次账务处理中净发生额小于零的账户；然后对所述风险账户进行资金预处理；在完成所有风险账户的资金预处理之后，根据所有账户的净发生额对本次账务处理中的所有账户进行资金实际处理。与现有技术相比，由于其它非风险账户在本次账务处理过程中即使不与风险账户同步进行资金处理也不会发生资金风险，因此可以不对非风险账户进行资金预处理，而仅对所述风险账户进行资金预处理，由此可以减少账务处理过程中的同步处理步骤，降低资源开销，提高性能。

Description

基于分布式事务的账务处理方法及设备

技术领域

本申请涉及计算机领域，尤其涉及一种基于分布式事务的账务处理方法及设备。

背景技术

在银行/第三方支付的支付处理过程中，经常会采用分布式事务机制来保证业务处理以及资金处理的一致性。分布式事务一般都是以两阶段提交作为技术基础，其第一阶段为准备阶段，在该阶段按每个事务参与者均完成相关的预处理，在所有事务参与者均完成了第一阶段的操作之后，执行第二阶段，即提交阶段，提交预处理的结果，完成实际的处理操作。在整个分布式事务的处理过程中，需要作为事务协调者的事务管理器与作为事务参与者的相关资源服务器之间进行多次协调通信，因此需要更多性能和资源开销。

发明内容

本申请的目的是提供一种基于分布式事务的账务处理方法及设备，以解决现有技术中性能和资源开销较多的问题。

为实现上述目的，本申请提供了一种基于分布式事务的账务处理方法，该方法包括：

根据本次账务处理中所有账户的净发生额确定风险账户，其中所述风险账户为本次账务处理中净发生额小于零的账户；

对所述风险账户进行资金预处理；

在完成所有风险账户的资金预处理之后，根据所有账户的净发生额对本次账务处理中的所有账户进行资金实际处理。

进一步地，所述账务处理中的每个账户至少包括一次资金变动；

根据本次账务处理中所有账户的净发生额确定风险账户，包括：

若某一账户在任意一次资金变动后的净发生额小于零，则将该账户确定为风险账户。

进一步地，对所述风险账户进行资金预处理，包括：

根据所述风险账户的每一次资金变动对该风险账户进行资金预处理。

进一步地，根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理之前，还包括：

对本次账务处理中所有账户进行业务预处理。

进一步地，在完成所有风险账户的资金预处理以及本次账务处理中所有账户的业务预处理之后，还包括：

根据所述业务预处理的结果对本次账务处理中的所有账户进行业务实际处理。

基于本申请的另一方面，还提供了一种基于分布式事务的账务处理设备，该设备包括：

判断装置，用于根据本次账务处理中所有账户的净发生额确定风险账户，其中所述为本次账务处理中净发生额小于零的账户；

第一处理装置，用于对所述风险账户进行资金预处理；

第二处理装置，用于在完成所有风险账户的资金预处理之后，根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理。

进一步地，所述账务处理中的每个账户至少包括一次资金变动；

判断装置，用于当某一账户在任意一次资金变动后的净发生额小于零时，将该账户确定为风险账户。

进一步地，所述第一处理装置，用于根据所述风险账户的每一次资金变动对该风险账户进行资金预处理。

进一步地，所述第一处理装置，还用于在根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理之前，对本次账务处理中所有账户进行业务预处理。

进一步地，所述第二处理装置，还用于在完成所有风险账户的资金预处理以及本次账务处理中所有账户的业务预处理之后，根据所述业务预处理的结果对本次账务处理中的所有账户进行业务实际处理。

与现有技术相比，本申请的技术方案根据账务处理过程中账户的净发生额将某些特定的账户确定为风险账户，由于其它非风险账户在本次账务处理过程中即使不与风险账户同步进行资金处理也不会发生资金风险，因此可以不对非风险账户进行资金预处理，而仅对所述风险账户进行资金预处理，由此可以减少账务处理过程中的同步处理步骤，降低资源开销，提高性能。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的一种基于分布式事务的账务处理方法的流程图；

图2为本申请实施例提供的另一种基于分布式事务的账务处理方法的流程图；

图3为本申请实施例提供的一种基于分布式事务的账务处理设备的结构示意图；

图4为本申请实施例中基于分布式事务的账务处理过程中各个节点之间的拓扑结构示意图；

图5(a)为现有技术中基于分布式事务的账务处理过程中所涉及的各个节点在分布式事务的第一阶段的交互示意图；

图5(b)为现有技术中基于分布式事务的账务处理过程中所涉及的各个节点在分布式事务的第一阶段的交互示意图；

图6为本申请实施例提供的一种基于分布式事务的账务处理方法中所涉及的各个节点在分布式事务的第一阶段的交互示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

图1示出了本申请实施例提供的基于分布式事务的账务处理方法，该方法包括以下步骤：

步骤S101，根据本次账务处理中所有账户的净发生额确定风险账户，其中所述风险账户为本次账务处理中净发生额小于零的账户；

步骤S102，对所述风险账户进行资金预处理。

步骤S103，在完成所有风险账户的资金预处理之后，根据所有账户的净发生额对本次账务处理中的所有账户进行资金实际处理。

在此，所述净发生额是指在账务处理过程中，某一账户在其资金发生变动后的资金额净值。该方法中，根据账务处理过程中账户的净发生额将某些特定的账户确定为风险账户，由于其它非风险账户在本次账务处理过程中即使不与风险账户同步进行资金处理也不会发生资金风险，因此可以不对非风险账户进行资金预处理，而仅对所述风险账户进行资金预处理，由此可以减少账务处理过程中的同步处理步骤，降低资源开销，提高性能。

分布式事务一般都是以两阶段提交作为技术基础，其第一阶段为准备阶段，在该阶段按每个事务参与者均完成相关的预处理，在所有事务参与者均完成了第一阶段的操作之后，执行第二阶段，即提交阶段，提交预处理的结果，完成实际的处理操作，由此保证分布式事务的原子性(即各个事务参与者的处理要么全部完成，要么全部失败)。以一次转账过程中涉及的账务处理为例，账户A向账户B付款100元，账户B再向账户C付款50元。若账户A、B、C的对应的相关事务处理分别由资源服务器401、402和403执行，并由事务管理器400对所述资源服务器401、402和403的事务提交进行统一的管理，其拓扑结构如图4所示。若以现有方式进行处理，在分布式事务的第一阶段需要进行如下的预处理：

1、对账户A做资金预留冻结100元，确保账户A有足够的余额；

2、记录账户B未达到的资金100元；

3、从账户B未达到的资金中扣除50元；

4、记录账户C未到达的资金50元。

在第一阶段，账户A、B、C对应的资源服务器401、402和403在本地执行各自的预处理操作，生成对应的事务日志，使得相应的事务在资源服务器本地完成，且处于待提交的状态，若顺利完成则向事务管理器400发送就绪消息，图5(a)示出了第一阶段的交互示意图。由此，仅需要在第二阶段提交事务即可完成资金的实际操作处理。

当所有账户第一阶段的资金预处理都完成(事务管理器接收到本次账务处理涉及的所有资源服务器发送的就绪消息)之后，即可执行第二阶段的实际处理操作：

1、账户A余额减少100元；

2、账户B余额增加50元；

3、账户C余额增加50元。

由此完成本次转账。

在第二阶段，事务管理器400会向各个资源管理器发送提交消息，资源服务器401、402和403在收到提交消息后将已经在本地完成且处于待提交状态的事务进行提交(即执行数据库的Commit命令)，由此完成分布式事务第二阶段的实际处理，图5(b)示出了第二阶段的交互示意图。

由于第二阶段的事务提交是一个耗时极短的操作，提交失败的概率很小，由此保证了分布式事务的原子性。因此采用分布式事务机制来进行账务处理能够保证多个账户的资金处理的一致性，即所有账户都要同步进行操作，防止发生资金风险。由上述现有的分布式事务处理过程可知，由于在整个分布式事务的处理过程中需要在多个节点(多个资源服务器与事务管理器)之间进行多次协调通信，如在第一阶段事务管理器需要接收到所有账户所对应的资源服务器的就绪消息之后，才会进行第二阶段的实际处理，因此现有技术方案在一定程度上会受限于节点设备的性能、或者网络资源以及计算资源的开销等。

但是，在账务处理的实际场景下，如果一个账户在某次账务处理中其资金的净发生额大于零，那么该账户发生资金风险的可能性很小。因此，可以不需要在分布式事务的第一阶段对发生资金风险可能性很小的非风险账户进行资金预处理，即可以对资金的净发生额大于零的非风险账户进行异步操作。由此，可以对现有分布式事务处理方案进行改进，以达到减少同步处理步骤，降低资源开销，提高性能的目的。

仍以前述转账为例，若采用本申请提供的账务处理方法，根据本次账务处理中所有账户的净发生额，账户A为-100元、账户B为+50元、账户C为+50元，由此可以确定账户A为风险账户。因此可以仅对账户A进行第一阶段的资金预处理。在完成账户A的第一阶段的资金预处理，可以根据账户的净发生额对本次账务处理中的所有账户进行资金实际处理。

因此，上述转账过程中分布式事务的第一阶段和第二阶段的处理如下：

分布式事务第一阶段：

1、对账户A做资金预留冻结100元，确保账户A有足够的余额。

在第一阶段，仅需要由账户A对应的资源服务器401本地执行的预处理操作，生成对应的事务日志，使得相应的事务在资源服务器本地完成，且处于待提交的状态，若顺利完成则向事务管理器400发送就绪消息，图6示出了第一阶段的交互示意图。

当风险账户A的第一阶段的资金预处理都完成(事务管理器接收到风险账户A对应的资源服务器401发送的就绪消息)之后，即可执行第二阶段的实际处理操作：

1、账户A余额减少100元；

2、账户B余额增加50元；

3、账户C余额增加50元。

在第二阶段，事务管理器400会向所有账户对应的资源管理器发送提交消息，风险账户A对应的资源服务器401在收到提交消息后将已经在本地完成且处于待提交状态的事务进行提交，而账户B和C对应的资源服务器402和资源服务器403，在直接进行事务的相关处理，生成相应地事务日志，并在完成后进行事务的提交。第二阶段的交互示意图与现有技术类似，可参考图5(b)。

通过此种方式，原本在分布式事务的第一阶段需要同步完成的四步预处理可以减少到一步，可以减少分布式事务第一阶段75％的处理操作，并且非风险账户的事务处理可以无需与风险账户的事务处理同步进行，可以第一阶段减少协调通信的次数，由此降低资源开销，提高性能。

进一步地，由于在一次账务处理中的每个账户至少会包括一次资金变动，那么对于所述步骤S101中根据本次账务处理中所有账户的净发生额确定风险账户，具体包括：若某一账户在任意一次资金变动后的净发生额小于零，则将该账户确定为风险账户。

仍以前述转账为例，其包括4次资金变动，涉及3个账户，其中账户A包括一次资金变动，账户B包括两次资金变动，账户C包括一次资金变动。这4次资金变动以及资金变动后账户的净发生额如下表所示：

账户	资金变动额	净发生额
			A	-100	-100
B	+100	+100
			B	-50	+100-50＝+50
C	+50	+50

由上表可知，账户A在1次资金变动后的净发生额为-100元，账户B在第1次和第2次资金变动后的净发生额分别为+100和+50元，账户C在1次资金变动后的净发生额为+50元，由此可以确定，账户A为风险账户。

在实际场景下，还有另一种情况，同样以账户A、B、C之间的转账为例，账户A向账户B付款100元，账户B再向账户C付款150元，同样涉及4次资金变动，此时这4次资金变动后的净发生额如下表所示：

账户	资金变动额	净发生额
			A	-100	-100
B	+100	+100
			B	-150	+100-150＝-50
C	+150	+50

由上表可知，账户A在1次资金变动后的净发生额为-100元，账户B在第1次和第2次资金变动后的净发生额分别为+100和-50元，账户C在1次资金变动后的净发生额为+50元。由于账户B在第2次资金变动后的净发生额小于零，则账户B也确定为风险账户。

在此基础上，若还有账户D向账户B付款80元，账户B在第1次、第2次和第3次资金变动后的净发生额分别为+100、-50和+30元。由于只要任意一次的资金变动后净发生额小于零，则将该账户确定为风险账户，因此账户B仍为风险账户。即只要某一账户在任意一次的资金变动之后其净发生额小于零，无论后续的资金变动是否使其的净发生额大于零，仍将该账户作为风险账户，与其它风险账户同步操作。由此，可以避免一些潜在的资金风险，提高账务处理过程中资金的安全性。

进一步地，步骤S102中对所述风险账户进行资金预处理，具体包括：根据所述风险账户的每一次资金变动对该风险账户进行资金预处理。即对于某一账户，若其在前n次的资金变动中净发生额均大于零，若在第n+1次的资金变动后确定为风险账户，那么需要包括前面n次在内的每次资金变动都进行资金预处理。仍以前述账户A向账户B付款100元，账户B再向账户C付款150元的应用场景为例，账户B在第1次资金变动后的净发生额为+100元，而在第2次资金变动后的净发生额为-50元，需要对涉及账户B的每一次资金变动均进行资金预处理，因此分布式事务第一阶段的资金预处理具体为：

1、对账户A做资金预留冻结100元，确保账户A有足够的余额；

2、记录账户B未达到的资金100元；

3、从账户B未达到的资金中扣除150元；

由此，相较于现有技术省略了分布式事务第一阶段中的第4步处理，即记录账户C未到达的资金150元的资金预处理，可以减少分布式事务第一阶段25％的处理操作，由此降低资源开销，提高性能。由于在实际应用中，前述提及的第一种场景中的情况较为常见，资金流越复杂，本申请提供的方案能够达到的优化效果越显著。

在实际应用中，一次账务处理除了资金处理之外，往往还伴随相应的业务处理。因此，对于所述的基于分布式事务的账务处理方法，在根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理之前，还包括：对本次账务处理中所有账户进行业务预处理。其中，以前述转账的场景为例，其对应的业务处理即为通知拥有所述账户的用户已经转账成功或者转账失败的消息。在此，所述业务预处理是指针对业务的分布式事务第一阶段的处理，即是指处理相关业务的资源服务器已经在本地完成通知用户转账成功的准备，还未正式提交事务管理器。

相应地，业务处理的第二阶段，即对于相应账户的业务实际处理，则需要在在完成所有风险账户的资金预处理以及本次账务处理中所有账户的业务预处理之后进行。对应于前述的业务预处理，此处业务实际处理是指将预处理的结果正式提交事务管理器，正式向用户发送转账成功的消息。例如，在使用某支付系统转账时，支付系统账户中的资金额发生实际变化即为完成了资金实际处理，而支付系统通过消息提示用户“转账完成，转账XX元”，即为完成了相应的业务实际处理，通过分布式事务的方式来保证两者的同步完成。因此，所述的基于分布式事务的账务处理方法，具体包括如图2所示的以下步骤：

步骤S201，根据本次账务处理中所有账户的净发生额确定风险账户，其中所述风险账户为本次账务处理中净发生额小于零的账户；

步骤S202，对所述风险账户进行资金预处理以及对所有账户进行业务预处理。此阶段即为基于分布式事务的账户处理的第一阶段。

步骤S303，在完成所有风险账户的资金预处理以及本次账务处理中所有账户的业务预处理之后，根据所有账户的净发生额对本次账务处理中的所有账户进行资金实际处理，同时根据所述业务预处理的结果对本次账务处理中的所有账户进行业务实际处理。此阶段即为基于分布式事务的账户处理的第二阶段。

由此，通过分布式事务的方式在减少处理数据量的前提下，避免发生资金风险。

图5示出了本申请实施例提供的基于分布式事务的账务处理设备，该设备包括判断装置510、第一处理装置520和第二处理装置530。具体地，判断装置510用于根据本次账务处理中所有账户的净发生额确定风险账户，其中所述为本次账务处理中净发生额小于零的账户；第一处理装置520用于对所述风险账户进行资金预处理；第二处理装置530用于在完成所有风险账户的资金预处理之后，根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理。

在此，所述净发生额是指在账务处理过程中，某一账户在其资金发生变动后的资金额净值。在该设备的处理过程中，根据账务处理过程中账户的净发生额将某些特定的账户确定为风险账户，由于其它非风险账户在本次账务处理过程中即使不与风险账户同步进行资金处理也不会发生资金风险，因此可以不对非风险账户进行资金预处理，而仅对所述风险账户进行资金预处理，由此可以减少账务处理过程中的同步处理步骤，降低资源开销，提高性能。

在此，本领域技术人员应当理解，所述账务处理设备可以包括但不限于用户设备、网络设备或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备包括但不限于个人计算机、触控终端等实现；所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

分布式事务一般都是以两阶段提交作为技术基础，其第一阶段为准备阶段，在该阶段按每个事务参与者均完成相关的预处理，在所有事务参与者均完成了第一阶段的操作之后，执行第二阶段，即提交阶段，提交预处理的结果，完成实际的处理操作，由此保证分布式事务的原子性(即各个事务参与者的处理要么全部完成，要么全部失败)。以一次转账过程中涉及的账务处理为例，账户A向账户B付款100元，账户B再向账户C付款50元。若账户A、B、C的对应的相关事务处理分别由资源服务器401、402和403执行，并由事务管理器400对所述资源服务器401、402和403的事务提交进行统一的管理，其拓扑结构如图4所示。若以现有方式进行处理，在分布式事务的第一阶段需要进行如下的预处理：

1、对账户A做资金预留冻结100元，确保账户A有足够的余额；

2、记录账户B未达到的资金100元；

3、从账户B未达到的资金中扣除50元；

4、记录账户C未到达的资金50元。

在第一阶段，账户A、B、C对应的资源服务器401、402和403在本地执行各自的预处理操作，生成对应的事务日志，使得相应的事务在资源服务器本地完成，且处于待提交的状态，若顺利完成则向事务管理器400发送就绪消息，图5(a)示出了第一阶段的交互示意图。由此，仅需要在第二阶段提交事务即可完成资金的实际操作处理。

当所有账户第一阶段的资金预处理都完成(事务管理器接收到本次账务处理涉及的所有资源服务器发送的就绪消息)之后，即可执行第二阶段的实际处理操作：

1、账户A余额减少100元；

2、账户B余额增加50元；

3、账户C余额增加50元。

由此完成本次转账。

在第二阶段，事务管理器400会向各个资源管理器发送提交消息，资源服务器401、402和403在收到提交消息后将已经在本地完成且处于待提交状态的事务进行提交(即执行数据库的Commit命令)，由此完成分布式事务第二阶段的实际处理，图5(b)示出了第二阶段的交互示意图。

由于第二阶段的事务提交是一个耗时极短的操作，提交失败的概率很小，由此保证了分布式事务的原子性。因此采用分布式事务机制来进行账务处理能够保证多个账户的资金处理的一致性，即所有账户都要同步进行操作，防止发生资金风险。由上述现有的分布式事务处理过程可知，由于在整个分布式事务的处理过程中需要在多个节点(多个资源服务器与事务管理器)之间进行多次协调通信，如在第一阶段事务管理器需要接收到所有账户所对应的资源服务器的就绪消息之后，才会进行第二阶段的实际处理，因此现有技术方案在一定程度上会受限于节点设备的性能、或者网络资源以及计算资源的开销等。

但是，在账务处理的实际场景下，如果一个账户在某次账务处理中其资金的净发生额大于零，那么该账户发生资金风险的可能性很小。因此，可以不需要在分布式事务的第一阶段对发生资金风险可能性很小的额非风险账户进行资金预处理，即可以对资金的净发生额大于零的非风险账户进行异步操作。由此，可以对现有分布式事务处理方案进行改进，以达到减少同步处理步骤，降低资源开销，提高性能的目的。

仍以前述转账为例，若采用本申请提供的账务处理设备进行处理，根据本次账务处理中所有账户的净发生额，账户A为-100元、账户B为+50元、账户C为+50元，由此可以确定账户A为风险账户。因此可以仅对账户A进行第一阶段的资金预处理。在完成账户A的第一阶段的资金预处理，可以根据账户的净发生额对本次账务处理中的所有账户进行资金实际处理。

因此，上述转账过程中分布式事务的第一阶段和第二阶段的处理如下：

分布式事务第一阶段：

1、对账户A做资金预留冻结100元，确保账户A有足够的余额。

在第一阶段，仅需要由账户A对应的资源服务器401本地执行的预处理操作，生成对应的事务日志，使得相应的事务在资源服务器本地完成，且处于待提交的状态，若顺利完成则向事务管理器400发送就绪消息，图6示出了第一阶段的交互示意图。

当风险账户A的第一阶段的资金预处理都完成(事务管理器接收到风险账户A对应的资源服务器401发送的就绪消息)之后，即可执行第二阶段的实际处理操作：

1、账户A余额减少100元；

2、账户B余额增加50元；

3、账户C余额增加50元。

在第二阶段，事务管理器400会向所有账户对应的资源管理器发送提交消息，风险账户A对应的资源服务器401在收到提交消息后将已经在本地完成且处于待提交状态的事务进行提交，而账户B和C对应的资源服务器402和资源服务器403，在直接进行事务的相关处理，生成相应地事务日志，并在完成后进行事务的提交。第二阶段的交互示意图与现有技术类似，可参考图5(b)。

通过此种方式，原本在分布式事务的第一阶段需要同步完成的四步预处理可以减少到一步，可以减少分布式事务第一阶段75％的处理操作，并且非风险账户的事务处理可以无需与风险账户的事务处理同步进行，可以第一阶段减少协调通信的次数，由此降低资源开销，提高性能。

进一步地，由于在一次账务处理中的每个账户至少会包括一次资金变动，那么所述判断装置510具体用于：若某一账户在任意一次资金变动后的净发生额小于零，则将该账户确定为风险账户。

仍以前述转账为例，其包括4次资金变动，涉及3个账户，其中账户A包括一次资金变动，账户B包括两次资金变动，账户C包括一次资金变动。这4次资金变动以及资金变动后账户的净发生额如下表所示：

账户	资金变动额	净发生额
			A	-100	-100
B	+100	+100
			B	-50	+100-50＝+50
C	+50	+50

由上表可知，账户A在1次资金变动后的净发生额为-100元，账户B在第1次和第2次资金变动后的净发生额分别为+100和+50元，账户C在1次资金变动后的净发生额为+50元，由此可以确定，账户A为风险账户。

在实际场景下，还有另一种情况，同样以账户A、B、C之间的转账为例，账户A向账户B付款100元，账户B再向账户C付款150元，同样涉及4次资金变动，此时这4次资金变动后的净发生额如下表所示：

账户	资金变动额	净发生额
			A	-100	-100
B	+100	+100
			B	-150	+100-150＝-50
C	+150	+50

由上表可知，账户A在1次资金变动后的净发生额为-100元，账户B在第1次和第2次资金变动后的净发生额分别为+100和-50元，账户C在1次资金变动后的净发生额为+50元。由于账户B在第2次资金变动后的净发生额小于零，则账户B也确定为风险账户。

在此基础上，若还有账户D向账户B付款80元，账户B在第1次、第2次和第3次资金变动后的净发生额分别为+100、-50和+30元。由于只要任意一次的资金变动后净发生额小于零，则将该账户确定为风险账户，因此账户B仍为风险账户。即只要某一账户在任意一次的资金变动之后其净发生额小于零，无论后续的资金变动是否使其的净发生额大于零，仍将该账户作为风险账户，与其它风险账户同步操作。由此，可以避免一些潜在的资金风险，提高账务处理过程中资金的安全性。

进一步地，所述第一处理装置520，具体用于：根据所述风险账户的每一次资金变动对该风险账户进行资金预处理。即对于某一账户，若其在前n次的资金变动中净发生额均大于零，若在第n+1次的资金变动后确定为风险账户，那么需要包括前面n次在内的每次资金变动都进行资金预处理。仍以前述账户A向账户B付款100元，账户B再向账户C付款150元的应用场景为例，账户B在第1次资金变动后的净发生额为+100元，而在第2次资金变动后的净发生额为-50元，需要对涉及账户B的每一次资金变动均进行资金预处理，因此分布式事务第一阶段的资金预处理具体为：

1、对账户A做资金预留冻结100元，确保账户A有足够的余额；

2、记录账户B未达到的资金100元；

3、从账户B未达到的资金中扣除150元；

由此，相较于现有技术省略了分布式事务第一阶段中的第4步处理，即记录账户C未到达的资金150元的资金预处理，可以减少了分布式事务第一阶段25％的处理操作，由此降低资源开销，提高性能。由于在实际应用中，前述提及的第一种场景中的情况较为常见，资金流越复杂，本申请提供的方案能够达到的优化效果越显著。

在实际应用中，一次账务处理除了资金处理之外，往往还伴随相应的业务处理。因此，对于所述的基于分布式事务的账务处理设备，所述第一处理装置520，还用于在根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理之前，对本次账务处理中所有账户进行业务预处理。其中，以前述转账的场景为例，其对应的业务处理即为通知拥有所述账户的用户已经转账成功或者转账失败的消息。在此，所述业务预处理是指针对业务的分布式事务第一阶段的处理，即是指处理相关业务的资源服务器已经在本地完成通知用户转账成功的准备，还未正式提交事务管理器。

相应地，业务处理的第二阶段，即对于相应账户的业务实际处理，则需要在在完成所有风险账户的资金预处理以及本次账务处理中所有账户的业务预处理之后进行。对应于前述的业务预处理，此处业务实际处理是指将预处理的结果正式提交事务管理器，正式向用户发送转账成功的消息。例如，在使用某支付系统转账时，支付系统账户中的资金额发生实际变化即为完成了资金实际处理，而支付系统通过消息提示用户“转账完成，转账XX元”，即为完成了相应的业务实际处理，通过分布式事务的方式来保证两者的同步完成。因此，对于所述基于分布式事务的账务处理设备中，所述第二处理装置，还用于：在完成所有风险账户的资金预处理以及本次账务处理中所有账户的业务预处理之后，根据所述业务预处理的结果对本次账务处理中的所有账户进行业务实际处理。

由此，通过分布式事务的方式在减少处理数据量的前提下，避免发生资金风险。

综上所述，本申请的技术方案根据账务处理过程中账户的净发生额将某些特定的账户确定为风险账户，由于其它非风险账户在本次账务处理过程中即使不与风险账户同步进行资金处理也不会发生资金风险，因此可以不对非风险账户进行资金预处理，而仅对所述风险账户进行资金预处理，由此可以减少账务处理过程中的同步处理步骤，降低资源开销，提高性能。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (10)

1.一种基于分布式事务的账务处理方法，其中，该方法包括：

根据本次账务处理中所有账户的净发生额确定风险账户，其中所述风险账户为本次账务处理中净发生额小于零的账户；

对所述风险账户进行资金预处理；

在完成所有风险账户的资金预处理之后，根据所有账户的净发生额对本次账务处理中的所有账户进行资金实际处理。

2.根据权利要求1所述的方法，其中，所述账务处理中的每个账户至少包括一次资金变动；

根据本次账务处理中所有账户的净发生额确定风险账户，包括：

若某一账户在任意一次资金变动后的净发生额小于零，则将该账户确定为风险账户。

3.根据权利要求2所述的方法，其中，对所述风险账户进行资金预处理，包括：

根据所述风险账户的每一次资金变动对该风险账户进行资金预处理。

4.根据权利要求1至3中任一项所述的方法，其中，根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理之前，还包括：

对本次账务处理中所有账户进行业务预处理。

5.根据权利要求4所述的方法，其中，在完成所有风险账户的资金预处理以及本次账务处理中所有账户的业务预处理之后，还包括：

根据所述业务预处理的结果对本次账务处理中的所有账户进行业务实际处理。

6.一种基于分布式事务的账务处理设备，其中，该设备包括：

判断装置，用于根据本次账务处理中所有账户的净发生额确定风险账户，其中所述为本次账务处理中净发生额小于零的账户；

第一处理装置，用于对所述风险账户进行资金预处理；

第二处理装置，用于在完成所有风险账户的资金预处理之后，根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理。

7.根据权利要求6所述的设备，其中，所述账务处理中的每个账户至少包括一次资金变动；

判断装置，用于当某一账户在任意一次资金变动后的净发生额小于零时，将该账户确定为风险账户。

8.根据权利要求7所述的设备，其中，所述第一处理装置，用于根据所述风险账户的每一次资金变动对该风险账户进行资金预处理。

9.根据权利要求6至8中任一项所述的设备，其中，所述第一处理装置，还用于在根据所述资金预处理的结果对本次账务处理中的所有账户进行资金实际处理之前，对本次账务处理中所有账户进行业务预处理。

10.根据权利要求9所述的设备，其中，所述第二处理装置，还用于在完成所有风险账户的资金预处理以及本次账务处理中所有账户的业务预处理之后，根据所述业务预处理的结果对本次账务处理中的所有账户进行业务实际处理。