CN108345977B - 一种业务处理方法及装置 - Google Patents

Abstract

本申请实施例公开了一种业务处理方法及装置。所述方法包括：接收业务重试触发消息，所述业务重试触发消息是根据预配置的重试间隔策略定时发送的，所述重试间隔策略包括固定重试间隔策略或基于动态表达式的弹性重试间隔策略；根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录；对所述掉单业务活动记录对应的业务活动进行重试执行。利用本申请实施例，可以实现无需在当前线程中同步重试执行掉单业务活动，而是可以在预配置的策略的定时触发下，异步地重试执行掉单业务活动，因此，即使业务系统重启或崩溃，仍然可以在业务系统恢复正常后再次重试。

Description

一种业务处理方法及装置

技术领域

本申请涉及计算机软件技术领域，尤其涉及一种业务处理方法及装置。

背景技术

随着计算机技术和互联网技术的迅速发展，很多业务都可以在网上进行，比如电子金融业务、电商业务等。一般地，可以由流程引擎将业务所涉及的一个或多个业务活动进行编排，构成相应的业务流程，再按照业务流程顺序执行业务活动，从而实现业务目标。

业务流程中的业务活动执行通常会涉及两端之间的方法调用，一种典型的调用是调用端向服务端发起的远程方法调用(Remote Procedure Call，RPC)。在实际应用中，RPC可能会执行失败，则相应的业务活动也会执行异常，进而可能导致业务掉单。从用户角度而言，由于发生业务掉单，用户即使已经支付了业务代价，却无法获得相应的业务服务，体验很差。

针对上述业务活动执行异常的情况导致业务掉单的问题，现有技术中通常采用同步重试的方式解决。具体地，在RPC执行失败导致业务活动执行异常时，可以在当前线程中同步重试执行该RPC，进而实现对应的业务活动重试执行。

但是，上述现有技术中同步重试的方式的稳定性较差，在业务系统重启或崩溃时会失去同步重试的状态，导致业务活动无法再重试执行。

发明内容

本申请实施例提供一种业务处理方法及装置，用以解决如下技术问题：上述现有技术中同步重试的方式的稳定性较差，在业务系统重启或崩溃时会失去同步重试的状态，导致业务活动无法再重试执行。

为解决上述技术问题，本申请实施例是这样实现的：

本申请实施例提供的一种业务处理方法，包括：

接收业务重试触发消息，所述业务重试触发消息是根据预配置的重试间隔策略定时发送的，所述重试间隔策略包括固定重试间隔策略或基于动态表达式的弹性重试间隔策略；

根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录；

对所述掉单业务活动记录对应的业务活动进行重试执行。

本申请实施例提供的一种业务处理装置，包括：

接收模块，接收业务重试触发消息，所述业务重试触发消息是根据预配置的重试间隔策略定时发送的，所述重试间隔策略包括固定重试间隔策略或基于动态表达式的弹性重试间隔策略；

确定模块，根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录；

重试模块，对所述掉单业务活动记录对应的业务活动进行重试执行。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：可以实现无需在当前线程中同步重试执行掉单业务活动，而是可以在预配置的策略的定时触发下，异步地重试执行掉单业务活动，因此，即使业务系统重启或崩溃，仍然可以在业务系统恢复正常后再次重试，因此，可以部分或全部地解决现有技术中的问题。

附图说明

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

图1为现有技术中调用端和服务端之间的远程方法调用过程示意图；

图2为现有技术中的一种消息服务的原理示意图；

图3为本申请实施例提供的一种业务处理方法的流程示意图；

图4为现有技术中的一种业务系统的业务流程执行原理示意图；

图5为现有技术中的金融业务系统的一种业务活动模型；

图6为本申请实施例提供的一种业务活动模型的示意图；

图7为本申请实施例提供的集群环境下，上述业务处理方法的一种具体实施方案的原理示意图；

图8为本申请实施例提供的图7对应的交互示意图；

图9为本申请实施例提供的对应于图3的一种业务处理装置的结构示意图。

具体实施方式

