一种分布式记账方法、设备及系统与流程

本发明关于金融技术领域，特别是关于金融领域中的支付技术，具体的讲是一种分布式记账方法、分布式记账系统、计算机设备以及计算机可读存储介质。

背景技术：

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

二代支付系统上线后，为适应商业银行数据大集中趋势的需求，其接入方式由多点接入、多点清算过渡为一点接入、一点清算。第二代支付系统目前能支持的峰值为每小时50万次的单一账户访问量，超过商业银行峰值的最大业务量，能够满足当前的业务处理需求。但是随着我国社会经济快速发展，经济规模不断扩大，交易活动日益频繁，在可预见的未来，大型商业银行在高峰时业务量有可能突破每小时50万笔，导致单一清算账户成为热点账户。

目前支付系统更多的采用集中式架构，如图16所示，其特点是架构简捷稳定，便于纵向扩展与管理，技术成熟，但是集中式架构对高端设备依赖较强，业务连续性指标有待加强。集中式账户记账时所有清算账户数据均部署在主机节点上，清算系统收到交易系统提交的支付清算报文后，逐笔实时锁定借贷记账户，进行清算处理。如果可用头寸足够支付的立即做账务处理。可用头寸不足时，将该清算指令纳入清算排队处理，清算系统实时返回该清算回执报文，同一商业银行的所有清算报文串行处理。集中式架构存在如下的技术缺陷：

1)不支持分布式部署和分布式事务

单机部署单点故障风险高，不符合业务连续性需求，随着我国社会经济的快速发展，日益频繁的交易活动对业务连续性、可靠性的需求更高；为最大程度保障支付系统安全稳定，要求分布式部署，提升处理性能，保证业务连续性需求。

2)资源利用率低，性能待进一步提高

集中记账清算时,采用xa事务的两阶段提交，数据库操作时需同时锁定借贷记账户的所有余额，不利于账户资源的充分应用；大部分支付业务集中在少数几大行之间，随着业务量的增长，系统清算处理存在性能瓶颈。

3)依赖高端软硬件设备，不符合国家自主可控的要求

集中式架构对高端软硬件设备依赖较强，无法灵活适应多样化灵活部署的需求，也不适应国家对关键业务信息系统自主可控的安全要求。

因此，如何提供一种新的方案，其能够克服上述技术缺陷是本领域亟待解决的技术难题。

技术实现要素：

有鉴于此，本发明实施例提供了一种分布式记账方法、分布式记账系统、计算机设备以及计算机可读存储介质，通过采用开源事务框架tcc来协调借贷分离的分布式事务，提高了业务连续性，通过分布式改造，提高了系统健壮性，实现了当部分节点故障时，能够保障业务连续性不受影响，同时避免了集中式架构依赖高端软硬件设备的弊端。

本发明的目的之一是，提供一种分布式记账系统，包括主服务器、事务管理器、第一从服务器以及第二从服务器，所述第一从服务器以及第二从服务器均包括try接口、confirm接口和cancel接口，所述confirm接口和所述cancel接口幂等；

所述主服务器，用于根据一业务请求报文调用所述第一从服务器的try接口以及所述第二从服务器的try接口，所述业务请求报文对应的账户数据位于不同类型的从服务器的数据库实例中；

所述第一从服务器，用于根据账户合法性、账户状态以及可用余额输出第一try接口返回信息；

所述第二从服务器，用于根据账户合法性以及账户状态输出第二try接口返回信息；

所述事务管理器，用于根据所述第一try接口返回信息以及所述第二try接口返回信息调用所述第一从服务器以及所述第二从服务器，以实现与所述业务请求报文对应的业务。

在本发明的优选实施方式中，所述主服务器包括：

请求报文接收模块，用于接收所述业务请求报文；

请求报文检查模块，用于对所述业务请求报文的报文格式、业务合法性以及账户状态进行检查；

业务凭证记录模块，用于当所述请求报文检查模块检查通过时，记录业务凭证；

服务接口调用模块，用于当所述请求报文检查模块检查通过时，调用第一从服务器的try接口以及所述第二从服务器的try接口。

