一种分布式事务处理方法、装置、介质和设备与流程

1.本公开涉及计算机技术领域，特别涉及一种分布式事务处理方法、装置、介质和设备。


背景技术：

2.本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.随着业务需求和架构的变化，软件系统从单体应用发展到分布式系统后，通过将软件系统拆分成微服务，实现了系统容量的可伸缩性。将全局事务划分成若干个领域的分支事务，每个服务内部的数据一致性可由本地分支事务来保证。但由于网络丢包、硬件损坏、依赖超时等物理环境的复杂性，局部网络问题发生时，必然会对系统全局事务的一致性、可用性造成影响。
4.在base理论的基础上，为满足分布式系统柔性事务中数据的一致性，方法论层面的支持包括两阶段提交协议(2pc协议)、三阶段提交协议(3pc协议)、分布式事务标准协议(xa协议)和尝试、确认或撤销协议(tcc协议)。同时业界也提出了一些分布式事务解决方案，例如seata、lotter等，一般可以采用上述解决方案应用于软件系统中。
5.seata是一款开源的分布式事务解决方案，提供简单易用的分布式事务服务，一般可采用seata txc模式。seata txc模式是基于两阶段提交模式设计的，解决了微服务场景下面临的分布式事务问题。但缺点是需要在业务中引入的seata客户端通过netty实现与协调者(tc模块)的通信，存在网络输入输出(io)延迟，且由于seata txc模式是基于两阶段提交模式的，因此存在易发生同步阻塞、协调者单点故障、脑裂的问题，且协调者在第二阶段处理过程中，一旦发生故障则无法继续处理，资源无法得到释放。
6.lottor基于可靠性消息事务模型实现，采用中心化服务调度的思想。优点在于利用服务器集中管理分布式事务，便于排查问题。但缺点是网络io多，容易出现性能瓶颈，且业务方(包括生产方和消费方)需强依赖消息组件、因此须有完善的降级策略，业务方接入服务器需要先回查本地事务状态的逻辑，接入复杂性较高，只适用于业务量较小的场景。
7.因此，亟需提供一种高性能的分布式事务处理方案，至少解决上述提及的seata和lotter分布式事务解决方案存在的问题。


技术实现要素：