本申请实施例提供一种业务处理方法及装置。

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

背景技术中对一种现有技术进行了简单说明，为了便于理解，结合图1、图2对现有技术进一步地说明。

图1为现有技术中调用端和服务端之间的远程方法调用(RPC)过程示意图。对于该RPC过程，于本申请的方案相关的主要有以下背景情况：

在RPC请求过程中由于超时而未收到请求结果，或者应答状态不明确等原因，需要考虑重试执行来保证得到明确的调用返回结果；

调用端对服务端的关系如果不是强依赖(也即，无需当下立即需要调用返回结果)，一般会建议使用基于消息服务(比如msgbroker等)重试的方式来驱动后续业务的执行。如果是强依赖关系，当RPC具体为查询请求时，若应答失败，可以不重试，直接返回处理失败，而当RPC具体为会触发服务端数据状态变化的请求时，则需要实现基于业务数据的同步重试机制来保证数据的最终一致性。比如，在第三方电子支付业务中，第三方支付系统在与外部银行对接时涉及直连请求的强依赖调用，当调用失败时，会引发业务掉单，因此一般采用同步重试的方式重试执行掉单业务。

在上面的说明中，提到了背景技术中的同步重试的方式，除此之外，还提供了另一种现有技术：基于消息服务重试。图2为现有技术中的一种消息服务的原理示意图。在图2中，当异常发生时调用端发送可靠的消息到消息服务系统(msgbroker)后结束当前本地事务，从而依赖msgbroker的消息重复推送来执行后续重试。

但是，上述两种方式均存在问题，具体如下。

对于同步重试的方案，其稳定性较差，在业务系统重启或崩溃时会失去同步重试的状态，导致业务活动无法再重试执行；不仅如此，由于是在当前线程中同步执行的，因此，容易阻塞计算资源，以至于导致业务系统负载恶化。

对于基于消息服务重试的方式，其重试的策略单一，无法基于具体的业务场景来定制重试间隔；需要在序列化和反序列化有所开销。

本申请的方案可以部分或全部地解决上述问题。下面对本申请的方案进行详细说明。

图3为本申请实施例提供的一种业务处理方法的流程示意图。从程序角度而言，该流程的执行主体可以是业务系统相关的功能模块；从设备角度而言，该流程的执行主体可以包括但不限于可搭载所述功能模块的以下设备：计算机集群、个人计算机、大中型计算机、手机、平板电脑、智能可穿戴设备、车机等。

本申请对业务的具体内容并不做限定，只要是可以在网上进行的业务均可适用，比如，金融业务、电子支付业务、通讯业务、电子游戏业务等。

图3中的流程可以包括以下步骤：

S301：接收业务重试触发消息，所述业务重试触发消息是根据预配置的重试间隔策略定时发送的，所述重试间隔策略包括固定重试间隔策略或基于动态表达式的弹性重试间隔策略。

在本申请实施例中，重试间隔策略可以根据具体的业务场景需要进行定制。

当采用了固定重试间隔策略时，业务重试触发消息可以是以固定重试间隔策略对应的固定重试间隔作为定时间隔，定时发送的，比如，每秒钟发送一次或每分钟发送一次等。

当采用了基于动态表达式的弹性重试间隔策略，业务重试触发消息可以是以弹性重试间隔策略对应的特定间隔作为定时间隔，定时发送的，所述弹性重试间隔策略对应的各重试间隔均为所述特定间隔的整倍数。对于多次重试的同一业务活动，重试间隔可以不相同。

以动态表达式“times*10+30”秒为例，“times”表示重试次数(也即，本次是第几次重试)，计算可以得到：第一次重试与前次执行之间间隔40秒，第二次重试与第一次重试间隔50秒，等等。在这种情况下，上述特定间隔一般可以为1秒或10秒等。

当然，业务重试触发消息可以是以弹性重试间隔策略对应的弹性重试间隔作为定时间隔，定时发送的，在这种情况下，每次都需要根据计算弹性重试间隔，以确定本次何时发送业务重试触发消息。初次执行失败后，触发第一次重试的业务重试触发消息可以是在40秒后发送的，触发第二次重试(若第一次重试也失败了)的业务重试触发消息可以是在40+50＝90秒后发送的。