在本发明的优选实施方式中，所述第一从服务器包括：

第一账户检查模块，用于对所述第一从服务器的账户合法性、账户状态以及可用余额进行检查；

业务金额冻结模块，用于当所述第一账户检查模块检查通过时，根据所述可用余额冻结业务金额；

第一信息输出模块，用于根据所述第一账户检查模块以及所述业务金额冻结模块输出第一try接口返回信息。

在本发明的优选实施方式中，所述第一信息输出模块包括：

接口正常输出模块，用于当所述业务金额冻结模块冻结业务金额成功时输出try接口正常的第一try接口返回信息；

接口异常输出模块，用于当所述第一账户检查模块检查未通过或所述业务金额冻结模块冻结业务金额失败时输出try接口异常的第一try接口返回信息。

在本发明的优选实施方式中，所述第二从服务器包括：

第二账户检查模块，用于对所述第二从服务器的账户合法性以及账户状态进行检查；

第二信息输出模块，用于当所述第二账户检查模块检查未通过时输出所述第二从服务器的try接口异常的第二try接口返回信息，当所述第二账户检查模块检查通过时输出所述第二从服务器的try接口正常的第二try接口返回信息。

在本发明的优选实施方式中，所述事务管理器包括：

返回信息接收模块，用于接收所述第一try接口返回信息以及所述第二try接口返回信息；

返回信息解析模块，用于解析所述第一try接口返回信息以及所述第二try接口返回信息得到解析结果；

第一接口调用模块，用于当所述解析结果显示所述第一try接口返回信息的try接口正常以及所述第二try接口返回信息的try接口正常时，调用所述第一从服务器的confirm接口以及所述第二从服务器的confirm接口；

第二接口调用模块，用于当所述解析结果显示所述第一try接口返回信息的try接口异常和/或所述第二try接口返回信息的try接口异常时，调用所述第一从服务器的cancel接口以及所述第二从服务器的cancel接口。

在本发明的优选实施方式中，所述第一从服务器，还用于通过confirm接口对所述账户余额进行扣减，对冻结的业务金额进行释放并记录账务明细；

所述第二从服务器，还用于通过confirm接口对所述账户余额进行增加并记录账务明细；

所述主服务器还包括第一凭证更新模块，用于当所述解析结果显示所述第一try接口返回信息的try接口正常以及所述第二try接口返回信息的try接口正常时，将所述业务凭证更新为业务状态为已清算。

在本发明的优选实施方式中，所述第一从服务器，还用于当冻结业务金额成功时通过cancel接口对冻结金额进行释放；

所述第二从服务器，还用于通过cancel接口针对try阶段事务幂等性回滚；

所述主服务器还包括第二凭证更新模块，用于当所述解析结果显示所述第一try接口返回信息的try接口异常和/或所述第二try接口返回信息的try接口异常时，将所述业务凭证更新为业务状态为已失败。

本发明的目的之一是，提供一种分布式记账方法，包括：

所述主服务器根据一业务请求报文调用所述第一从服务器的try接口以及所述第二从服务器的try接口，所述业务请求报文对应的账户数据位于不同类型的从服务器的数据库实例中；

所述第一从服务器根据账户合法性、账户状态以及可用余额输出第一try接口返回信息；

所述第二从服务器根据账户合法性以及账户状态输出第二try接口返回信息；

所述事务管理器根据所述第一try接口返回信息以及所述第二try接口返回信息调用所述第一从服务器以及所述第二从服务器，以实现与所述业务请求报文对应的业务。

在本发明的优选实施方式中，所述主服务器根据一业务请求报文调用所述第一从服务器的try接口以及所述第二从服务器的try接口包括：

所述主服务器接收所述业务请求报文；

对所述业务请求报文的报文格式、业务合法性以及账户状态进行检查；

当所述请求报文检查模块检查通过时，记录业务凭证；

调用第一从服务器的try接口以及所述第二从服务器的try接口。