8.本公开实施例提供一种分布式事务处理方法、装置、介质和设备，用于解决目前的分布式事务处理方案性能较差的问题。
9.第一方面，本公开提供了一种分布式事务处理方法，所述方法包括：
10.响应于分布式事务处理请求，调用所述分布式事务的每个分支事务的尝试阶段接口，根据每个分支事务尝试阶段接口的执行结果，更新预先生成的每个分支事务命令记录表，并更新预先生成的关联的全局事务命令记录表，所述分支事务命令记录表包括分支事
务对应的事务命令相关的配置和操作记录信息，所述全局事务命令记录表包括所述分布式事务对应的事务命令相关的配置和操作记录信息，且所述分支事务命令记录表和所述全局事务命令记录表保存在业务数据库中；
11.响应于每个分支事务尝试阶段接口的执行结果均为执行成功，根据所述分支事务命令记录表和所述全局事务命令记录表，确定所述分布式事务以及每个分支事务的状态，根据确定出的所述分布式事务以及每个分支事务的状态，实现对所述分布式事务确认阶段的处理；
12.响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，根据所述分支事务命令记录表和所述全局事务命令记录表，确定所述分布式事务以及每个分支事务的状态，根据确定出的所述分布式事务以及每个分支事务的状态，实现对所述分布式事务撤销阶段的处理。
13.在一种可能的实现方式中，响应于每个分支事务尝试阶段接口的执行结果均为执行成功，根据所述分支事务命令记录表和所述全局事务命令记录表，确定所述分布式事务以及每个分支事务的状态，根据确定出的所述分布式事务以及每个分支事务的状态，实现对所述分布式事务确认阶段的处理，包括：
14.响应于每个分支事务尝试阶段接口的执行结果均为执行成功，读取所述全局事务命令记录表，根据所述全局事务命令记录表，确定所述分布式事务是否达到第一指定状态；
15.响应于所述分布式事务未达到第一指定状态，读取关联的每个分支事务对应的分支事务命令记录表，根据所述分支事务命令记录表，确定未达到第一设定状态的分支事务；
16.针对每个未达到第一设定状态的分支事务，响应于到达该分支事务的调用时间，根据对应的分支事务命令记录表，确定对应的第一异步命令执行器的标识，所述第一异步命令执行器包括确认阶段接口，所述确认阶段接口用于执行指定的异步业务策略，实现确认阶段的操作；
17.根据确定出的所述第一异步命令执行器的标识，路由到对应的第一异步命令执行器，通过第一异步命令执行器包括的确认阶段接口执行指定的异步业务策略，并根据执行结果，更新对应的分支事务命令记录表；根据每个未达到第一设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表；
18.响应于到达设定时刻，返回执行读取所述全局事务命令记录表。
19.在一种可能的实现方式中，所述方法还包括：
20.通过创建的异步线程调用所述分布式事务的每个分支事务对应的确认阶段接口，所述异步线程为业务线程执行业务请求的过程中创建的；
21.根据每个分支事务对应的确认阶段接口的调用结果，更新所述全局事务命令记录表以及对应的分支事务命令记录表。
22.在一种可能的实现方式中，根据执行结果，更新对应的分支事务命令记录表；根据每个未达到第一设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表，包括：
23.响应于执行结果为异步业务策略执行成功，将对应的分支事务命令记录表中的分支事务状态更新为第二设定状态；响应于每个未达到第一设定状态的分支事务对应的执行结果均为异步业务策略执行成功，将所述全局事务命令记录表中包括的全局事务状态更新
为第二指定状态；
24.响应于至少一个未达到第一设定状态的分支事务对应的执行结果为异步业务策略执行失败，更新该分支事务对应的已调用次数和下次调用时间，响应于已调用次数达到第一阈值，将该分支事务对应的分支事务命令记录表中的分支事务状态更新为第三设定状态，并将所述全局事务命令记录表中的全局事务状态更新为第三指定状态。
25.在一种可能的实现方式中，响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，根据所述分支事务命令记录表和所述全局事务命令记录表，确定所述分布式事务以及每个分支事务的状态，根据确定出的所述分布式事务以及每个分支事务的状态，实现对所述分布式事务撤销阶段的处理，包括：
26.响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，读取所述全局事务命令记录表，根据所述全局事务命令记录表，确定所述分布式事务是否达到第四指定状态；
27.响应于所述分布式事务未达到第四指定状态，读取关联的每个分支事务对应的分支事务命令记录表，根据所述分支事务命令记录表，确定未达到第四设定状态的分支事务；
28.针对每个未达到第四设定状态的分支事务，响应于到达该分支事务的调用时间，根据对应的分支事务命令记录表，确定对应的第二异步命令执行器的标识，所述第二异步命令执行器包括撤销阶段接口，所述撤销阶段接口用于执行指定的异步业务策略，实现撤销阶段的操作；
29.根据确定出的所述第二异步命令执行器的标识，路由到对应的第二异步命令执行器，通过第二异步命令执行器包括的撤销阶段接口执行指定的异步业务策略，并根据执行结果，更新对应的分支事务命令记录表；根据每个未达到第四设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表；
30.响应于到达设定时刻，返回执行读取所述全局事务命令记录表。
31.在一种可能的实现方式中，所述方法还包括：
32.通过创建的异步线程调用所述分布式事务的每个分支事务对应的撤销阶段接口，所述异步线程为业务线程执行业务请求的过程中创建的；
33.根据每个分支事务对应的撤销阶段接口的调用结果，更新所述全局事务命令记录表以及对应的分支事务命令记录表。
34.在一种可能的实现方式中，根据执行结果，更新对应的分支事务命令记录表；以及，根据每个未达到第四设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表，包括：
35.响应于执行结果为异步业务策略执行成功，将对应的分支事务命令记录表中的分支事务状态更新为第五设定状态；响应于每个未达到第四设定状态的分支事务对应的执行结果均为异步业务策略执行成功，将所述全局事务命令记录表中包括的全局事务状态更新为第五指定状态；
36.响应于至少一个未达到第四设定状态的分支事务对应的执行结果为异步业务策略执行失败，更新该分支事务对应的已调用次数和下次调用时间，响应于已调用次数达到第二阈值，将该分支事务对应的分支事务命令记录表中的分支事务状态更新为第六设定状态，并将所述全局事务命令记录表中的全局事务状态更新为第六指定状态。
37.在一种可能的实现方式中，所述方法还包括：
38.响应于分支事务调用请求，读取所述分支事务对应的事务命令记录表，所述事务命令记录表包括事务命令相关的配置和操作记录信息，且所述事务命令记录表保存在业务数据库中；
39.根据所述事务命令记录表，确定所述分支事务的状态；
40.根据确定出的所述分支事务的状态，实现对所述分支事务的处理。
41.在一种可能的实现方式中，根据确定出的所述分支事务的状态，实现对所述分支事务的处理，包括：
42.响应于所述分支事务未达到特定状态，根据所述事务命令记录表，确定是否到达所述分支事务调用时间；
43.响应于到达所述分支事务调用时间，根据所述事务命令记录表，确定对应的第三异步命令执行器的标识，所述第三异步命令执行器用于执行指定的异步业务策略，实现分支事务的调用；
44.根据确定出的所述第三异步命令执行器的标识，路由到对应的第三异步命令执行器执行指定的异步业务策略，根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表，并响应于到达设定时刻，返回执行读取所述分支事务对应的事务命令记录表。
45.在一种可能的实现方式中，所述方法还包括：
46.通过创建的异步线程调用所述第三异步命令执行器，所述异步线程为业务线程执行业务请求的过程中创建的；
47.根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表。
48.在一种可能的实现方式中，根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表，包括：
49.响应于执行结果为异步业务策略执行成功，将所述事务命令记录表中的分支事务状态更新为第一状态；
50.响应于执行结果为异步业务策略执行失败，更新事务命令记录表中的已调用次数和下次调用时间，响应于已调用次数达到门限值，将事务命令记录表中的分支事务状态更新为第二状态。
51.第二方面，本公开还提供了一种分布式事务处理装置，所述装置包括：
52.尝试阶段接口调用模块，用于响应于分布式事务处理请求，调用所述分布式事务的每个分支事务的尝试阶段接口；
53.确认阶段接口调用模块，用于响应于每个分支事务尝试阶段接口的执行结果均为执行成功，根据所述分支事务命令记录表和所述全局事务命令记录表，确定所述分布式事务以及每个分支事务的状态，根据确定出的所述分布式事务以及每个分支事务的状态，实现对所述分布式事务确认阶段的处理；
54.撤销阶段接口调用模块，用于响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，根据所述分支事务命令记录表和所述全局事务命令记录表，确定所述分布式事务以及每个分支事务的状态，根据确定出的所述分布式事务以及每个分支事务的状态，实现对所述分布式事务撤销阶段的处理；
55.更新模块，用于根据每个分支事务尝试阶段接口的执行结果，更新预先生成的每
个分支事务命令记录表，并更新预先生成的关联的全局事务命令记录表；所述分支事务命令记录表包括分支事务对应的事务命令相关的配置和操作记录信息，所述全局事务命令记录表包括所述分布式事务对应的事务命令相关的配置和操作记录信息，且所述分支事务命令记录表和所述全局事务命令记录表保存在业务数据库中。
56.在一种可能的实现方式中，所述确认阶段接口调用模块，具体用于响应于每个分支事务尝试阶段接口的执行结果均为执行成功，读取所述全局事务命令记录表，根据所述全局事务命令记录表，确定所述分布式事务是否达到第一指定状态；
57.响应于所述分布式事务未达到第一指定状态，读取关联的每个分支事务对应的分支事务命令记录表，根据所述分支事务命令记录表，确定未达到第一设定状态的分支事务；
58.针对每个未达到第一设定状态的分支事务，响应于到达该分支事务的调用时间，根据对应的分支事务命令记录表，确定对应的第一异步命令执行器的标识，所述第一异步命令执行器包括确认阶段接口，所述确认阶段接口用于执行指定的异步业务策略，实现确认阶段的操作；
59.根据确定出的所述第一异步命令执行器的标识，路由到对应的第一异步命令执行器，通过第一异步命令执行器包括的确认阶段接口执行指定的异步业务策略；
60.响应于到达设定时刻，返回执行读取所述全局事务命令记录表；
61.所述更新模块，还用于根据所述第一异步命令执行器的执行结果，更新对应的分支事务命令记录表；根据每个未达到第一设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表。
62.在一种可能的实现方式中，所述装置还包括异步线程调用模块：
63.所述异步线程调用模块，用于通过创建的异步线程调用所述分布式事务的每个分支事务对应的确认阶段接口，所述异步线程为业务线程执行业务请求的过程中创建的；
64.所述更新模块，还用于根据每个分支事务对应的确认阶段接口的调用结果，更新所述全局事务命令记录表以及对应的分支事务命令记录表。
65.在一种可能的实现方式中，所述更新模块，根据所述第一异步命令执行器的执行结果，更新对应的分支事务命令记录表；根据每个未达到第一设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表，包括：
66.响应于所述第一异步命令执行器的执行结果为异步业务策略执行成功，将对应的分支事务命令记录表中的分支事务状态更新为第二设定状态；响应于每个未达到第一设定状态的分支事务对应的执行结果均为异步业务策略执行成功，将所述全局事务命令记录表中包括的全局事务状态更新为第二指定状态；
67.响应于至少一个未达到第一设定状态的分支事务对应的执行结果为异步业务策略执行失败，更新该分支事务对应的已调用次数和下次调用时间，响应于已调用次数达到第一阈值，将该分支事务对应的分支事务命令记录表中的分支事务状态更新为第三设定状态，并将所述全局事务命令记录表中的全局事务状态更新为第三指定状态。
68.在一种可能的实现方式中，所述撤销阶段接口调用模块，具体用于响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，读取所述全局事务命令记录表，根据所述全局事务命令记录表，确定所述分布式事务是否达到第四指定状态；
69.响应于所述分布式事务未达到第四指定状态，读取关联的每个分支事务对应的分
支事务命令记录表，根据所述分支事务命令记录表，确定未达到第四设定状态的分支事务；
70.针对每个未达到第四设定状态的分支事务，响应于到达该分支事务的调用时间，根据对应的分支事务命令记录表，确定对应的第二异步命令执行器的标识，所述第二异步命令执行器包括撤销阶段接口，所述撤销阶段接口用于执行指定的异步业务策略，实现撤销阶段的操作；
71.根据确定出的所述第二异步命令执行器的标识，路由到对应的第二异步命令执行器，通过第二异步命令执行器包括的撤销阶段接口执行指定的异步业务策略；
72.响应于到达设定时刻，返回执行读取所述全局事务命令记录表；
73.所述更新模块，还用于根据所述第二异步命令执行器的执行结果，更新对应的分支事务命令记录表；根据每个未达到第四设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表。
74.在一种可能的实现方式中，所述装置还包括异步线程调用模块：
75.所述异步线程调用模块，用于通过创建的异步线程调用所述分布式事务的每个分支事务对应的撤销阶段接口，所述异步线程为业务线程执行业务请求的过程中创建的；
76.所述更新模块，还用于根据每个分支事务对应的撤销阶段接口的调用结果，更新所述全局事务命令记录表以及对应的分支事务命令记录表。
77.在一种可能的实现方式中，所述更新模块，根据所述第二异步命令执行器的执行结果，更新对应的分支事务命令记录表；根据每个未达到第四设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表，包括：
78.响应于所述第二异步命令执行器的执行结果为异步业务策略执行成功，将对应的分支事务命令记录表中的分支事务状态更新为第五设定状态；响应于每个未达到第四设定状态的分支事务对应的执行结果均为异步业务策略执行成功，将所述全局事务命令记录表中包括的全局事务状态更新为第五指定状态；
79.响应于至少一个未达到第四设定状态的分支事务对应的执行结果为异步业务策略执行失败，更新该分支事务对应的已调用次数和下次调用时间，响应于已调用次数达到第二阈值，将该分支事务对应的分支事务命令记录表中的分支事务状态更新为第六设定状态，并将所述全局事务命令记录表中的全局事务状态更新为第六指定状态。
80.在一种可能的实现方式中，所述装置还包括读取模块、状态确定模块和处理模块，其中：
81.所述读取模块，用于响应于分支事务调用请求，读取所述分支事务对应的事务命令记录表，所述事务命令记录表包括事务命令相关的配置和操作记录信息，且所述事务命令记录表保存在业务数据库中；
82.所述状态确定模块，用于根据所述事务命令记录表，确定所述分支事务的状态；
83.所述处理模块，用于根据确定出的所述分支事务的状态，实现对所述分支事务的处理。
84.在一种可能的实现方式中，所述处理模块，具体用于响应于所述分支事务未达到特定状态，根据所述事务命令记录表，确定是否到达所述分支事务调用时间；
85.响应于到达所述分支事务调用时间，根据所述事务命令记录表，确定对应的第三异步命令执行器的标识，所述第三异步命令执行器用于执行指定的异步业务策略，实现分
支事务的调用；
86.根据确定出的所述第三异步命令执行器的标识，路由到对应的第三异步命令执行器执行指定的异步业务策略，根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表，并响应于到达设定时刻，返回执行读取所述分支事务对应的事务命令记录表。
87.在一种可能的实现方式中，所述装置还包括异步线程调用模块：
88.所述异步线程调用模块，用于通过创建的异步线程调用所述第三异步命令执行器，所述异步线程为业务线程执行业务请求的过程中创建的；根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表。
89.在一种可能的实现方式中，所述处理模块，根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表，包括：
90.响应于执行结果为异步业务策略执行成功，将所述事务命令记录表中的分支事务状态更新为第一状态；
91.响应于执行结果为异步业务策略执行失败，更新事务命令记录表中的已调用次数和下次调用时间，响应于已调用次数达到门限值，将事务命令记录表中的分支事务状态更新为第二状态。
92.第三方面，本公开还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有可执行程序，该可执行程序被处理器执行实现如上所述的方法。
93.第四方面，本公开还提供了一种分布式事务处理设备，包括处理器、通信接口、存储器和通信总线，其中，所述处理器，所述通信接口，所述存储器通过所述通信总线完成相互间的通信；
94.所述存储器，用于存放计算机程序；
95.所述处理器，用于执行所述存储器上所存储的程序时，实现如上所述的方法步骤。
96.根据本公开实施例提供的方案，可以在接收到分布式事务处理请求时，基于tcc协议来实现分布式事务处理。在处理过程中，可以基于保存在业务数据库中的分支事务命令记录表和全局事务命令记录表，来实现对应的事务命令相关的配置和操作记录信息的保存，进而可以根据每个分支事务尝试阶段接口的执行结果，以及根据分支事务命令记录表和全局事务命令记录表，确定出的分布式事务以及每个分支事务的状态，实现对分布式事务确认阶段和撤销阶段的处理，从而实现分布式事务处理。
97.即，根据本公开实施例提供的方案，可以通过设置分支事务命令记录表和全局事务命令记录表，来实现分布式事务处理。而由于分支事务命令记录表和全局事务命令记录表，与业务数据保存在同一个数据库中，可以基于同库协调的方式实现分布式事务处理，有效减少了网络io，从而有效提升系统性能。
98.本公开的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本公开而了解。本公开的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
99.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本
公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
100.图1为本公开实施例提供的seata模块设计的结构示意图；
101.图2为本公开实施例提供的lotter模块设计的结构示意图；
102.图3为本公开实施例提供的异步重试确保模型的结构示意图；
103.图4为本公开实施例提供的异步命令执行器的实现过程示意图；
104.图5为本公开实施例提供的事务命令记录表ddl示例示意图；
105.图6为本公开实施例提供的分布式事务处理方法的流程示意图；
106.图7为本公开实施例提供的基于同库协调的tcc模型的结构示意图；
107.图8(a)～图8(b)为本公开实施例提供的全局事务命令记录表和分支事务命令记录表的示意图；
108.图9为本公开实施例提供的分布式事务处理流程示意图；
109.图10为本公开实施例提供的分布式事务处理方法的流程示意图；
110.图11为本公开实施例提供的分布式事务处理装置的结构示意图；
111.图12为本公开实施例提供的分布式事务处理设备的结构示意图。
具体实施方式
112.为了使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开作进一步地详细描述，显然，所描述的实施例仅仅是本公开的一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
113.需要说明的是，在本文中提及的“多个或者若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
114.本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。
115.此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
116.为了便于了解seata、lotter以及本公开方案，下面对几个概念进行简单说明。
117.cap：指的是在一个分布式系统中的一致性(consistency)、可用性(availability)和分区容错性(partition tolerance)。而cap原则指的是，在一个分布式系统中，上述三个要素最多只能同时实现两点，不可能三者兼顾。根据cap理论，分布式系统要继续提供服务，必须实现分区容错性，在部分对可用性要求比较严格的场景下，无法保证数据的强一致性；
118.一致性：可以理解为分布式系统中多个数据副本之间能够保持一致的特性；
119.可用性：可以理解为分布式系统对于用户的请求能够在有限时间内返回结果的特性；
120.分区容错性：可以理解为出现局部的网络故障时，分布式系统仍然可以对外提供服务，满足可用性，并保持一致性；
121.base：包括基本可用(basically available)、柔性状态(soft state)和最终一致性(eventual consistency)。base理论是对cap理论的延伸，是对cap中一致性和可用性进行权衡的结果，base理论的核心思想就是：分布式系统无法做到数据的强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。对于大多数要求高可用、高性能的业务应用场景，遵循base理论的柔性事务是最佳的选择，分布式系统放弃事务隔离性、减小事务中锁的力度，使得应用能够更好地利用资源层的并发性能，实现吞吐量的线性扩展。且异步执行方式可更好地适应分布式环境，在局部网络抖动、故障情况下尽量保证系统可用性，对全局事务中的数据一致性要求适当放宽，达到最终一致性即可。
122.基于2pc协议的两阶段提交模式：是分布式事务参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是提交操作还是中止操作；
123.基于3pc协议的三阶段提交模式：是两阶段提交模式的改进版本，在两阶段提交模式的基础上引入了超时机制，并新增了准备阶段；
124.基于xa协议的xa模式：是基于资源层的底层分布式事务解决方案，本质上属于两阶段提交模式；
125.基于tcc协议的tcc模式：是对两阶段提交模式的一种改进，针对每个分支事务，都要注册一个与其对应的确认和撤销(补偿)操作，避免同步阻塞资源的情况。
126.下面对seata txc模式下的分布式事务解决方案进行简单说明。
127.seata txc模式又称为seata at模式，可以理解为补偿方法是框架自动生成的，对用户完全屏蔽，用户可以像使用本地事务那样使用分布式事务。缺点是仅支持关系型数据库(目前支持mysql)，引入seata at的服务需要本地建表存储回滚信息(rollback_info)，隔离级别默认为未提交读(ru)级别，适用场景有限。
128.seata解决方案上将整体分成三个大模块，即全局事务管理器(tm，transaction manager)、资源管理器(rm，resource manager)和事务协调器(tc，transaction coordinator)，模块设计的结构示意图可以如图1所示，具体解释如下：
129.tm：控制全局事务边界，负责全局事务开启、全局事务提交、全局事务回滚。
130.rm：控制分支事务，负责分支事务注册、状态汇报，并接收事务协调器的指令，驱动分支(本地)事务的提交和回滚。
131.tc：维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
132.seata txc模式具体包括如下两个阶段：
133.阶段1：分支(本地)事务执行。可以将一个本地事务作为一个分布式事务分支，若干个分布在不同微服务中的本地事务共同组成了一个全局事务。
134.阶段2：分支事务提交或回滚。阶段2完成的是全局事务的最终提交或回滚，当全局事务中所有分支事务全部完成并且都执行成功，这时tm会发起全局事务提交，tc收到全局事务提交消息后，会通知各rm，对分支事务进行提交；同理，当全局事务中所有分支事务全
部完成并且某个分支事务失败了，tm会通知tc协调全局事务回滚，进而tc通知各rm，对分支事务进行回滚。
135.下面对分布式事务解决方案lotter进行简单说明。
136.lottor基于可靠性消息事务模型，解决微服务架构下分布式事务的问题。分布式事务解决方案lotter的模块设计的结构示意图可以如图2所示，包括lottor服务器(lottor server)与客户端(包括生产方客户端和消费方客户端)，在lotter解决方案中，所有的服务都会注册到管理中心(consul)。
137.lottor服务器与客户端之间的通信使用高性能通信框架netty，且所有的客户端都会与服务器保持长连接。lottor服务器用户界面(ui)可以展示系统中的事务组详细信息，包括预提交的事务组、消费失败的事务消息，并支持展示页面操作失败的消息(如补偿或重试)。其中：
138.1)生产方客户端主要用于：
139.发送预发送消息：生产方客户端首先会将消费方客户端的事务组(一条或多条事务消息)组装好，并发送到lottor server，事务消息的状态为预发送(pre
‑
commit)。
140.执行本地事务：生产方客户端预发送事务消息之后，将会执行本地事务。
141.发送确认消息：生产方客户端可以根据本地事务的执行结果，异步发送确认消息。如果本地事务执行成功，发送成功消息，如果本地事务执行出现异常，回滚本地事务，并将失败消息与捕捉到的异常信息一起发送到lottor server。
142.2)lottor server主要用于：
143.接收预发送消息：lottor server收到预发送消息，将事务组中的事务消息分别保存，状态为pre
‑
commit。
144.接收确认消息：如果lottor server收到成功消息，更改相应的事务组中各事务消息的状态为confirm，并将成功消息发送到对应的消费方客户端(通过消息队列(mq)异步实现)，并标记各事务消息的状态为unconsumed。如果lottor server收到失败消息，则只会修改事务组状态为异常。
145.回查预发送消息的状态：针对各事务消息状态为pre
‑
commit的事务组，lottor server将会定期回查生产方客户端。
146.回查事务消息的状态：针对各事务消息状态为异常的事务组，lottor server将会定期(一般为每4小时)回查消费方客户端。
147.执行本地事务：接收预发送消息之后，lottor server将会执行本地事务。
148.3)消费方客户端主要用于：
149.接收事务消息：消费方客户端可以订阅相关的主题，并接收对应的事务消息。且消费方客户端消费完成之后，可以异步发送消费成功响应(ack)给lottor server，消费失败会将消费异常响应返回给lottor server。
150.鉴于目前的分布式事务处理方案性能较差的问题，本公开提供一种通用事务服务(rts，general transaction service)，其属于解决分布式事务数据一致性问题的通用框架。其实现可以是基于应用层的，总体思路是采用重试、幂等的机制保证数据的最终一致性，属于柔性事务范畴，可以由内嵌组件化的协调者去保证异步调度执行。本公开方案包含两种模型：一种可以记为异步重试确保模型，其利用重试、幂等的机制保证数据最终一致；
另一种可以记为基于同库协调的tcc模型，其通过事务协调管理组件的协调，以异步重试确保模型作为基础来完成分支事务的最终提交。
151.本公开方案包含的异步重试确保模型的结构示意图可以如图3所示。图3对应的应用场景可以理解为，在业务链路中，上游服务a调用下游服务b，服务b需要做状态变更，服务a维护的数据状态需要与服务b维护的数据状态保证最终一致性。
152.在如图3所示的模型中，服务a(可以记为调用方)中的业务线程在接收到业务请求后，可以执行业务，并可以在本地业务数据库(可以记为db)中创建一个针对服务b的事务命令记录表。部署在服务a中的事务协调管理组件，响应于服务b调用请求，可以定时读取该事务命令记录表，确定服务b是否达到特定状态，若确定服务b未达到特定状态，且确定到达服务b调用时间，则可以根据该事务命令记录表中记录的异步命令执行器的标识，路由到对应的异步命令执行器执行指定的异步业务策略，实现对服务b的调用，并根据对服务b的调用结果，更新该事务命令记录表。
153.即对于无需立即调用的分支事务，可以通过事务协调管理组件，实现分支事务的延迟执行和重试(可以理解为重新尝试执行)。
154.另外，服务a中的业务线程也可以在执行业务的过程中，根据其中的事务命令，创建异步线程，立即调用与服务b对应的异步命令执行器，实现对服务b的调用，并根据对服务b的调用结果，更新在业务数据库中保存的服务b对应的事务命令记录表。
155.此时进一步的，部署在服务a中的事务协调管理组件，可以基于重试机制，定时读取该事务命令记录表，确定服务b是否达到特定状态，若确定服务b未达到特定状态，且确定到达服务b调用时间，则可以根据该事务命令记录表中记录的异步命令执行器的标识，路由到对应的异步命令执行器执行指定的异步业务策略，实现对服务b的调用，并根据对服务b的调用结果，更新该事务命令记录表。
156.即对于需要立即调用的分支事务，可以通过异步线程，实现分支事务的立即执行，并可以通过事务协调管理组件，对于首次执行失败的分支事务，实现分支事务的重试。
157.图3对应的常见应用场景可以但不限于包括，交易链路中的数据统计、数据库的读缓存更新、收到支付回调后的履约状态更新等等。
158.异步命令执行器的实现过程可以如图4所示，在本公开方案中，可以提供通用的抽象类(例如，如图4所示，抽象类可以记为dowork()以及execute())，调用方需继承抽象类，以获得异步命令执行器实现类(例如，如图4所示，实现类可以记为executor 1、executor 2和executor n)。获得异步命令执行器实现类后，可以实例化后，注册至rts容器中的执行器注册表中，进而调用方可以根据需要执行的业务策略，调用执行器缓存池中缓存的实现类，从而实现特定场景的异步命令执行逻辑(例如异步推送私信等)，保证依赖幂等。
159.异步命令的执行逻辑，可以修改直接依赖的资源(例如，数据库、缓存、消息等)的状态，并可以修改间接依赖的资源(例如，系统微服务接口(如履约服务、对账服务)、第三方服务(如即时通信(im)服务、支付宝、微信)等)的状态。
160.另外，在本公开方案中，可以配置与业务数据同库的关系型数据库，用于实现业务调度过程中事务命令的存储、查询和修改等。通过与业务数据同库保存事务命令，减少网络io，提升系统性能。系统性能取决于业务数据库的写入能力，并可以保证本地事务的原子性。在该关系型数据库中创建的事务命令记录表，其表结构的数据定义语言(ddl)示例可以
如图5所示。
161.事务命令记录表(可以记为mts_asyn_command)包括事务命令相关的配置和操作记录信息，可以用于记录异步命令。在如图5所示的示例中，事务命令记录表中可以包括分支事务的状态信息、执行策略以及业务隔离信息等。
162.事务命令记录表中包括的分支事务的状态信息的各字段、描述和作用可以如表1所示。
163.表1
[0164][0165]
事务命令记录表中包括的分支事务的执行策略的各字段、描述和作用可以如表2所示。
[0166]
表2
[0167]
字段描述作用asynexecutorname异步命令执行器标识用以调度此前实例化并注册至容器的异步业务逻辑nextexecutetime下次执行时间下次重试的具体时刻maxlimittimes最大重试次数配置截止次数，避免无限次重试retrvtimes已重试次数累加重试次数strategy时间策略可以采用cron表达式，可定制重试频率、时间间隔
[0168]
事务命令记录表中包括的分支事务的业务隔离信息的各字段、描述和作用可以如表3所示。
[0169]
表3
[0170][0171]
需要说明的是，在事务命令记录表中，分支事务状态可以包括初始化、处理中、已完成和执行失败，且需要保证分支事务状态最终达到终态，即已完成或执行失败。
[0172]
另外需要指出的是，通过事务命令记录表的设计，可以有效支持针对分支事务的配置化，可以根据分支事务的需求来定制相关参数，例如，最大重试次数，时间策略等。
[0173]
结合上述事务命令记录表的设计示例，可以理解为，在异步重试确保模型中，调用方在事务中插入事务命令后，业务线程可选择通过创建新的异步线程，立即执行异步命令完成分支事务调度。这种调度模式不依赖于定时调度的周期，可以尽可能地缩短事务中数据不一致的时间。需要说明的是，rts可以提供异步线程池的初始化，复用异步线程的链接，避免多次创建线程带来的性能损耗。
[0174]
而对于无需立即执行或首次执行失败后的分支事务，rts可以通过配置定时重试任务，定期扫描业务数据库中的事务命令记录表，捞出未达终态，并已达重试时间的分支事
务，根据事务命令记录表中记录的异步命令执行器标识(asynexecutorname)路由到异步命令执行器执行业务逻辑。执行成功则更新分支事务状态至成功，执行失败则可以根据重试策略，更新下次执行时间、重试次数，如果达到最大重试次数，仍未执行成功，则可以更新分支事务状态至执行失败，并可以予以报警，以便于进行人工排查兜底。
[0175]
在一种可能的实现方式中，定时重试任务可以通过springboot的定时任务组件、或定时任务框架quartz实现分支事务调度。其中，可以根据事务命令记录表中索引，基于创建异步命令时配置的下次执行时间、分支事务状态、分片信息、调用业务名称来捞取未达终态，并已达重试时间的分支事务。
[0176]
基于异步重试确保模型，本公开提供一种分布式事务处理方法，该方法可以应用于调用方，步骤流程可以如图6所示，包括：
[0177]
步骤101、响应于分支事务调用请求，读取分支事务对应的事务命令记录表。
[0178]
在本步骤中，可以根据分支事务调用请求，来读取分支事务对应的事务命令记录表。事务命令记录表可以理解为包括事务命令相关的配置和操作记录信息，且事务命令记录表保存在业务数据库中，与业务数据实现同库保存，使得对事务命令记录表的操作，可以像操作业务数据一样，基于本地业务数据库来实现，无需通过网络io实现，避免通过网络io来实现分布式事务导致的系统性能较差的问题。
[0179]
步骤102、根据事务命令记录表，确定分支事务的状态。
[0180]
可以理解为，根据包括事务命令相关的配置和操作记录信息的事务命令记录表，可以确定分支事务的状态。
[0181]
分支事务的状态可以但不限于包括分支事务尚未被开始执行信息(事务命令记录表中记录的分支事务状态信息可以但不限于为初始化，即可以但不限于用初始化表示该状态)、分支事务正在被执行中(事务命令记录表中记录的分支事务状态信息可以但不限于为处理中，即可以但不限于用处理中表示该状态)，分支事务执行成功(事务命令记录表中记录的分支事务状态信息可以但不限于为已完成，即可以但不限于用已完成表示该状态)和分支事务执行失败(事务命令记录表中记录的分支事务状态信息可以但不限于为执行失败，即可以但不限于用执行失败表示该状态)等等。
[0182]
步骤103、根据确定出的分支事务的状态，实现对分支事务的处理。
[0183]
在本步骤中，为了提高分布式事务处理的成功率，在一种可能的实现方式中，可以但不限于基于重试机制，来执行分支事务。
[0184]
进一步的，在一种可能的实现方式中，可以但不限于通过以下方式，来执行分支事务：
[0185]
响应于分支事务未达到特定状态(例如，已完成或执行失败)，可以根据事务命令记录表，确定是否到达分支事务调用时间；
[0186]
响应于到达分支事务调用时间，根据事务命令记录表，确定对应的异步命令执行器的标识，异步命令执行器用于执行指定的异步业务策略，实现分支事务的调用；
[0187]
根据确定出的异步命令执行器的标识，路由到对应的异步命令执行器执行指定的异步业务策略，根据异步命令执行器的执行结果，更新事务命令记录表。
[0188]
并响应于满足一定条件，例如到达设定时刻，返回执行步骤101，读取分支事务对应的事务命令记录表。
[0189]
即在本步骤中，若分支事务未达到终态，且确定到达分支事务的调用时间，则可以通过对应的异步命令执行器，实现对该分支事务的调用，并更新事务命令记录表。进一步的，可以在满足一定条件，例如到达设定时刻时，执行步骤101，重新读取分支事务对应的事务命令记录表，再次确定分支事务是否达到终态，从而可以基于重试机制，使得分支事务最终可以达到终态。
[0190]
若分支事务未达到终态，并确定未到达分支事务的调用时间，则可以在满足一定条件，例如到达设定时刻时，执行步骤101，重新读取分支事务对应的事务命令记录表，再次确定是否到达分支事务的调用时间，从而可以基于重试机制，使得分支事务最终可以达到终态。
[0191]
而若分支事务已达到终态，则可以认为分支事务执行完毕，可以结束本流程。
[0192]
需要说明的是，除了可以基于异步重试机制，对于无需立即调用的分支事务，来实现分支事务的延迟执行和重试之外，响应于分支事务调用请求，在读取分支事务对应的事务命令记录表之前，还可以通过创建的异步线程调用上述异步命令执行器，来调用分支事务，异步线程为业务线程执行业务请求的过程中创建的，并根据异步命令执行器的执行结果，更新事务命令记录表。
[0193]
即，对于需要立即调用的分支事务，可以通过异步线程，实现分支事务的立即执行。且可以基于重试机制，对于通过异步线程首次执行失败的分支事务，实现分支事务的重试。
[0194]
需要进一步说明的是，通过异步线程调用异步命令执行器，或者，实现分支事务的延迟执行和重试的过程中，根据异步命令执行器的执行结果，更新事务命令记录表，可以包括：
[0195]
响应于执行结果为异步业务策略执行成功，将事务命令记录表中的分支事务状态更新为第一状态(例如，已完成)；
[0196]
响应于执行结果为异步业务策略执行失败，更新事务命令记录表中的已调用次数和下次调用时间，响应于已调用次数达到门限值，将事务命令记录表中的分支事务状态更新为第二状态(例如，执行失败)。
[0197]
分支事务的初始状态可以为第三状态(例如，初始化)，若执行结果为异步业务策略执行失败，在更新事务命令记录表中的已调用次数和下次调用时间的同时，也可以更新分支事务的状态为第四状态(例如，处理中)。
[0198]
可以理解为，异步重试确保模型提供重试机制，可以用于实现异步通知、业务重试兜底，适用于对数据一致性要求不高的场景。可实现无侵入、可配置、通用的异步重试通知，在事务切面处可定制个性化的异步命令，通过数据库持久化和调用方本地事务的原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)，即acid特性保证链路数据的最终一致性，并做到操作异步解耦。
[0199]
异步重试确保模型可以实现事务中非核心操作的异步解耦、以及关键逻辑的重试兜底策略。其除了可以解决普通的简单事务问题外，还可以作为基于同库协调的tcc模型的基础，实现事务第二阶段(确认阶段或撤销阶段)的异步重试，以保证对一致性要求较高的场景中，数据的最终一致性。
[0200]
基于同库协调的tcc模型可以理解为包括如下两个阶段：
[0201]
第一阶段：尝试阶段(可以记为try阶段)，通常用于锁定链路设计的资源，例如账户资金、库存等；
[0202]
第二阶段：确认阶段(可以记为confirm阶段)或撤销阶段(可以记为cancel阶段)。如果链路正常，则通过确认阶段，锁定资源提交，执行后续动作；如果链路出现异常，就需要通过撤销阶段，经回滚、释放等操作将锁定的资源进行释放。
[0203]
调用方只需要关心第一阶段的调用，以第一阶段的处理结果为准，每个链路分支中尝试阶段接口都执行成功才算成功，返回给上层调用方。第二阶段则可以交给部署的事务协调管理组件去处理。各参与方在接口幂等的情况下，以第一阶段的处理结果为准，事务协调管理组件通过异步重试机制保障第二阶段的最终一致性。
[0204]
本公开方案包含的基于同库协调的tcc模型的结构示意图可以如图7所示。图7对应的应用场景可以理解为，上游服务a同时调用服务b和服务c的情况下，服务b和服务c都需要做状态变更，服务a需要及时反馈给上层响应结果，服务a维护的数据状态需要与服务b、服务c维护的数据状态保证最终一致性。
[0205]
在如图7所示的模型中，服务a作为调用方，服务b和服务c作为参与方，其中，服务b可以记为参与方1，服务c可以记为参与方2。
[0206]
响应于分布式事务处理请求，调用方中的业务线程可以调用参与方1对应的尝试阶段接口以及参与方2对应的尝试阶段接口。并可以在本地业务数据库(可以记为db)中创建针对参与方1的分支事务命令记录表1，针对参与方2的分支事务命令记录表2，以及与分支事务命令记录表1、分支事务命令记录表2关联的全局事务命令记录表。
[0207]
部署在调用方中的事务协调管理组件，可以根据每个分支事务第一阶段的执行结果(即各尝试阶段接口的执行结果)均为执行成功，利用分支事务命令记录表和全局事务命令记录表，对于第二阶段无需立即调用的分支事务，根据设置的调度中心发送的调度消息，实现该分支事务的第二阶段(确认阶段)的延迟执行和重试。
[0208]
同时，对于第二阶段需要立即调用的分支事务，可以通过异步线程，实现该分支事务第二阶段(确认阶段)的立即执行，并可以对于首次执行失败的分支事务，实现该分支事务第二阶段(确认阶段)的重试。
[0209]
另外，部署在调用方中的事务协调管理组件，可以根据每个分支事务第一阶段的执行结果(即各尝试阶段接口的执行结果)为至少一个分支事务执行失败，利用分支事务命令记录表和全局事务命令记录表，对于第二阶段无需立即调用的分支事务，实现该分支事务的第二阶段(撤销阶段)的延迟执行和重试。
[0210]
同时，对于第二阶段需要立即调用的分支事务，可以通过异步线程，实现该分支事务第二阶段(撤销阶段)的立即执行，并可以对于首次执行失败的分支事务，实现该分支事务第二阶段(撤销阶段)的重试。
[0211]
图7对应的典型的应用场景可以但不限于包括，涉及账户扣减、优惠券、库存扣减的下单链路。
[0212]
需要说明的是，图3和图7中涉及的事务协调管理组件(可以理解为开发的jar包)，可以利用分片任务来实现，从而可以通过多线程并发的方式来执行任务。
[0213]
与异步重试确保模型类似的，分支事务每个阶段也均可以通过异步命令执行器来实现。
[0214]
且与异步重试确保模型类似的，rts可以提供尝试阶段、确认阶段和撤销阶段分别对应的三个核心接口，供调用方继承，同样需要保证接口幂等。并可以在实例化后，注册至rts容器中的执行器注册表中，由事务协调管理组件调度。区别在于，参与方业务逻辑由原有的单一步骤拆分成有时序关系的多个步骤。
[0215]
异步命令的执行逻辑，可以修改直接依赖和间接依赖的资源状态，其中：
[0216]
try阶段：主要用于锁定业务中涉及的资源或者先完成写操作，例如送礼链路中，冻结账户的资金或直接扣除资金，占用资源；
[0217]
confirm阶段：主要用于尝试阶段完成后的一些异步操作。例如插入入账明细、发送私信等；
[0218]
cancel阶段：主要用于恢复因局部网络故障导致的数据不一致，利用回滚或补偿操作，将已完成try阶段的参与方锁定的资源回收。
[0219]
在一种可能的实现方式中，cancel阶段接口可以实现业务的空回滚，即，若针对某分布式事务处理请求，参与方中try阶段接口未执行成功，则根据cancel阶段接口，该参与方cancel阶段的回滚可以默认成功。
[0220]
且与异步重试确保模型类似的，可以配置与业务数据同库的关系型数据库，用于实现业务调度过程中事务命令的存储、查询和修改等。通过与业务数据同库保存事务命令，减少网络io，提升系统性能，使得基于rts的系统性能相比于基于中心化服务的tcc模式更优。
[0221]
在该关系型数据库中创建的全局事务命令记录表，可以包括分布式事务对应的事务命令相关的配置和操作记录信息，以实现全局事务记录的保存，在该关系型数据库中创建的分支事务命令记录表，可以包括分支事务对应的事务命令相关的配置和操作记录信息，以实现各参与方的分支事务记录的保存，从而使得调用方可以基于全局事务命令记录表和分支事务命令记录表，协调事务的各阶段提交。
[0222]
全局事务命令记录表、分支事务命令记录表的形式可以与异步重试确保模型中涉及的事务命令记录表的形式类似，全局事务命令记录表的示意图可以如图8(a)所示，分支事务命令记录表的示意图可以如图8(b)所示，一个全局事务命令记录表，可以对应多个分支事务命令记录表，可以理解为多个分支事务命令记录表可以关联同一个全局事务命令记录表。
[0223]
如图8(a)所示，全局事务命令记录表(可以记为mts_business_activity)中，一次全局事务操作对应一条全局事务命令记录，其中的activityid字段可以表示系统自增函数分配的唯一的全局事务记录号，businessno字段可以表示映射至业务请求的请求号，后续的协调过程中，可以根据业务请求号查询关联数据。
[0224]
全局事务命令记录表的其余字段(例如，分片信息(shardingindex)、调用业务名称(appname)、全局事务状态(status)、时间策略(strategy)、已重试次数(retrytimes)、最大重试次数(maxlimittimes)、下次执行时间(nextexecutetime)、全局事务命令记录表创建时间(createtime)和全局事务命令记录表更新时间(updatetime))，与异步重试确保模型涉及的事务命令记录表中提及的状态信息、执行策略、业务隔离信息等的设置思路类似，其中，需要说明的是，在全局事务命令记录表中，全局事务状态可以包括处理中、待提交、待取消、已提交、已取消和执行失败，且需要保证全局事务状态最终达到终态，即已提交、已取
消或执行失败。
[0225]
全局事务中参与方的数量决定分支事务命令记录表的数量，每个分支事务命令记录表用于存储一个分支事务执行的基本信息。如图8(b)所示，分支事务命令记录表(可以记为mts_business_action)中，actionid字段可以用于表示系统自增函数分配的唯一的分支事务记录号，relactivityid字段可以用于表示该分支事务命令记录表关联的全局事务命令记录表，actionbeanname字段可以用于表示初始化各阶段接口的异步命令执行器标识，可通过此字段路由选择异步命令执行器，完成各阶段逻辑。
[0226]
分支事务命令记录表的其余字段(例如，业务请求号(businessno)、分片信息(shardingindex)、分支事务状态(status)、分支事务命令记录表创建时间(createtime)和分支事务命令记录表更新时间(updatetime))，也与异步重试确保模型涉及的事务命令记录表中提及的状态信息、执行策略、业务隔离信息等的设置思路类似，其中，需要说明的是，在分支事务命令记录表中，分支事务状态也可以包括处理中、待提交、待取消、已提交、已取消和执行失败，且需要保证分支事务状态最终达到终态，即已提交、已取消或执行失败。
[0227]
根据基于同库协调的tcc模型，分布式事务处理流程示意图可以如图9所示，全局事务开始后，可以在全局事务切面，确定事务参与方，并生成全局事务命令记录表，以及每个参与方对应的分支事务命令记录表。全局事务命令记录表以及每个分支事务命令记录表，与调用方业务数据同库，即可以插入业务数据库中，保证数据读写性能与原子性。
[0228]
调用方响应于分布式事务处理请求，在第一阶段，可以调用分布式事务的每个参与方(参与方1和参与方2)对应的尝试阶段接口，并根据每个分支事务尝试阶段接口的执行结果，更新在本地业务数据库中预先生成的每个分支事务命令记录表(分支事务命令记录表1和分支事务命令记录表2)，并更新在本地业务数据库中预先生成的关联的全局事务命令记录表。
[0229]
响应于每个分支事务尝试阶段接口的执行结果，在第二阶段，可以根据分支事务命令记录表和全局事务命令记录表，针对每个分支事务，实现确认阶段或撤销阶段处理。根据处理结果，可以更新在本地业务数据库中保存的分支事务命令记录表1和分支事务命令记录表2，并可以更新在本地业务数据库中保存的全局事务命令记录表。保证第二阶段的数据最终一致性。
[0230]
其中，在第二阶段，针对每个分支事务，实现确认阶段或撤销阶段处理，可以是根据设置的调度中心发送的调度消息来实现第二阶段(confirm阶段或cancel阶段)的延迟执行和兜底重试，也可以是通过异步线程，来实现第二阶段的立即执行，并针对首次执行失败的分支事务，实现该分支事务第二阶段的兜底重试。
[0231]
可以理解为，分布式事务下的所有分支事务，可以按顺序执行尝试阶段操作。由于调用方需要及时反馈给上层响应结果，需在每个分支事务的尝试阶段全部执行成功，或者期间某个分支事务出现异常时，将成功或失败响应结果通知到上游服务。对于第二阶段的操作，可通过调用方协调、基于异步重试机制，完成确认或者撤销阶段。
[0232]
如果所有分支事务第一阶段全部正常执行，那么可以将全局事务、每个分支事务状态均设置为待提交；如果第一阶段的操作由于局部故障导致失败，那么可以将全局事务、每个分支事务状态均设置为待取消。
[0233]
在事务状态发生变更之后，调用方需完成后续的第二阶段操作。与异步重试确保
模型类似的，可以通过异步线程唤起以及定时任务调度通知，去调度对应分支事务的第二阶段操作，直至最终完成，保证数据一致性，并可以将全局事务、每个分支事务状态设置为终态(已提交、已取消或执行失败)，完成整个基于tcc协议的分布式事务处理流程。
[0234]
针对基于同库协调的tcc模型，本公开提供一种分布式事务处理方法，该方法的步骤流程可以如图10所示，包括：
[0235]
步骤201、响应于分布式事务处理请求，调用分布式事务的每个分支事务的尝试阶段接口，根据每个分支事务尝试阶段接口的执行结果，更新预先生成的每个分支事务命令记录表，并更新预先生成的关联的全局事务命令记录表。
[0236]
在本步骤中，可以根据分布式事务处理请求，确定该分布式事务的参与方，针对每个参与方生成分支事务命令记录表，分支事务命令记录表包括分支事务对应的事务命令相关的配置和操作记录信息，并针对该分布式事务生成全局事务命令记录表，全局事务命令记录表包括分布式事务对应的事务命令相关的配置和操作记录信息。
[0237]
分支事务命令记录表和全局事务命令记录表可以保存在业务数据库中，与业务数据实现同库保存，使得对分支事务命令记录表和全局事务命令记录表的操作，可以像操作业务数据一样，基于本地业务数据库来实现，无需通过网络io实现，避免通过网络io来实现分布式事务导致的系统性能较差的问题。
[0238]
在本步骤中，可以进一步调用分布式事务每个分支事务的尝试阶段接口，进而可以根据每个分支事务尝试阶段接口的执行结果，来更新生成的分支事务命令记录表以及全局事务命令记录表。
[0239]
步骤202、根据分布式事务每个分支事务的尝试阶段接口的执行结果，实现对该分布式事务第二阶段的处理。
[0240]
本步骤可以包括，响应于每个分支事务尝试阶段接口的执行结果均为执行成功，可以根据分支事务命令记录表和全局事务命令记录表，确定分布式事务以及每个分支事务的状态，根据确定出的分布式事务以及每个分支事务的状态，实现对分布式事务确认阶段的处理。
[0241]
即在本实施例中，可以基于分支事务命令记录表和全局事务命令记录表，针对分布式事务，实现tcc协议中确认阶段的处理。
[0242]
在一种可能的实现方式中，可以但不限于基于重试机制，针对分布式事务，实现tcc协议中确认阶段的处理，以提高分布式事务处理的成功率。
[0243]
进一步的，在一种可能的实现方式中，可以但不限于通过以下方式，实现tcc协议中确认阶段的处理：
[0244]
响应于每个分支事务尝试阶段接口的执行结果均为执行成功，读取全局事务命令记录表，根据全局事务命令记录表，确定分布式事务是否达到第一指定状态(例如，已提交或执行失败)；
[0245]
响应于分布式事务未达到第一指定状态，读取关联的每个分支事务对应的分支事务命令记录表，根据分支事务命令记录表，确定未达到第一设定状态(例如，已提交或执行失败)的分支事务；
[0246]
针对每个未达到第一设定状态的分支事务，响应于到达该分支事务的调用时间，根据对应的分支事务命令记录表，确定对应的第一异步命令执行器的标识，第一异步命令
执行器包括确认阶段接口，确认阶段接口用于执行指定的异步业务策略，实现确认阶段的操作；
[0247]
根据确定出的第一异步命令执行器的标识，路由到对应的第一异步命令执行器，通过第一异步命令执行器包括的确认阶段接口执行指定的异步业务策略，并根据执行结果，更新对应的分支事务命令记录表；根据每个未达到第一设定状态的分支事务对应的执行结果，更新全局事务命令记录表；
[0248]
响应于满足一定条件，例如到达设定时刻，返回执行读取全局事务命令记录表。
[0249]
即，若分布式事务未达到确认阶段的终态，则可以确定每个未达到确认阶段的终态的分支事务。针对每个确定出的分支事务，若确定到达该分支事务的调用时间，则可以通过对应的异步命令执行器，实现对该分支事务确认阶段接口的调用，对应更新分支事务命令记录表，从而可以更新关联的全局事务命令记录表。
[0250]
在满足一定条件，例如到达设定时刻时，可以重新读取全局事务命令记录表，再次确定分布式事务是否达到确认阶段的终态，从而可以基于重试机制，使得分布式事务的确认阶段最终可以达到终态，即分布式事务每个分支事务的确认阶段最终可以达到终态，提高分布式事务执行的成功率。
[0251]
需要说明的是，除了可以基于异步重试机制，对于确认阶段无需立即执行的分布式事务，来实现各分支事务确认阶段的延迟执行和重试之外，响应于每个分支事务尝试阶段接口的执行结果均为执行成功，在读取全局事务命令记录表之前，还可以通过创建的异步线程调用每个分支事务对应的确认阶段接口，异步线程为业务线程执行业务请求的过程中创建的；根据每个分支事务对应的确认阶段接口的调用结果，更新全局事务命令记录表以及对应的分支事务命令记录表。
[0252]
即，对于确认阶段需要立即执行的分布式事务，可以通过异步线程，实现各分支事务确认阶段的立即执行。且可以基于重试机制，对于通过异步线程首次执行失败的分支事务确认阶段，实现分支事务确认阶段的重试。
[0253]
需要进一步说明的是，实现分支事务确认阶段的延迟执行和重试的过程中，根据执行结果，更新对应的分支事务命令记录表，根据每个未达到第一设定状态的分支事务对应的执行结果，更新全局事务命令记录表，可以包括：
[0254]
响应于执行结果为异步业务策略执行成功，将对应的分支事务命令记录表中的分支事务状态更新为第二设定状态(例如，已提交)；响应于每个未达到第一设定状态的分支事务对应的执行结果均为异步业务策略执行成功，将全局事务命令记录表中包括的全局事务状态更新为第二指定状态(例如，已提交)；
[0255]
响应于至少一个未达到第一设定状态的分支事务对应的执行结果为异步业务策略执行失败，更新该分支事务对应的已调用次数和下次调用时间，响应于已调用次数达到第一阈值，将该分支事务对应的分支事务命令记录表中的分支事务状态更新为第三设定状态(例如，执行失败)，并将所述全局事务命令记录表中的全局事务状态更新为第三指定状态(例如，执行失败)。
[0256]
通过异步线程，实现各分支事务确认阶段的立即执行的过程中，根据每个分支事务对应的确认阶段接口的调用结果，更新全局事务命令记录表以及对应的分支事务命令记录表的方式，与上述更新方式类似，在此不再赘述。
[0257]
另外，本步骤还可以包括，响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，根据分支事务命令记录表和全局事务命令记录表，确定分布式事务以及每个分支事务的状态，根据确定出的分布式事务以及每个分支事务的状态，实现对分布式事务撤销阶段的处理。
[0258]
即在本实施例中，可以基于分支事务命令记录表和全局事务命令记录表，针对分布式事务，实现tcc协议中撤销阶段的处理。
[0259]
在一种可能的实现方式中，可以但不限于基于重试机制，针对分布式事务，实现tcc协议中撤销阶段的处理，以提高分布式事务处理的成功率。
[0260]
进一步的，在一种可能的实现方式中，可以但不限于通过以下方式，实现tcc协议中撤销阶段的处理：
[0261]
响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，读取全局事务命令记录表，根据全局事务命令记录表，确定分布式事务是否达到第四指定状态(例如，已取消或执行失败)；
[0262]
响应于分布式事务未达到第四指定状态，读取关联的每个分支事务对应的分支事务命令记录表，根据分支事务命令记录表，确定未达到第四设定状态(例如，已取消或执行失败)的分支事务；
[0263]
针对每个未达到第四设定状态的分支事务，响应于到达该分支事务的调用时间，根据对应的分支事务命令记录表，确定对应的第二异步命令执行器的标识，第二异步命令执行器包括撤销阶段接口，撤销阶段接口用于执行指定的异步业务策略，实现撤销阶段的操作；
[0264]
根据确定出的第二异步命令执行器的标识，路由到对应的第二异步命令执行器，通过第二异步命令执行器包括的撤销阶段接口执行指定的异步业务策略，并根据执行结果，更新对应的分支事务命令记录表；根据每个未达到第四设定状态的分支事务对应的执行结果，更新全局事务命令记录表；
[0265]
响应于满足一定条件，例如到达设定时刻，返回执行读取全局事务命令记录表。
[0266]
即，若分布式事务未达到撤销阶段的终态，则可以确定每个未达到撤销阶段的终态的分支事务。针对每个确定出的分支事务，若确定到达该分支事务的调用时间，则可以通过对应的异步命令执行器，实现对该分支事务撤销阶段接口的调用，对应更新分支事务命令记录表，从而可以更新关联的全局事务命令记录表。
[0267]
在满足一定条件，例如到达设定时刻时，可以重新读取全局事务命令记录表，再次确定分布式事务是否达到撤销阶段的终态，从而可以基于重试机制，使得分布式事务的撤销阶段最终可以达到终态，即分布式事务每个分支事务的撤销阶段最终可以达到终态，提高分布式事务执行的成功率。
[0268]
需要说明的是，除了可以基于异步重试机制，对于撤销阶段无需立即执行的分布式事务，来实现各分支事务撤销阶段的延迟执行和重试之外，响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，在读取全局事务命令记录表之前，还可以通过创建的异步线程调用每个分支事务对应的撤销阶段接口；根据每个分支事务对应的撤销阶段接口的调用结果，更新全局事务命令记录表以及对应的分支事务命令记录表。
[0269]
即，对于撤销阶段需要立即执行的分布式事务，可以通过异步线程，实现各分支事
务撤销阶段的立即执行。且可以基于重试机制，对于通过异步线程首次执行失败的分支事务撤销阶段，实现分支事务撤销阶段的重试。
[0270]
需要进一步说明的是，实现分支事务撤销阶段的延迟执行和重试的过程中，根据执行结果，更新对应的分支事务命令记录表；以及，根据每个未达到第四设定状态的分支事务对应的执行结果，更新全局事务命令记录表，包括：
[0271]
响应于执行结果为异步业务策略执行成功，将对应的分支事务命令记录表中的分支事务状态更新为第五设定状态(例如，已取消)；响应于每个未达到第四设定状态的分支事务对应的执行结果均为异步业务策略执行成功，将全局事务命令记录表中包括的全局事务状态更新为第五指定状态(例如，已取消)；
[0272]
响应于至少一个未达到第四设定状态的分支事务对应的执行结果为异步业务策略执行失败，更新该分支事务对应的已调用次数和下次调用时间，响应于已调用次数达到第二阈值，将该分支事务对应的分支事务命令记录表中的分支事务状态更新为第六设定状态(例如，执行失败)，并将全局事务命令记录表中的全局事务状态更新为第六指定状态(例如，执行失败)。
[0273]
通过异步线程，实现各分支事务撤销阶段的立即执行的过程中，根据每个分支事务对应的撤销阶段接口的调用结果，更新全局事务命令记录表以及对应的分支事务命令记录表的方式，与上述更新方式类似，在此不再赘述。
[0274]
本公开提供的应用于调用方的上述两种分布式事务处理方法，可以应用于同一个调用方，本公开对此不再进一步进行说明。
[0275]
本公开实施例提供的方案，可以通过事务命令记录表(此处将事务命令记录表、全局事务命令记录表和分支事务命令记录表，统称为事务命令记录表)结构的设计，使得分布式事务在调度状态、执行策略和环境隔离的控制上更加灵活。rts中的异步重试机制，提出可以基于异步执行、定时任务去重试执行在本地事务中提交的异步命令，直至数据最终一致，有效解决异步解耦、柔性事务的问题。rts中的基于同库协调的tcc模式，提供了事务记录备份，通过同库读写，无需回查，即可确保多参与方事务的一致性，可以解决对一致性要求比较严格的分布式事务问题。
[0276]
本公开实施例提供的方案，通过提供优化的分布式事务组件，可以保证业务改造成本低，性能损耗少，隔离性保证完整。其可以提供去中心化服务，可将rts框架集成至客户端(调用方)，实现依赖式引入，接入简单，解决分布式柔性事务数据一致性保证问题，保证全局事务最终一致，隔离性保证完整。且基于同库模式实现数据读写，无需回查，性能取决于业务数据库的写入能力，不会存在明显性能瓶颈。另外，可实现依赖资源、重试策略、调度策略的可配置化，满足业务对分布式事务策略的定制化需求。并可以支持环境隔离以及命令集水平分片，实现多线程并发执行命令。
[0277]
与提供的方法对应的，进一步提供以下的装置。
[0278]
本公开实施例提供一种分布式事务处理装置，该装置可以集成在调用方中，该装置的结构可以如图11所示，包括：
[0279]
尝试阶段接口调用模块11用于响应于分布式事务处理请求，调用所述分布式事务的每个分支事务的尝试阶段接口；
[0280]
确认阶段接口调用模块12用于响应于每个分支事务尝试阶段接口的执行结果均
为执行成功，根据所述分支事务命令记录表和所述全局事务命令记录表，确定所述分布式事务以及每个分支事务的状态，根据确定出的所述分布式事务以及每个分支事务的状态，实现对所述分布式事务确认阶段的处理；
[0281]
撤销阶段接口调用模块13用于响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，根据所述分支事务命令记录表和所述全局事务命令记录表，确定所述分布式事务以及每个分支事务的状态，根据确定出的所述分布式事务以及每个分支事务的状态，实现对所述分布式事务撤销阶段的处理；
[0282]
更新模块14用于根据每个分支事务尝试阶段接口的执行结果，更新预先生成的每个分支事务命令记录表，并更新预先生成的关联的全局事务命令记录表；所述分支事务命令记录表包括分支事务对应的事务命令相关的配置和操作记录信息，所述全局事务命令记录表包括所述分布式事务对应的事务命令相关的配置和操作记录信息，且所述分支事务命令记录表和所述全局事务命令记录表保存在业务数据库中。
[0283]
在一种可能的实现方式中，所述确认阶段接口调用模块12具体用于响应于每个分支事务尝试阶段接口的执行结果均为执行成功，读取所述全局事务命令记录表，根据所述全局事务命令记录表，确定所述分布式事务是否达到第一指定状态；
[0284]
响应于所述分布式事务未达到第一指定状态，读取关联的每个分支事务对应的分支事务命令记录表，根据所述分支事务命令记录表，确定未达到第一设定状态的分支事务；
[0285]
针对每个未达到第一设定状态的分支事务，响应于到达该分支事务的调用时间，根据对应的分支事务命令记录表，确定对应的第一异步命令执行器的标识，所述第一异步命令执行器包括确认阶段接口，所述确认阶段接口用于执行指定的异步业务策略，实现确认阶段的操作；
[0286]
根据确定出的所述第一异步命令执行器的标识，路由到对应的第一异步命令执行器，通过第一异步命令执行器包括的确认阶段接口执行指定的异步业务策略；
[0287]
响应于到达设定时刻，返回执行读取所述全局事务命令记录表；
[0288]
所述更新模块14还用于根据所述第一异步命令执行器的执行结果，更新对应的分支事务命令记录表；根据每个未达到第一设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表。
[0289]
在一种可能的实现方式中，所述装置还包括异步线程调用模块15：
[0290]
所述异步线程调用模块15用于通过创建的异步线程调用所述分布式事务的每个分支事务对应的确认阶段接口，所述异步线程为业务线程执行业务请求的过程中创建的；
[0291]
所述更新模块14还用于根据每个分支事务对应的确认阶段接口的调用结果，更新所述全局事务命令记录表以及对应的分支事务命令记录表。
[0292]
在一种可能的实现方式中，所述更新模块14根据所述第一异步命令执行器的执行结果，更新对应的分支事务命令记录表；根据每个未达到第一设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表，包括：
[0293]
响应于所述第一异步命令执行器的执行结果为异步业务策略执行成功，将对应的分支事务命令记录表中的分支事务状态更新为第二设定状态；响应于每个未达到第一设定状态的分支事务对应的执行结果均为异步业务策略执行成功，将所述全局事务命令记录表中包括的全局事务状态更新为第二指定状态；
[0294]
响应于至少一个未达到第一设定状态的分支事务对应的执行结果为异步业务策略执行失败，更新该分支事务对应的已调用次数和下次调用时间，响应于已调用次数达到第一阈值，将该分支事务对应的分支事务命令记录表中的分支事务状态更新为第三设定状态，并将所述全局事务命令记录表中的全局事务状态更新为第三指定状态。
[0295]
在一种可能的实现方式中，所述撤销阶段接口调用模块13具体用于响应于至少一个分支事务尝试阶段接口的执行结果为执行失败，读取所述全局事务命令记录表，根据所述全局事务命令记录表，确定所述分布式事务是否达到第四指定状态；
[0296]
响应于所述分布式事务未达到第四指定状态，读取关联的每个分支事务对应的分支事务命令记录表，根据所述分支事务命令记录表，确定未达到第四设定状态的分支事务；
[0297]
针对每个未达到第四设定状态的分支事务，响应于到达该分支事务的调用时间，根据对应的分支事务命令记录表，确定对应的第二异步命令执行器的标识，所述第二异步命令执行器包括撤销阶段接口，所述撤销阶段接口用于执行指定的异步业务策略，实现撤销阶段的操作；
[0298]
根据确定出的所述第二异步命令执行器的标识，路由到对应的第二异步命令执行器，通过第二异步命令执行器包括的撤销阶段接口执行指定的异步业务策略；
[0299]
响应于到达设定时刻，返回执行读取所述全局事务命令记录表；
[0300]
所述更新模块14还用于根据所述第二异步命令执行器的执行结果，更新对应的分支事务命令记录表；根据每个未达到第四设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表。
[0301]
在一种可能的实现方式中，所述异步线程调用模块15用于通过创建的异步线程调用所述分布式事务的每个分支事务对应的撤销阶段接口，所述异步线程为业务线程执行业务请求的过程中创建的；
[0302]
所述更新模块14还用于根据每个分支事务对应的撤销阶段接口的调用结果，更新所述全局事务命令记录表以及对应的分支事务命令记录表。
[0303]
在一种可能的实现方式中，所述更新模块14根据所述第二异步命令执行器的执行结果，更新对应的分支事务命令记录表；根据每个未达到第四设定状态的分支事务对应的执行结果，更新所述全局事务命令记录表，包括：
[0304]
响应于所述第二异步命令执行器的执行结果为异步业务策略执行成功，将对应的分支事务命令记录表中的分支事务状态更新为第五设定状态；响应于每个未达到第四设定状态的分支事务对应的执行结果均为异步业务策略执行成功，将所述全局事务命令记录表中包括的全局事务状态更新为第五指定状态；
[0305]
响应于至少一个未达到第四设定状态的分支事务对应的执行结果为异步业务策略执行失败，更新该分支事务对应的已调用次数和下次调用时间，响应于已调用次数达到第二阈值，将该分支事务对应的分支事务命令记录表中的分支事务状态更新为第六设定状态，并将所述全局事务命令记录表中的全局事务状态更新为第六指定状态。
[0306]
在一种可能的实现方式中，所述装置还包括读取模块16、状态确定模块17和处理模块18，其中：
[0307]
所述读取模块16用于响应于分支事务调用请求，读取所述分支事务对应的事务命令记录表，所述事务命令记录表包括事务命令相关的配置和操作记录信息，且所述事务命
令记录表保存在业务数据库中；
[0308]
所述状态确定模块17用于根据所述事务命令记录表，确定所述分支事务的状态；
[0309]
所述处理模块18用于根据确定出的所述分支事务的状态，实现对所述分支事务的处理。
[0310]
在一种可能的实现方式中，所述处理模块18具体用于响应于所述分支事务未达到特定状态，根据所述事务命令记录表，确定是否到达所述分支事务调用时间；
[0311]
响应于到达所述分支事务调用时间，根据所述事务命令记录表，确定对应的第三异步命令执行器的标识，所述第三异步命令执行器用于执行指定的异步业务策略，实现分支事务的调用；
[0312]
根据确定出的所述第三异步命令执行器的标识，路由到对应的第三异步命令执行器执行指定的异步业务策略，根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表，并响应于到达设定时刻，返回执行读取所述分支事务对应的事务命令记录表。
[0313]
在一种可能的实现方式中，所述异步线程调用模块15还用于通过创建的异步线程调用所述第三异步命令执行器，所述异步线程为业务线程执行业务请求的过程中创建的；触发所述处理模块18根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表。
[0314]
在一种可能的实现方式中，所述处理模块18根据所述第三异步命令执行器的执行结果，更新所述事务命令记录表，包括：
[0315]
响应于执行结果为异步业务策略执行成功，将所述事务命令记录表中的分支事务状态更新为第一状态；
[0316]
响应于执行结果为异步业务策略执行失败，更新事务命令记录表中的已调用次数和下次调用时间，响应于已调用次数达到门限值，将事务命令记录表中的分支事务状态更新为第二状态。
[0317]
可以理解为，在上述装置中，除异步线程调用模块15之外的其它模块，均可以集成在本公开提及的rts事务协调管理组件中，由事务协调管理组件实现集成的各模块的上述功能。
[0318]
本公开上述实施例提供的各装置的各功能单元的功能，可以通过上述对应的各方法的步骤来实现，因此，本公开实施例提供的各装置中的各个功能单元的可能的工作过程和有益效果，在此不复赘述。
[0319]
基于同一发明构思，本公开实施例提供以下的设备和介质。
[0320]
本公开实施例提供一种分布式事务处理设备，该设备的结构可以如图12所示，包括处理器21、通信接口22、存储器23和通信总线24，其中，所述处理器21，所述通信接口22，所述存储器23通过所述通信总线24完成相互间的通信；
[0321]
所述存储器23，用于存放计算机程序；
[0322]
所述处理器21，用于执行所述存储器上所存储的程序时，实现本公开上述方法实施例所述的步骤。
[0323]
可选的，所述处理器21可以包括中央处理器(cpu)、特定应用集成电路(asic，application specific integrated circuit)，可以是一个或多个用于控制程序执行的集成电路，可以是使用现场可编程门阵列(fpga，field programmable gate array)开发的硬
件电路，可以是基带处理器。
[0324]
可选的，所述处理器21可以包括至少一个处理核心。
[0325]
可选的，所述存储器23可以包括只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)和磁盘存储器。存储器23用于存储至少一个处理器21运行时所需的数据。存储器23的数量可以为一个或多个。
[0326]
本公开实施例还提供一种非易失性计算机存储介质，所述计算机存储介质存储有可执行程序，当可执行程序被处理器执行时，实现本公开上述方法实施例提供的方法。
[0327]
在可能的实施过程中，计算机存储介质可以包括：通用串行总线闪存盘(usb，universal serial bus flash drive)、移动硬盘、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的存储介质。
[0328]
在本公开实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述单元或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性或其它的形式。
[0329]
在本公开实施例中的各功能单元可以集成在一个处理单元中，或者各个单元也可以均是独立的物理模块。
[0330]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开实施例的技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备，例如可以是个人计算机，服务器，或者网络设备等，或处理器(processor)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：通用串行总线闪存盘(universal serial bus flash drive)、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
[0331]
本领域内的技术人员应明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
[0332]
本公开是参照根据本公开实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0333]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指
令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0334]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0335]
尽管已描述了本公开的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本公开范围的所有变更和修改。
[0336]
显然，本领域的技术人员可以对本公开进行各种改动和变型而不脱离本公开的精神和范围。这样，倘若本公开的这些修改和变型属于本公开权利要求及其等同技术的范围之内，则本公开也意图包含这些改动和变型在内。