在本申请实施例中，对业务重试触发消息的发送方并不做限定，可以取决于具体场景。比如，对于集群场景，该发送方可以是集群的调度中心；对于单机场景，该发送方可以是单机上的定时器模块；等等。

S302：根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录。

在现有技术中，在业务流程的执行过程中，业务流程中的每个业务活动都具有相应的业务活动记录，该业务活动记录用于描述对应的业务活动的状态信息，业务活动记录是预先定义的业务活动模型(比如，类、结构体、数据库元素等)的实例。

而在本申请实施例中，可以在已有的业务活动模型基础上增加用于描述重试状态的相关字段，比如，“已重试次数”字段、“下次重试时间”字段，等等，如此，业务活动记录既包含有业务活动状态信息，也包含有重试状态信息，便于为后续的重试流程提供支持。

为了便于理解，结合实际应用中的一种业务系统进行说明，如图4所示，图4为该业务系统的业务流程执行原理示意图。以该业务系统具体为金融业务系统为例。目前，在金融业务系统的设计过程中，剥离了渠道、产品和客户等变化因子后将业务流程进行标准化，成为一个或多个业务活动，业务流程中将渠道、产品和客户这些引起变化的因素剥离出来，定义为变化因子，业务活动因此具有独立于渠道、产品和客户的特点，每当需要引进新的渠道、新的产品和客户分类时，金融业务系统可以高效便捷地调整以适应新的需求。

对于图4中的业务系统，在两个方面做了抽象标准化：

业务流程基于流程引擎进行编排装配：业务具体服务的实现由多个业务活动组成，流程引擎起到穿针引线的作用，流程引擎还负责执行业务流程(也即，按照业务流程顺序，执行业务流程包含的各业务活动)；

业务活动执行前由统一的业务活动模型来承载相关信息。

基于上述两点抽象标准化，可以通过对业务活动模型进行修改，以及进行相关的预配置，实现本申请的方案，成本较小。

图5为金融业务系统的一种业务活动模型的示意图。

图5中包含了用于为描述业务活动定义的多个字段，以及定义的各字段的数据类型。包括：“自增主键ID”、“业务活动编号”、“业务活动类型”、“业务活动状态”等字段。

图6为本申请实施例提供的一种业务活动模型的示意图，是在上述标准化的业务活动模型基础上修改得到的。

在图6中，相比于图5中的业务活动模型，增加了“已重试次数”、“下次重试执行时间(可以简称为：下次执行时间)”这两个字段，用以为掉单业务活动重试提供支持。

在本申请实施例中，确定的掉单业务活动记录具体为：需要本次重试执行的业务活动对应的记录。

在本申请实施例中，在确定掉单业务活动记录后，可以将掉单业务活动记录捞取出来以便于后续处理，或者也可以将掉单业务活动记录的标识信息记录下来以便于后续处理。

S303：对所述掉单业务活动记录对应的业务活动进行重试执行。

在本申请实施例中，对业务活动的重试执行可以由该业务活动前次执行的执行方来执行，也可以由另一方执行。所述另一方、前次的执行方可以是业务系统中的业务活动执行程序或设备(比如，流程引擎、集群中的机器等)。

在本申请实施例中，对业务活动的重试执行需要保障业务活动所涉及数据的幂等性。

另外，在实际应用中，若有需求还可以实现：通过对某个业务活动重试执行以触发相关的一个或多个其他业务活动重试执行。

需要说明的是，图3中的各步骤的执行主体可以是同一设备或同一程序(程序是搭载于设备上的)，也可以是不同设备或不同程序。比如，步骤S301～S303的执行主体可以均为设备1；又比如，步骤S301的执行主体为设备1，步骤S302的执行主体为设备2，S303的执行主体为设备3；等等。