在本发明的优选实施方式中，所述第一从服务器根据账户合法性、账户状态以及可用余额输出第一try接口返回信息包括：

所述第一从服务器对第一从服务器的账户合法性、账户状态以及可用余额进行检查，得到检查结果；

当所述检查结果显示检查通过时，根据所述可用余额冻结业务金额，得到冻结结果；

根据所述检查结果以及所述冻结结果输出第一try接口返回信息。

在本发明的优选实施方式中，根据所述检查结果以及所述冻结结果输出第一try接口返回信息包括：

当所述冻结结果显示冻结业务金额成功时，所述第一从服务器输出try接口正常的第一try接口返回信息；

当所述检查结果显示检查未通过或所述冻结信息显示冻结业务金额失败时，输出try接口异常的第一try接口返回信息。

在本发明的优选实施方式中，所述第二从服务器根据账户合法性以及账户状态输出第二try接口返回信息包括：

所述第二从服务器对所述第二从服务器的账户合法性以及账户状态进行检查；

当检查未通过时，输出try接口异常的第二try接口返回信息；

当检查通过时，输出try接口正常的第二try接口返回信息。

在本发明的优选实施方式中，所述事务管理器根据所述第一try接口返回信息以及所述第二try接口返回信息调用所述第一从服务器以及所述第二从服务器包括：

所述事务管理器接收所述第一try接口返回信息以及所述第二try接口返回信息；

解析所述第一try接口返回信息以及所述第二try接口返回信息得到解析结果；

当所述解析结果显示所述第一try接口返回信息的try接口正常以及所述第二try接口返回信息的try接口正常时，调用所述第一从服务器的confirm接口以及所述第二从服务器的confirm接口；

当所述解析结果显示所述第一try接口返回信息的try接口异常和/或所述第二try接口返回信息的try接口异常时，调用所述第一从服务器的cancel接口以及所述第二从服务器的cancel接口。

在本发明的优选实施方式中，所述方法还包括：

所述第一从服务器通过confirm接口对所述账户余额进行扣减，对冻结的业务金额进行释放并记录账务明细；

所述第二从服务器通过confirm接口对所述账户余额进行增加并记录账务明细；

所述主服务器将所述业务凭证更新为业务状态为已清算。

在本发明的优选实施方式中，所述方法还包括：

当冻结业务金额成功时，所述第一从服务器通过cancel接口对冻结金额进行释放；

所述第二从服务器通过cancel接口针对try阶段事务幂等性回滚；

所述主服务器将所述业务凭证更新为业务状态为已失败。

本发明的目的之一是，提供一种计算机设备，包括：适于实现各指令的处理器以及存储设备，所述存储设备存储有多条指令，所述指令适于由处理器加载并执行一种分布式记账方法。

本发明的目的之一是，提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序用于执行一种分布式记账方法。

本发明的有益效果在于，提供了一种分布式记账方法、分布式记账系统、计算机设备以及计算机可读存储介质，通过采用开源事务框架tcc来协调借贷分离的分布式事务，提高了业务连续性，通过分布式改造，提高了系统健壮性，实现了当部分节点故障时，能够保障业务连续性不受影响，同时避免了集中式架构依赖高端软硬件设备的弊端。

为让本发明的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

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

图1为本发明实施例提供的一种分布式记账系统的结构示意图；

图2为本发明实施例提供的一种分布式记账系统中主服务器的实施方式一的结构示意图；

图3为本发明实施例提供的一种分布式记账系统中第一从服务器的结构示意图；

图4为本发明实施例提供的一种分布式记账系统中第一信息输出模块的结构示意图；

图5为本发明实施例提供的一种分布式记账系统中第二从服务器的结构示意图；

图6为本发明实施例提供的一种分布式记账系统中事务管理器的结构示意图；

图7为本发明实施例提供的一种分布式记账系统中主服务器的实施方式二的结构示意图；

图8为本发明实施例提供的一种分布式记账方法的流程示意图；

图9为图8中的步骤s101的具体流程示意图；

图10为图8中的步骤s102的具体流程示意图；

图11为图10中的步骤s203的具体流程示意图；

图12为图8中的步骤s103的具体流程示意图；

图13为图8中的步骤s104的具体流程示意图；

图14为本发明实施例提供的一种分布式记账方法的实施方式二的流程示意图；

图15为本发明实施例提供的一种分布式记账方法的实施方式三的流程示意图；

图16现有技术中的支付系统的集中式架构示意图；

图17为本发明提供的具体实施例中账户数据分布置两个数据库实例的示意图；

图18为本发明的一个完整的tcc事务参与方的示意图；

图19为本发明提供的实施例1中业务处理的流程示意图；

图20是本发明提供的实施例2中业务处理的流程示意图。

具体实施方式

下面将结合附图，对本发明实施例中的技术方案进行清楚、完整地描述参考在附图中示出并在以下描述中详述的非限制性示例实施例，更加全面地说明本发明的示例实施例和它们的多种特征及有利细节。应注意的是，图中示出的特征不是必须按照比例绘制。本发明省略了已知材料、组件和工艺技术的描述，从而不使本发明的示例实施例模糊。所给出的示例仅旨在有利于理解本发明示例实施例的实施，以及进一步使本领域技术人员能够实施示例实施例。因而，这些示例不应被理解为对本发明的实施例的范围的限制。

除非另外特别定义，本发明使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。本发明中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。此外，在本发明各个实施例中，相同或类似的参考标号表示相同或类似的构件。

现有技术中的集中式架构的清算系统对高端设备依赖较强，业务连续性指标有待加强。集中式账户记账时所有清算账户数据均部署在主机节点上，清算系统收到交易系统提交的支付清算报文后，逐笔实时锁定借贷记账户，进行清算处理。如果可用头寸足够支付的立即做账务处理。可用头寸不足时，将该清算指令纳入清算排队处理，清算系统实时返回该清算回执报文，同一商业银行的所有清算报文串行处理。基于此，本发明创造性的通过采用开源事务框架tcc来协调借贷分离的分布式事务，实现以下关键要求：

1)支持应用分布式改造，实现横向可扩展。

2)解决借贷分离的分布式事务的最终一致性的问题，通过锁定业务金额，使用更小粒度的业务锁，提高账户资源的利用率，进一步提高清算效率，提高系统的处理性能。

3)提高业务连续性，通过分布式改造，可提高系统健壮性，部分节点故障时，保障业务连续性不受影响，同时避免了集中式架构依赖高端软硬件设备的弊端。

本发明遵循对参与者透明，维持清算处理对参与者外特性不变这一基本设计原则，将清算行的账户数据按照一定的规则分布到两个或两个以上的数据库实例上，如图17为本发明提供的具体实施例中账户数据分布置两个数据库实例的示意图。在本发明的一种实施方式中，可以按照哈希规则或自定义分片规则，将账户数据分布在两个或以上的数据库实例上。在业务进行处理之前需按照分片规则进行校验，当借贷记账户位于同一数据库实例时，直接路由至本地事务处理即可。

当清算业务中涉及到的两个账户在不同的数据库实例时，将产生分布式事务，清算这一过程需要跨数据库实例db1和数据库实例db2实现。为了保证借贷平衡，引用开源事务框架tcc，如图18为本发明的一个完整的tcc事务参与方的示意图，来解决事务的最终一致性。请参阅图18，一个完整的tcc事务参与方包含三个部分：

1)主业务服务，为整个支付业务事务的发起方；

2)从业务服务，负责提供tcc业务操作，是整个支付业务事务的操作方。从业务服务必须实现try、confirm和cancel三个接口，供主业务服务调用。由于confirm和cancel操作可能会被重复调用，故要求confirm和cancel两个接口是幂等的。

3)业务活动管理器，管理控制整个支付业务活动，包括记录和维护tcc全局事务的事务状态和每个从服务的子事务状态，并在业务活动提交时确认所有的tcc型操作的confirm操作，在业务活动取消时调用所有tcc型操作的cancel操作。