通过图3的方法，可以实现无需在当前线程中同步重试执行掉单业务活动，而是可以在预配置的策略的定时触发下，异步地重试执行掉单业务活动，因此，即使业务系统重启或崩溃，仍然可以在业务系统恢复正常后再次重试。

不仅如此，由于基于动态表达式的动态重试间隔策略相比于现有技术，策略可以灵活多变，有利于支持更多的业务场景。另外，本申请的方案也无需额外的序列化开销或反序列化开销。

基于图3的方法，本申请实施例还提供了该方法的一些具体实施方案，以及扩展方案，下面进行说明。

在本申请实施例中，对于步骤S302，所述根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录，具体可以包括：根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中，确定业务活动状态反映对应的业务活动需重试，且重试状态信息反映对应的业务活动需本次重试的业务活动记录，作为确定的掉单业务活动记录。

以图6中的业务活动模型为例，字段“业务活动状态”可以用于记录业务活动状态信息，可以预先为该字段定义多个值，分别表征不同的业务活动状态。比如，可以用整型值“1”表征“执行成功”状态，用整型值“2”表征“执行失败需重试”状态，用整型值“3”表征“执行失败不需重试”状态等，在这种情况下，通过判定各业务活动记录的“业务活动状态”字段值是否为2，即可确定各业务活动记录是否需要重试。

类似地，字段“已重试次数”和“下次重试时间”可以用于记录重试状态信息，其中，“下次重试时间”字段值可以是根据预配置的重试间隔策略进行维护的。通过将当前时间与“下次重试时间”字段值进行比较，即可确定各业务活动记录是否需要本次重试。

在本申请实施例中，除了预配置重试间隔策略，还可以预配置重试范围策略，用以限定每次执行图3中流程时涉及的业务活动记录的范围。

则对于步骤S302，所述在所述各业务活动记录中确定掉单业务活动记录，具体可以包括：根据预配置的重试范围策略，在属于所述重试范围策略所指定范围的所述各业务活动记录中确定掉单业务活动记录，所述范围包括业务范围和/或时间范围和/或数量范围和/或重试次数范围。所述范围可以是离散值，也可以是连续的取值区间。

以业务范围为例，业务范围可以是：业务类型的范围、业务流程名称的范围、业务活动名称的范围等，列举的这几类业务范围都为离散值。

以时间范围为例，可以指定一个连续的时间区间(具体可以指定该时间区间的两个时间端点即可)作为时间范围。

以数量范围为例，可以指定一个连续的数量区间作为数量范围，也可以指定一个或多个批次信息等作为数量范围，对于后一种情况，属于所述批次的业务活动记录都落在该数量范围内。

以重试次数范围为例，可以指定最大重试次数等作为重试次数范围。

在本申请实施例中，对预配置的重试间隔策略、重试范围策略的具体配置方式并不做限定，比如，可以采用编写诸如JSON、XML等格式的字符串的方式进行配置，也可以通过选项卡界面中选择选项的方式进行配置。

在本申请实施例中，可以上述预配置的策略动态地进行调整，如此，便于迅速适应于业务场景和需求变化，灵活性和适用性较好。

为了便于理解，下面给出了一种实际应用场景下，以字符串方式预配置的上述策略的一种实例：

其中，“processName”为需要掉单重试执行的流程名称(属于上述的业务范围)名，该流程可以为流程引擎中现有的正常流程，也可以为特别配置的异常流程等；“batchsize”为批次大小(属于上述的数量范围)，意味着每次重试涉及的业务活动记录是可配置的；“earliestTimeLimit”和“latestTimeLimit”为一前一后两个时间端点，可以共同定义上述的时间范围，从而使得重试涉及的业务活动记录具有时效意义；“nextExecuteTimeExpression”可以是上述的动态表达式，可以灵活地定义重试间隔；“retryTimes”为最大的重试次数(属于上述的重试次数范围)。

在本申请实施例中，如前所述，所述动态表达式可以是基于重试次数的动态表达式。对掉单业务活动重试完毕后，可以对对应的业务活动记录内的已重试次数、下次重试执行时间、业务活动状态(若状态改变)等进行更新。