整个tcc事务对于主业务服务来说是透明的，其中业务活动管理器和从业务活动管理器分别执行部分事务。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。在本发明中，清算业务中涉及到的两个账户在不同的数据库实例时，产生了分布式事务。图1为本发明实施例提供的一种分布式记账系统的结构示意图，请参见图1，所述分布式记账系统包括主服务器100、事务管理器200、多个第一从服务器300以及第二从服务器400；

所述第一从服务器300以及第二从服务器400均包括try接口、confirm接口和cancel接口，所述confirm接口和所述cancel接口幂等；

所述主服务器100，用于根据一业务请求报文调用所述第一从服务器的try接口以及所述第二从服务器的try接口，所述业务请求报文对应的账户数据位于不同类型的从服务器的数据库实例中；

所述第一从服务器，用于根据账户合法性、账户状态以及可用余额输出第一try接口返回信息；

所述第二从服务器，用于根据账户合法性以及账户状态输出第二try接口返回信息；

所述事务管理器，用于根据所述第一try接口返回信息以及所述第二try接口返回信息调用所述第一从服务器以及所述第二从服务器，以实现与所述业务请求报文对应的业务。

在本发明中，从服务器可以拓展为第一从服务器、第二从服务器至多个从服务器。在具体的业务处理过程中，一个业务请求一般涉及多个从服务器，一个从服务器对应业务请求中功能相对集中的处理逻辑。

具体的，图2为本发明实施例提供的一种分布式记账系统中主服务器的实施方式一的结构示意图，请参阅图2，在实施方式一中主服务器100包括：

请求报文接收模块101，用于接收所述业务请求报文。

在具体的实施例中，业务请求报文可由交易系统输出，业务请求诸如为清算业务。

请求报文检查模块102，用于对所述业务请求报文的报文格式、业务合法性以及账户状态进行检查；

业务凭证记录模块103，用于当所述请求报文检查模块检查通过时，记录业务凭证；

服务接口调用模块104，用于当所述请求报文检查模块检查通过时，调用第一从服务器的try接口以及所述第二从服务器的try接口。

也即，在分布式事务处理中，主服务器在try阶段进行报文格式、业务合法性以及账户状态的检查，通过检查则记入业务凭证，并调用借记从服务的try接口、贷记从服务的try接口。

图3为本发明实施例提供的一种分布式记账系统中第一从服务器的结构示意图，请参阅图3，第一从服务器300包括：

第一账户检查模块301，用于对所述第一从服务器的账户合法性、账户状态以及可用余额进行检查；

业务金额冻结模块302，用于当所述第一账户检查模块检查通过时，根据所述可用余额冻结业务金额；

第一信息输出模块303，用于根据所述第一账户检查模块以及所述业务金额冻结模块输出第一try接口返回信息。图4为第一信息输出模块的结构示意图，请参阅图4，第一信息输出模块303包括：

接口正常输出模块3031，用于当所述业务金额冻结模块冻结业务金额成功时输出try接口正常的第一try接口返回信息；

接口异常输出模块3032，用于当所述第一账户检查模块检查未通过或所述业务金额冻结模块冻结业务金额失败时输出try接口异常的第一try接口返回信息。

也即，第一从服务器在try阶段，根据检查账户合法性、账户状态以及可用余额的检查结果结合可用余额冻结业务金额的冻结结果输出try接口正常或输出try接口异常的第一try接口返回信息。

图5为本发明实施例提供的一种分布式记账系统中第二从服务器的结构示意图，请参阅图5，第二从服务器400包括：

第二账户检查模块401，用于对所述第二从服务器的账户合法性以及账户状态进行检查；

第二信息输出模块402，用于当所述第二账户检查模块检查未通过时输出所述第二从服务器的try接口异常的第二try接口返回信息，当所述第二账户检查模块检查通过时输出所述第二从服务器的try接口正常的第二try接口返回信息。

也即，第二从服务器在try阶段，根据检查账户合法性以及账户状态的检查结果输出try接口正常或输出try接口异常的第二try接口返回信息。

图6为本发明实施例提供的一种分布式记账系统中事务管理器的结构示意图，请参阅图6，事务管理器200包括：

返回信息接收模块201，用于接收所述第一try接口返回信息以及所述第二try接口返回信息；

返回信息解析模块202，用于解析所述第一try接口返回信息以及所述第二try接口返回信息得到解析结果；

第一接口调用模块203，用于当所述解析结果显示所述第一try接口返回信息的try接口正常以及所述第二try接口返回信息的try接口正常时，调用所述第一从服务器的confirm接口以及所述第二从服务器的confirm接口；

第二接口调用模块204，用于当所述解析结果显示所述第一try接口返回信息的try接口异常和/或所述第二try接口返回信息的try接口异常时，调用所述第一从服务器的cancel接口以及所述第二从服务器的cancel接口。

也即，当第一服务器以及第二服务器的try接口均返回接口正常时，事务管理器均会触发第一服务器以及第二服务器的confirm接口。在该实施方式中，第一从服务器300，还用于通过confirm接口对所述账户余额进行扣减，对冻结的业务金额进行释放并记录账务明细；

第二从服务器400，还用于通过confirm接口对所述账户余额进行增加并记录账务明细。

如图7所示，在该实施方式中主服务器还包括：

第一凭证更新模块105，用于当所述解析结果显示所述第一try接口返回信息的try接口正常以及所述第二try接口返回信息的try接口正常时，将所述业务凭证更新为业务状态为已清算。

当第一服务器以及第二服务器的任何一个try接口返回接口异常时，事务管理器均会触发第一服务器以及第二服务器的cancel接口。在该实施方式中所述第一从服务器300，还用于当冻结业务金额成功时通过cancel接口对冻结金额进行释放；

所述第二从服务器400，还用于通过cancel接口针对try阶段事务幂等性回滚。

如图8所示，在该实施方式中主服务器还包括：

第二凭证更新模块106，用于当所述解析结果显示所述第一try接口返回信息的try接口异常和/或所述第二try接口返回信息的try接口异常时，将所述业务凭证更新为业务状态为已失败。

由于账户数据分布在两个或多个数据库实例上，当单个数据库实例出现故障时，另一个数据库实例仍然可以处理清算业务，保障了业务的连续性不受影响。

如上即为本发明实施例提供的一种分布式记账系统，其基于借贷分离实现分布式记账，分散风险，进一步缓解热点账户问题，应用tcc技术实现借贷分离的支付清算业务处理流程，借助基于tcc的应用层分布式事务，实现支付清算账户数据的最终一致性。

此外，尽管在上文详细描述中提及了系统的若干单元模块，但是这种划分仅仅并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。同样，上文描述的一个单元的特征和功能也可以进一步划分为由多个单元来具体化。以上所使用的术语“模块”和“单元”，可以是实现预定功能的软件和/或硬件。尽管以下实施例所描述的模块较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

在介绍了本发明示例性实施方式的分布式记账系统之后，接下来，参考附图对本发明示例性实施方式的方法进行介绍。该方法的实施可以参见上述整体的实施，重复之处不再赘述。

图8为本发明实施例提供的一种分布式记账方法的流程示意图，请参见图8，所述分布式记账方法包括：

s101：主服务器100根据一业务请求报文调用所述第一从服务器的try接口以及所述第二从服务器的try接口，所述业务请求报文对应的账户数据位于不同类型的从服务器的数据库实例中；

s102：所第一从服务器根据账户合法性、账户状态以及可用余额输出第一try接口返回信息；

s103：第二从服务器根据账户合法性以及账户状态输出第二try接口返回信息；

s104：所述事务管理器根据所述第一try接口返回信息以及所述第二try接口返回信息调用所述第一从服务器以及所述第二从服务器，以实现与所述业务请求报文对应的业务。

在本发明中，从服务器可以拓展为第一从服务器、第二从服务器至多个从服务器。在具体的业务处理过程中，一个业务请求一般涉及多个从服务器，一个从服务器对应业务请求中功能相对集中的处理逻辑。

图9为步骤s101的具体流程示意图，请参阅图9，步骤s101包括：