具体地，当所述重试间隔策略包括基于动态表达式的弹性重试间隔策略，对于步骤S303，所述对所述掉单业务活动记录对应的业务活动进行重试执行后，还可以执行：若重试执行失败，对对应的重试状态信息包括的已重试次数进行更新；以及，根据更新的已重试次数，确定所述重试次数；将确定的所述重试次数代入所述动态表达式进行计算，并根据计算结果，对所述重试状态信息包括的下次重试执行时间进行更新。而若重试执行成功，可以对业务活动状态进行更新，并且还可以清除下次重试执行时间，因为，后续无需再重试。

类似地，当所述重试间隔策略包括基于固定重试间隔策略，在重试执行完毕后，也可以进行数据更新，比如，可以直接根据固定重试间隔策略对应的固定重试间隔，对下次重试执行时间进行更新。

在本申请实施例中，通过上面的说明可知，图3中的流程可以用于针对一个或多条业务活动记录对应的掉单活动进行重试执行。在实际应用中，业务活动记录的数量可能很大，单机未必有能力独自处理，在这种情况下，可以使用集群处理。下面对本申请的方案在集群中的具体实施进行说明。

相比于单机，集群最大的优点是可以均衡负载，分工协作，完成大数据量的任务。因此，图3中的流程的步骤也可以由集群中的多台机器协作完成。

具体地，上述的各业务活动记录(数量往往较大)可以是保存于一张或多张数据表中的。集群环境下，图3中的各步骤的一种具体实施方式如下所示。

对于步骤S301，所述接收业务重试触发消息，具体可以包括：所述集群中的第一机器接收业务重试触发消息；

对于步骤S302，所述根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录，具体包括：

所述第一机器对包含各业务活动记录的各数据表进行分表操作，得到多个分表，并分发给所述集群中的多个第二机器，各所述第二机器得到的分表不相同；

对于步骤S303，所述对所述掉单业务活动记录对应的业务活动进行重试执行，具体可以包括：所述第三机器通过执行得到的重试执行任务，完成对对应的掉单业务活动记录对应的业务活动的重试执行。

在本申请实施例中，所述第三机器执行得到的重试执行任务，具体可以包括：所述第三机器触发流程引擎执行得到的重试执行任务。当然，若不具有流程引擎，也可以采用其他具有业务活动执行能力的功能模块执行重试执行任务。

在本申请实施例中，述集群处于分布式环境中，所述重试间隔策略、所述重试范围策略预配置于所述分布式环境对应的分布式资源管理设备和/或调度中心设备上。在这种情况下，所述业务重试触发消息可以由所述调度中心设备发送。

更直观地，本申请实施例还提供了集群环境下，上述业务处理方法的一种具体实施方案的原理示意图，如图7所示。

在图7中，基于调度中心的消息来定时触发，当预先选择的是固定重试间隔策略，可以配置采用固定间隔的定时计划任务即可；当业务选择的是弹性重试间隔策略时，则配置的触发周期通常可以与各弹性重试间隔对应的单位时间一致，同时配置基于重试次数的动态表达式，用以确定动态重试间隔。

分表均衡，并加载掉单业务活动记录的数据，生成相应的重试执行任务并分发。

触发流程引擎来执行重试执行任务，如失败则可以更新重试次数以及下次重试执行时间；如成功，可以清除重试次数和下次重试执行时间，无需再重试。

进一步地，本申请实施例还提供了图7对应的交互示意图，如图8所示。

在图8中，将实现上述业务处理方法的逻辑称为通用掉单重试组件，通用掉单重试组件主要由基于三个通用类来完成相应的处理逻辑，分别为ActivityDataSyncSplitter、ActivityDataSyncLoader、ActivityProcessExecutor。完成了掉单数据从分表维度的拆分，到对应表的数据加载，最后完成重试执行的三个阶段，每个阶段都是通过软负载均衡策略来分发到集群中不同的机器来执行，从而有利于较大限度地利用集群资源。需要说明的是，这只是所述逻辑的一种实现方式示例，并非对本申请的限定。