s201：主服务器接收所述业务请求报文。

在具体的实施例中，业务请求报文可由交易系统输出，业务请求诸如为清算业务。

s202：对所述业务请求报文的报文格式、业务合法性以及账户状态进行检查；

s203：当检查通过时，记录业务凭证；

s204：调用第一从服务器的try接口以及所述第二从服务器的try接口。

也即，在分布式事务处理中，主服务器在try阶段进行报文格式、业务合法性以及账户装置的检查，通过检查则记入业务凭证，并调用借记从服务的的try接口、贷记从服务的try接口。

图10为步骤s102的具体流程示意图，请参阅图10，步骤s102包括：

s301：第一从服务器对所述第一从服务器的账户合法性、账户状态以及可用余额进行检查，得到检查结果；

s302：当所述检查结果显示检查通过时，根据所述可用余额冻结业务金额，得到冻结结果；

s303：根据所述检查结果以及所述冻结结果输出第一try接口返回信息。图11为步骤s203的具体流程示意图，请参阅图11，步骤s203包括：

s401：第一从服务器判断检查结果是否显示检查通过，当判断为是时，执行步骤s402，否则执行步骤s404；

s402：判断冻结结果是否显示冻结业务金额成功，当判断为是时，执行步骤s403，否则执行步骤s404；

s403：输出try接口正常的第一try接口返回信息；

s404：输出try接口异常的第一try接口返回信息。

也即，第一从服务器在try阶段，根据检查账户合法性、账户状态以及可用余额的检查结果结合可用余额冻结业务金额的冻结结果输出try接口正常或输出try接口异常的第一try接口返回信息。

图12为步骤s103的具体流程示意图，请参阅图12，该步骤包括：

s501：第二从服务器对所述第二从服务器的账户合法性以及账户状态进行检查；

s502：判断检查是否通过，当判断为是时，执行步骤s503，否则执行步骤s504；

s503：输出所述第二从服务器的try接口正常的第二try接口返回信息；

s504：输出所述第二从服务器的try接口异常的第二try接口返回信息。

也即，第二从服务器在try阶段，根据检查账户合法性以及账户状态的检查结果输出try接口正常或输出try接口异常的第二try接口返回信息。

图13为步骤s104的具体流程示意图，请参阅图13，该步骤包括：

s601：事务管理器接收所述第一try接口返回信息以及所述第二try接口返回信息；

s602：解析所述第一try接口返回信息以及所述第二try接口返回信息得到解析结果；

s603：当所述解析结果显示所述第一try接口返回信息的try接口正常以及所述第二try接口返回信息的try接口正常时，调用所述第一从服务器的confirm接口以及所述第二从服务器的confirm接口；

s604：当所述解析结果显示所述第一try接口返回信息的try接口异常和/或所述第二try接口返回信息的try接口异常时，调用所述第一从服务器的cancel接口以及所述第二从服务器的cancel接口。

也即，当第一服务器以及第二服务器的try接口均返回接口正常时，事务管理器均会触发第一服务器以及第二服务器的confirm接口。在该实施方式中，如图14所示，该方法还包括：

s701：第一从服务器通过confirm接口对所述账户余额进行扣减，对冻结的业务金额进行释放并记录账务明细；

s702：第二从服务器通过confirm接口对所述账户余额进行增加并记录账务明细。

s703：主服务器将所述业务凭证更新为业务状态为已清算。

当第一服务器以及第二服务器的任何一个try接口返回接口异常时，事务管理器均会触发第一服务器以及第二服务器的cancel接口。如图15所示，该方法还包括：

s801：当冻结业务金额成功时，第一从服务器通过cancel接口对冻结金额进行释放；

s802：第二从服务器通过cancel接口针对try阶段事务幂等性回滚。

s803：主服务器将所述业务凭证更新为业务状态为已失败。

由于账户数据分布在两个或多个数据库实例上，当单个数据库实例出现故障时，另一个数据库实例仍然可以处理清算业务，保障了业务的连续性不受影响。

如上即为本发明实施例提供的一种分布式记账方法，其基于借贷分离实现分布式记账，分散风险，进一步缓解热点账户问题，应用tcc技术实现借贷分离的支付清算业务处理流程，借助基于tcc的应用层分布式事务，实现支付清算账户数据的最终一致性。

本发明还提供一种计算机设备，包括：适于实现各指令的处理器以及存储设备，所述存储设备存储有多条指令，所述指令适于由处理器加载并执行一种分布式记账方法。

本发明还提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序用于执行一种分布式记账方法。

下面结合具体的实施例，详细介绍本发明的技术方案。将清算账户从一个实例按照一定规则水平拆分到多个数据库实例上后，当借贷记业务或清算业务发起时，应首先检查业务中所涉及到的清算账户是否在同一实例上。若所涉及到的两个清算账户位于两个不同的实例，路由到分布式事务处理模块运用基于借贷分离的分布式记账策略进行处理。图19为本发明提供的实施例1中业务处理的流程示意图，请参阅图19，在实施例1中：

(1)判断该笔业务涉及的借贷双方清算账户是否在同一个实例上，将报文发送至分布式事务主业务服务器处理；

(2)主业务服务器对清算报文进行报文格式、业务合法性、账户状态等进行检查，检查通过记入业务凭证表，发起借记服务，调用借记try接口，锁定交易金额；

(3)发起贷记服务，调用贷记try接口；

(4)借贷记try接口返回成功，主服务confirm接口更新业务凭证表业务状态为已清算，调用借记confirm接口扣减账户金额，恢复冻结金额；借贷记接口返回异常，主服务cancel接口更新业务凭证表状态为已排队，并纳入排队表，调用借记cancel服务，恢复冻结金额，更新借记业务状态为已失败。

(5)借贷记try接口返回成功，调用贷记confirm接口增加账户金额；借贷记try接口返回异常，调用贷记cancel接口，更新贷记业务状态已失败。

在在分布式事务处理流程中依托tcc框架来控制事务的最终一致性。事务发起时，生成事务的全局id，初始化根事务(主业务服务)和分支事务(借贷记服务)的事务状态记录在业务活动日志中。根事务或分支事务发生改变时，反馈到事务管理器更新事务状态。

图20是本发明提供的实施例2中业务处理的流程示意图，请参阅图20，在实施例2中：

业务申请阶段发起清算业务；

事务分发阶段，当清算行是否位于同一数据库实例时，由本地事务进行清算；

当清算行位于不同实例时，由分布式事务进行处理。

在事务处理阶段，分布式主服务器首先记录业务凭证，调用分布式从服务器1的借记try服务、分布式从服务器2的贷记try服务。在事务try阶段，从服务器1借记账户合法性、状态、可用余额检查，检查通过时冻结业务金额；从服务器2贷记账户合法性、状态检查。当借记贷try服务返回成功时，启动事务confirm阶段，否则启动事务cancel阶段。

在事务confirm阶段，分布式主服务器更新业务状态为已清算，从服务器1借记账户扣减余额，释放冻结金额，记录账户明细，从服务器2贷记账户增加账户余额，记录账户明细。

在事务cancel阶段，分布式主服务器更新业务状态为已拒绝，从服务器1如果该笔业务已冻结业务金额，释放，从服务器2针对try阶段事务幂等性回滚。

综上所述，本发明实施例提供了一种分布式记账方法、分布式记账系统、计算机设备以及计算机可读存储介质，基于借贷分离实现分布式记账，分散风险，进一步缓解热点账户问题，应用tcc技术实现借贷分离的支付清算业务处理流程，借助基于tcc的应用层分布式事务，实现支付清算账户数据的最终一致性。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现客户端和服务器以外，完全可以通过将方法步骤进行逻辑编程来使得客户端和服务器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种客户端和服务器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施方式或者实施方式的某些部分所述的方法。

本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其他实施方式的不同之处。尤其，针对客户端和服务器的实施方式来说，均可以参照前述方法的实施方式的介绍对照解释。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施方式描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。