在本申请实施例中，可以将上述业务处理方法应用于对于各种业务活动的重试执行中。在具体的业务支持中，可以预先将业务活动或业务流程的相关信息(比如，业务活动名称或业务流程名称等)、业务重试触发消息的发送方的相关信息(比如，定时器队列名称等)，业务活动状态的相关定义信息，与通用掉单重试组件相关联，从而可以实现对对应业务活动或业务流程的支持。

上面对本申请实施例提供的业务处理方法进行了说明，基于同样的发明思路，本申请实施例还提供了对应的装置，如图9所示。

图9为本申请实施例提供的对应于图3的一种业务处理装置的结构示意图，所述装置包括：

接收模块901，接收业务重试触发消息，所述业务重试触发消息是根据预配置的重试间隔策略定时发送的，所述重试间隔策略包括固定重试间隔策略或基于动态表达式的弹性重试间隔策略；

确定模块902，根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录；

重试模块903，对所述掉单业务活动记录对应的业务活动进行重试执行。

可选地，当所述重试间隔策略包括固定重试间隔策略，所述业务重试触发消息是以所述固定重试间隔策略对应的固定重试间隔作为定时间隔，定时发送的；

当所述重试间隔策略包括基于动态表达式的弹性重试间隔策略，所述业务重试触发消息是以弹性重试间隔策略对应的特定间隔作为定时间隔，定时发送的，所述弹性重试间隔策略对应的各重试间隔均为所述特定间隔的整倍数。

可选地，所述确定模块902根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录，具体包括：

所述确定模块902根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中，确定业务活动状态反映对应的业务活动需重试，且重试状态信息反映对应的业务活动需本次重试的业务活动记录，作为确定的掉单业务活动记录。

可选地，所述确定模块902在所述各业务活动记录中确定掉单业务活动记录，具体包括：

所述确定模块902根据预配置的重试范围策略，在属于所述重试范围策略所指定范围的所述各业务活动记录中确定掉单业务活动记录，所述范围包括业务范围和/或时间范围和/或数量范围和/或重试次数范围。

可选地，所述重试状态信息包括已重试次数和下次重试执行时间。

可选地，所述动态表达式是基于重试次数的动态表达式；

当所述重试间隔策略包括基于动态表达式的弹性重试间隔策略，所述装置还包括：

更新模块904，在所述重试模块903对所述掉单业务活动记录对应的业务活动进行重试执行后，若重试执行失败，对对应的重试状态信息包括的已重试次数进行更新；以及，根据更新的已重试次数，确定所述重试次数；将确定的所述重试次数代入所述动态表达式进行计算，并根据计算结果，对所述重试状态信息包括的下次重试执行时间进行更新。

可选地，所述装置应用于集群中，所述各业务活动记录保存于一张或多张数据表中；

所述接收模块901接收业务重试触发消息，具体包括：

所述集群中的第一机器上的接收模块901接收业务重试触发消息；

所述确定模块902根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录，具体包括：

所述第一机器上的确定模块902对包含各业务活动记录的各数据表进行分表操作，得到多个分表，并分发给所述集群中的多个第二机器，各所述第二机器得到的分表不相同；

所述第二机器上的确定模块902根据所述重试范围策略，以及得到的分表中包含各业务活动记录包含的业务活动状态信息和重试状态信息，确定并加载所述分表对应的掉单业务活动记录，根据加载的掉单业务活动记录，生成相应的重试执行任务，并分发给多个所述集群中的多个第三机器，各所述第三机器得到的重试执行任务不相同；

所述重试模块903对所述掉单业务活动记录对应的业务活动进行重试执行，具体包括：

所述第三机器上的重试模块903通过执行得到的重试执行任务，完成对对应的掉单业务活动记录对应的业务活动的重试执行。

可选地，所述第三机器上的重试模块903执行得到的重试执行任务，具体包括：

所述第三机器上的重试模块903触发流程引擎执行得到的重试执行任务。

可选地，所述集群处于分布式环境中，所述重试间隔策略、所述重试范围策略预配置于所述分布式环境对应的分布式资源管理设备和/或调度中心设备上；

所述业务重试触发消息由所述调度中心设备发送。

本申请实施例提供的装置与方法是一一对应的，因此，装置也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述对应装置的有益技术效果。

本申请实施例中所述支付涉及的技术载体，例如可以包括近场通信(Near FieldCommunication，NFC)、WIFI、3G/4G/5G、POS机刷卡技术、二维码扫码技术、条形码扫码技术、蓝牙、红外、短消息(Short Message Service，SMS)、多媒体消息(Multimedia MessageService，MMS)等。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

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

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

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

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

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (16)

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

接收集群的调度中心或单机上的定时器模块发送的业务重试触发消息，所述业务重试触发消息是根据预配置的重试间隔策略定时发送的，所述重试间隔策略包括固定重试间隔策略或基于动态表达式的弹性重试间隔策略；

根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录；

对所述掉单业务活动记录对应的业务活动进行重试执行；

所述在所述各业务活动记录中确定掉单业务活动记录，具体包括：

根据预配置的重试范围策略，在属于所述重试范围策略所指定范围的所述各业务活动记录中确定掉单业务活动记录，所述范围包括业务范围和/或时间范围和/或数量范围和/或重试次数范围。

2.如权利要求1所述的方法，其特征在于，当所述重试间隔策略包括固定重试间隔策略，所述业务重试触发消息是以所述固定重试间隔策略对应的固定重试间隔作为定时间隔，定时发送的；

当所述重试间隔策略包括基于动态表达式的弹性重试间隔策略，所述业务重试触发消息是以弹性重试间隔策略对应的特定间隔作为定时间隔，定时发送的，所述弹性重试间隔策略对应的各重试间隔均为所述特定间隔的整倍数。

3.如权利要求1所述的方法，其特征在于，所述根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录，具体包括：

根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中，确定业务活动状态反映对应的业务活动需重试，且重试状态信息反映对应的业务活动需本次重试的业务活动记录，作为确定的掉单业务活动记录。

4.如权利要求3所述的方法，其特征在于，所述重试状态信息包括已重试次数和下次重试执行时间。

5.如权利要求4所述的方法，其特征在于，所述动态表达式是基于重试次数的动态表达式；

当所述重试间隔策略包括基于动态表达式的弹性重试间隔策略，所述对所述掉单业务活动记录对应的业务活动进行重试执行后，所述方法还包括：

若重试执行失败，对对应的重试状态信息包括的已重试次数进行更新；以及，

根据更新的已重试次数，确定所述重试次数；

将确定的所述重试次数代入所述动态表达式进行计算，并根据计算结果，对所述重试状态信息包括的下次重试执行时间进行更新。

6.如权利要求1所述的方法，其特征在于，所述方法应用于集群中，所述各业务活动记录保存于一张或多张数据表中；

所述接收业务重试触发消息，具体包括：

所述集群中的第一机器接收业务重试触发消息；

所述根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录，具体包括：

所述第一机器对包含各业务活动记录的各数据表进行分表操作，得到多个分表，并分发给所述集群中的多个第二机器，各所述第二机器得到的分表不相同；

所述第二机器根据所述重试范围策略，以及得到的分表中包含各业务活动记录包含的业务活动状态信息和重试状态信息，确定并加载所述分表对应的掉单业务活动记录，根据加载的掉单业务活动记录，生成相应的重试执行任务，并分发给多个所述集群中的多个第三机器，各所述第三机器得到的重试执行任务不相同；

所述对所述掉单业务活动记录对应的业务活动进行重试执行，具体包括：

所述第三机器通过执行得到的重试执行任务，完成对对应的掉单业务活动记录对应的业务活动的重试执行。

7.权利要求6所述的方法，其特征在于，所述第三机器执行得到的重试执行任务，具体包括：

所述第三机器触发流程引擎执行得到的重试执行任务。

8.权利要求6所述的方法，其特征在于，所述集群处于分布式环境中，所述重试间隔策略、所述重试范围策略预配置于所述分布式环境对应的分布式资源管理设备和/或调度中心设备上；

所述业务重试触发消息由所述调度中心设备发送。

9.一种业务处理装置，其特征在于，包括：

接收模块，接收集群的调度中心或单机上的定时器模块发送的业务重试触发消息，所述业务重试触发消息是根据预配置的重试间隔策略定时发送的，所述重试间隔策略包括固定重试间隔策略或基于动态表达式的弹性重试间隔策略；

确定模块，根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录；

重试模块，对所述掉单业务活动记录对应的业务活动进行重试执行；

所述确定模块在所述各业务活动记录中确定掉单业务活动记录，具体包括：

所述确定模块根据预配置的重试范围策略，在属于所述重试范围策略所指定范围的所述各业务活动记录中确定掉单业务活动记录，所述范围包括业务范围和/或时间范围和/或数量范围和/或重试次数范围。

10.如权利要求9所述的装置，其特征在于，当所述重试间隔策略包括固定重试间隔策略，所述业务重试触发消息是以所述固定重试间隔策略对应的固定重试间隔作为定时间隔，定时发送的；

当所述重试间隔策略包括基于动态表达式的弹性重试间隔策略，所述业务重试触发消息是以弹性重试间隔策略对应的特定间隔作为定时间隔，定时发送的，所述弹性重试间隔策略对应的各重试间隔均为所述特定间隔的整倍数。

11.如权利要求9所述的装置，其特征在于，所述确定模块根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录，具体包括：

所述确定模块根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中，确定业务活动状态反映对应的业务活动需重试，且重试状态信息反映对应的业务活动需本次重试的业务活动记录，作为确定的掉单业务活动记录。

12.如权利要求10所述的装置，其特征在于，所述重试状态信息包括已重试次数和下次重试执行时间。

13.如权利要求12所述的装置，其特征在于，所述动态表达式是基于重试次数的动态表达式；

当所述重试间隔策略包括基于动态表达式的弹性重试间隔策略，所述装置还包括：

更新模块，在所述重试模块对所述掉单业务活动记录对应的业务活动进行重试执行后，若重试执行失败，对对应的重试状态信息包括的已重试次数进行更新；以及，根据更新的已重试次数，确定所述重试次数；将确定的所述重试次数代入所述动态表达式进行计算，并根据计算结果，对所述重试状态信息包括的下次重试执行时间进行更新。

14.如权利要求9所述的装置，其特征在于，所述装置应用于集群中，所述各业务活动记录保存于一张或多张数据表中；

所述接收模块接收业务重试触发消息，具体包括：

所述集群中的第一机器上的接收模块接收业务重试触发消息；

所述确定模块根据各业务活动记录包含的业务活动状态信息和重试状态信息，在所述各业务活动记录中确定掉单业务活动记录，具体包括：

所述第一机器上的确定模块对包含各业务活动记录的各数据表进行分表操作，得到多个分表，并分发给所述集群中的多个第二机器，各所述第二机器得到的分表不相同；

所述第二机器上的确定模块根据所述重试范围策略，以及得到的分表中包含各业务活动记录包含的业务活动状态信息和重试状态信息，确定并加载所述分表对应的掉单业务活动记录，根据加载的掉单业务活动记录，生成相应的重试执行任务，并分发给多个所述集群中的多个第三机器，各所述第三机器得到的重试执行任务不相同；

所述重试模块对所述掉单业务活动记录对应的业务活动进行重试执行，具体包括：

所述第三机器上的重试模块通过执行得到的重试执行任务，完成对对应的掉单业务活动记录对应的业务活动的重试执行。

15.如权利要求14所述的装置，其特征在于，所述第三机器上的重试模块执行得到的重试执行任务，具体包括：

所述第三机器上的重试模块触发流程引擎执行得到的重试执行任务。

16.如权利要求14所述的装置，其特征在于，所述集群处于分布式环境中，所述重试间隔策略、所述重试范围策略预配置于所述分布式环境对应的分布式资源管理设备和/或调度中心设备上；

所述业务重试触发消息由所述调度中心设备发送。

Images