CN110471739B - 指令重试方法及装置 - Google Patents

Abstract

本公开提供了指令重试方法及装置。方法包括：从第一设备接收针对第一指令的运行反馈信息，运行反馈信息包括返回码和业务特征信息；在返回码指示第一指令运行失败时基于业务特征信息确定是否需要对第一指令执行重试处理；在确定为需要对第一指令执行重试处理时基于第一指令来创建第二指令；将所创建的第二指令发送给第一设备来执行指令重试。利用该方法，在位于运行指令的第一设备上游的第二设备处，使用第一设备需要向第二设备反馈的针对第一指令的运行反馈信息中的业务特征信息来实现指令重新确定和重试指令创建操作，而无需等待第一设备处的指令重试确定结果，由此避免了第二设备处的指令重试处理对第一设备处的指令重试确定过程的依赖性。

Description

指令重试方法及装置

技术领域

本公开涉及计算机技术领域，具体地，涉及指令重试方法及装置。

背景技术

在正常的网络环境下，在指令运行过程中，如果出现网络抖动所导致的超时、指令所针对的服务不可用等异常情况，则可能导致该指令运行失败。不同的指令在运行失败后有不同的处理方式，某些指令运行失败后，不再进行处理，而某些指令运行失败之后，需要对该指令进行重试处理。

目前，在指令运行失败后进行重试处理的重试机制如下：运行指令的第一设备在执行完指令后，如果该指令运行失败，则第一设备会基于该指令的运行情况来判断是否需要对该指令进行重试处理，并且将指令重试处理的判断结果反馈给位于上游的第二设备，例如，将判断结果填入发送给第二设备的指令运行反馈信息的重试字段中来发送给第二设备。第二设备根据重试字段中的判断结果来执行相应的指令重试处理，比如，在重试字段指示需要进行指令重试时，第二设备创建重试指令并发送给第一设备来重新执行所创建的重试指令。

发明内容

鉴于上述，本公开提供了一种指令重试方法及装置，利用该方法及装置，可以在位于运行指令的第一设备上游的第二设备处，使用第一设备需要反馈的针对第一指令的运行反馈信息中的业务特征信息来实现指令重新确定和重试指令创建操作，而无需等待第一设备处的指令重试确定结果，由此避免了第二设备处的指令重试处理对第一设备处的指令重试确定过程的依赖性。

根据本公开的一个方面，提供了一种指令重试方法，包括：从第一设备接收针对第一指令的运行反馈信息，所述运行反馈信息包括返回码和业务特征信息，所述返回码用于表征所述第一指令的运行状态；在所述返回码指示所述第一指令运行失败时，基于所述业务特征信息确定是否需要对所述第一指令执行重试处理；在确定为需要对所述第一指令执行重试处理时，基于所述第一指令来创建第二指令；以及将所创建的第二指令发送给所述第一设备来执行指令重试。

可选地，在上述方面的一个示例中，所述业务特征信息包括业务代码信息以及业务要素特征信息。

可选地，在上述方面的一个示例中，基于所述业务特征信息确定是否需要对所述第一指令执行重试处理包括：在指令重试数据库中存在与所述业务特征信息匹配的指令重试数据时，确定需要对所述第一指令执行重试处理，所述指令重试数据包括业务代码信息和业务要素特征信息。

可选地，在上述方面的一个示例中，基于所述业务特征信息确定是否需要对所述第一指令执行重试处理包括：在指令重试数据库中存在与所述业务特征信息和所述返回码均匹配的指令重试数据时，确定需要对所述第一指令执行重试处理，所述指令重试数据包括返回码、业务代码信息和业务要素特征信息。

可选地，在上述方面的一个示例中，所述指令重试数据中的返回码和业务要素特征信息采用表达式来表征。

可选地，在上述方面的一个示例中，所述指令重试数据还包括重试类型，以及基于所述第一指令来创建第二指令包括：基于所述第一指令和所述重试类型来创建所述第二指令。

可选地，在上述方面的一个示例中，所述重试类型包括下述重试类型中的至少一种：人工重试；系统重试；和延迟重试。

可选地，在上述方面的一个示例中，所述指令重试数据包括优先级信息，基于所述第一指令和所述重试类型来创建所述第二指令包括：在匹配的指令重试数据包括至少两条指令重试数据时，基于所述第一指令和具有最高优先级的指令重试数据的重试类型来创建所述第二指令。

根据本公开的另一方面，还提供一种指令重试装置，包括：信息接收单元被配置为从第一设备接收针对第一指令的运行反馈信息，所述运行反馈信息包括返回码和业务特征信息，所述返回码用于表征所述第一指令的运行状态；重试处理确定单元被配置为在所述返回码指示所述第一指令运行失败时，基于所述业务特征信息确定是否需要对所述第一指令执行重试处理；指令创建单元被配置为在确定为需要对所述第一指令执行重试处理时，基于所述第一指令来创建第二指令；以及，指令发送单元被配置为将所创建的第二指令发送给所述第一设备来执行指令重试。

可选地，在上述方面的一个示例中，所述重试处理确定单元被配置为：在所述返回码指示所述第一指令运行失败并且在指令重试数据库中存在与所述业务特征信息匹配的指令重试数据时，确定需要对所述第一指令执行重试处理，所述指令重试数据包括业务代码信息和业务要素特征信息。。

可选地，在上述方面的一个示例中，所述重试处理确定单元被配置为：在所述返回码指示所述第一指令运行失败并且在指令重试数据库中存在与所述业务特征信息和所述返回码均匹配的指令重试数据时，确定需要对所述第一指令执行重试处理，所述指令重试数据包括返回码、业务代码信息和业务要素特征信息。

可选地，在上述方面的一个示例中，所述指令重试数据中的返回码和业务要素特征信息采用表达式来表征。

可选地，在上述方面的一个示例中，所述指令重试数据还包括重试类型，以及所述指令创建单元被配置为基于所述第一指令和所述重试类型来创建所述第二指令。

可选地，在上述方面的一个示例中，所述指令重试数据包括优先级信息，所述指令创建单元被配置为：在匹配的指令重试数据包括至少两条指令重试数据时，基于所述第一指令和具有最高优先级的指令重试数据的重试类型来创建所述第二指令。

根据本公开的另一方面，还提供一种计算设备，包括：至少一个处理器；以及存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的方法。

根据本公开的另一方面，还提供一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的方法。

附图说明

通过参照下面的附图，可以实现对于本公开内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。附图是用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开的实施例，但并不构成对本公开的实施例的限制。在附图中：

图1示出了根据现有技术的指令重试过程的系统架构示意图；

图2示出了根据本公开的第一实施例的指令重试方法的流程图；

图3示出了根据本公开的第一实施例的指令重试数据的示例的示意图；

图4示出了根据本公开的第二实施例的指令重试方法的流程图；

图5示出了根据本公开的第二实施例的指令重试数据的示例的示意图；

图6示出了根据本公开的第三实施例的指令重试方法的流程图；

图7示出了根据本公开的第三实施例的指令重试数据的示例的示意图；

图8示出了根据本公开的实施例的指令重试装置的方框图；

图9示出了根据本公开实施例的用于指令重试的计算设备的方框图。

具体实施方式

以下将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本公开内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。

如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。

如本文中使用的，术语“指令”是指计算设备发送给处理器的命令，用以告诉计算机从事某一特殊运算。

如本文中使用的，术语“重试”是指针对一条执行过的指令，重新执行与该指令的操作相同的操作。

如本文中使用的，术语“状态机”是指能够根据控制信号按照预先设定的状态进行状态转移，是协调相关信号动作、完成特定操作的控制中心。

图1示出了根据现有技术的指令重试过程的系统架构示意图。如图1所示，第一设备110与第二设备120通信连接，这里，第一设备110可以称为下游设备，第二设备120可以称为上游设备。第二设备120可以创建指令，并且将所创建的指令发送给下游的第一设备110来执行相应的操作。在第一设备110接收到该指令并完成相应的指令运行操作后，向第二设备120反馈相应的运行反馈信息。这里，运行反馈信息是针对指令的运行的反馈，无论第一设备110处的指令运行成功或失败，第一设备110都会向第二设备120反馈运行反馈信息。

在第一设备110运行指令失败的情况下，第一设备110基于指令运行信息来判断是否需要执行指令重试，并且在判断为需要执行指令重试时，向第二设备120发送指令重试消息，例如，将指令重试消息作为运行反馈信息中的重试字段来发送给第二设备120。第二设备120接收到指令重试消息后，启动指令重试程序来创建重试指令，并将所创建的重试指令再次发送给第一设备110来重新执行。

在上述指令重试架构中，在第二设备120处启动指令重试操作需要依赖于第一设备110处的指令重试判断结果。如果第一设备110的指令重试判断模块发生损坏，或者第一设备110和第二设备120之间的通信中断，则即使第一指令运行失败并且需要执行指令重试，第二设备120也由于无法获得重试字段而无法启动指令重试程序。

为了解决上述问题，本公开提供了一种指令重试方法及装置。在该方法及装置中，运行指令的第一设备110向第二设备120反馈的运行反馈信息中包括有返回码和业务特征信息，该返回码用于表征第一指令的运行状态。在返回码指示指令运行失败时，第二设备120基于业务特征信息来确定是否需要对指令执行重试处理，而无需等待第一设备110处执行指令重试确定过程和上传指令重试确定消息，由此避免了第二设备120处的指令重试处理对第一设备110处的指令重试确定过程的依赖性。

下面将结合附图来详细描述根据本公开实施例的指令重试方法及装置。

图2示出了根据本公开的第一实施例的指令重试方法的流程图。

如图2所示，在块210，从第一设备110接收针对第一指令的运行反馈信息。

在本公开中，第一指令可以是针对不同业务的指令，例如，第一指令可以是资金调拨业务的指令、账户查询指令等，在此不做限定。第一指令可以是根据业务进行配置的。

在本公开中，运行反馈信息包括返回码和业务特征信息。返回码用于表征第一指令的运行状态。运行状态可以分为运行成功状态和运行失败状态，运行失败状态可以包括运行超时状态、运行错误状态等。返回码可以是字母、数字、字母和数字的组合等其中任一种形式，例如，超时状态的返回码为E100。每一种运行状态对应至少一个返回码。在本公开中，运行状态与返回码的对应关系可以是预设的。

在本公开中，返回码可以在第一设备110处基于第一指令的运行状态来确定。具体地，第一设备110接收到第二设备120发送的第一指令后，运行第一指令。在运行完第一指令后，第一设备110根据第一指令的运行状态，确定该运行状态对应的返回码。

在本公开的一个示例中，业务特征信息可以包括业务代码信息以及业务要素特征信息。此外，可选地，除了上述两种信息以外，业务特征信息还可以包括其他信息，在此不做限定。

业务代码信息用于表示业务类型，每种业务类型对应一种业务代码信息。业务代码信息与业务类型的对应关系可以是预设的。例如，业务代码信息1000可以表示资金调拨业务。

业务要素特征信息用于表征业务特征信息所对应业务的关键要素信息，业务要素特征信息可以用来区分不同业务类型的业务。例如，资金调拨业务的业务要素特征信息可以包括金额和币种，而余额查询业务的业务要素特征信息可以包括账户信息和金额。

在本公开中，业务特征信息可以在第一设备110处基于第一指令所对应的业务来确定。具体地，在第一设备110处，根据第一指令确定对应的业务，而每一种业务与业务特征信息存在对应关系，该对应关系可以是预先设定的。由此，可以得到与第一指令对应的业务特征信息。

接着，在块220，判断返回码是否指示第一指令运行失败。如果返回码没有指示第一指令运行失败，则流程结束。如果返回码指示第一指令运行失败，则流程进行块230。在块230，基于业务特征信息确定是否需要对第一指令执行重试处理。例如，在业务特征信息包括业务代码信息以及业务要素特征信息的情况下，在返回码指示第一指令运行失败时，可以基于业务代码信息以及业务要素特征信息来确定是否需要对第一指令执行重试处理。

如果在块230中基于业务特征信息确定不需要对第一指令执行重试处理，则流程结束。如果在块230中确定需要对第一指令执行重试处理，则流程进行到块240。在块240，基于第一指令来创建第二指令。

在本公开中，第二指令所针对的业务与第一指令所针对的业务相同，并且，第二指令所执行的操作与第一指令所执行的操作相同。一个示例中，可以基于第一指令中的配置信息，对第二指令进行配置，以使得第二指令所需执行的操作与第一指令相同。

在本公开的一个示例中，可以使用运行标识来区分指令是否被执行，该运行标识设置在指令的配置信息中，这样便于第一设备110基于该运行标识来确认哪些指令是未执行的，哪些指令是已执行的。设备可以仅运行未执行的指令，而对于已执行的指令则可以不处理，由此避免重复运行同一指令而导致计算资源浪费的问题。

在该示例中，第一设备110运行的第一指令可以是由第二设备120创建的，并且第二设备120本地保存有创建的第一指令。在第二设备120需要创建第二指令时，从本地获取第一指令，并基于第一指令来创建第二指令。

具体地，第二设备120在基于第一指令来创建第二指令时，可以从第一指令获取配置信息，并对配置信息中的运行标识进行初始化，使得初始化后的运行标识所指示的指令是未执行的，然后基于配置信息来配置第二指令。这样，使得新创建的第二指令与第一指令所执行的操作相同，并且避免了新创建的第二指令因为运行标识而被第一设备110确认为已执行的指令，进而不能被第一设备110执行的问题。

在本公开的一个示例中，可以为每一指令设置对应的状态机，状态机可以用于指示所对应的指令的状态。例如，第一指令在第一设备110处运行完后，第一指令的状态机指示为终止状态。第二设备120创建第二指令后，第二指令的状态机指示为初始状态。

在创建第二指令之后，在块250，将所创建的第二指令发送给第一设备来执行指令重试。

第一设备110接收到第二指令后，运行该第二指令，即，执行指令重试。

通过本公开提供的指令重试方法及装置，可以在位于运行指令的第一设备110上游的第二设备120处，使用第一设备110需要反馈的针对第一指令的运行反馈信息中的业务特征信息来实现指令重新确定和重试指令创建操作，而无需等待第一设备110处的指令重试确定结果，由此避免了第二设备120处的指令重试处理对第一设备110处的指令重试确定过程的依赖性。

在本公开的一个示例中，在第二设备120处，可以设置有指令重试数据库，该指令重试数据库包括至少一条指令重试数据，每条指令重试数据包括业务特征信息。相应地，基于业务特征信息来确定是否需要对第一指令执行重试处理可以包括：在指令重试数据库中查找是否存在与从第一设备110接收的业务特征信息匹配的指令重试数据。如果在指令重试数据库中存在与业务特征信息匹配的指令重试数据，则确定需要对第一指令执行重试处理。如果在指令重试数据库中不存在与业务特征信息匹配的指令重试数据，则确定不需要对第一指令执行重试处理。

在进行匹配的一个示例中，将业务特征信息中的业务代码信息和业务要素特征信息，分别与每一指令重试数据所包括的业务代码信息和业务要素特征信息进行匹配。

例如，第一指令所针对的业务是资金调拨业务，业务特征信息中的业务代码信息为1000，业务要素特征信息中的金额为100，币种为CNY(Chinese Yuan，人民币)，指令重试数据库中存在一个指令重试数据所包括的业务代码信息为1000，业务要素特征信息中币种为CNY，金额为小于1000。那么，该业务特征信息与该指令重试数据是相匹配的。

匹配的结果包括以下三种：第一种结果，在指令重试数据库中不存在与业务特征信息匹配的指令重试数据；第二种结果，在指令重试数据库中存在一个与业务特征信息匹配的指令重试数据；第三种结果，在指令重试数据库中存在至少两个与业务特征信息匹配的指令重试数据。在第一种结果的情况下，则可以认为匹配失败，此时可以不用对第一指令执行重试处理。在第二种结果和第三种结果的情况下，则可以认为匹配成功，则确定需要对第一指令执行重试处理。

在本公开的另一示例中，指令重试数据可以包括返回码和业务特征信息。相应地，基于业务特征信息来确定是否需要对第一指令执行重试处理可以包括：在指令重试数据库中查找是否存在与从第一设备110接收的返回码和业务特征信息均匹配的指令重试数据。如果在指令重试数据库中存在与返回码和业务特征信息均匹配的指令重试数据，则确定需要对第一指令执行重试处理。如果在指令重试数据库中不存在与返回码和业务特征信息均匹配的指令重试数据，则确定不需要对第一指令执行重试处理。

在本公开的一个示例中，指令重试数据中的返回码和业务要素特征信息可以采用表达式来表征。图3示出了根据本公开的第一实施例的指令重试数据的示例的示意图。

如图3所示，Id表示指令重试数据的标识，Trans_code表示业务代码信息，Express表示用于表征业务要素特征信息和返回码的表达式。对于Id为1的数据来说，指令重试数据中返回码为E100，业务要素特征信息包括的币种为CNY，金额为小于1000，则采用表达式的方式来表征为：Code＝“E100”and currency＝“CNY”and amount<1000。对于Id为2的数据来说，指令重试数据中返回码为E200，账户为abc，金额为大于100，则采用表达式的方式来表征为：Code＝“E200”and account＝“abc”and amount>100。

在本公开的一个示例中，当指令重试数据中的返回码和业务要素特征信息采用表达式来表征时，表达式可以采用开源的表达式引擎。

采用表达式的方式来表征返回码和业务要素特征信息，可以在对返回码和业务特征信息进行匹配时，直接将运行反馈信息中的返回码和业务要素特征信息输入至表达式，该表达式即可输出相应的匹配结果。这样，简化了运行反馈信息与指令重试数据的匹配过程，提高了匹配效率。

图4示出了根据本公开的第二实施例的指令重试方法的流程图。图4中所示的实施例是上述图2示出的实施例的修改实施例。

在图4中示出的实施例中，指令重试数据库中的每一指令重试数据还包括重试类型，每一指令重试数据中的重试类型可以是预先设置的。重试类型用于表示创建第二指令的方式，例如，与运行反馈信息中的返回码和业务特征信息均匹配的指令重试数据所包括的重试类型为系统重试，则通过系统重试的方式来创建第二指令。

在本公开的一个示例中，重试类型可以包括人工重试、系统重试和延迟重试中的至少一种。除了上述三种以外，还可以包括其他的重试类型，在此不做限定。

在本公开中，人工重试是指执行指令重试的过程中需要人工介入的重试方式。例如，在确定需要对第一指令执行重试处理后，基于第一指令所包括的配置信息来手动对第二指令的配置信息进行设置。在本公开中，系统重试是指执行指令重试的过程中由设备自身完成的重试方式。在本公开中，延迟重试是指推迟进行系统重试的时间，延迟重试可以包括合并重试和梯度重试。

合并重试是指当需要重试的指令的数量达到预设指令数量阈值时再对需要重试的指令执行重试处理，预设指令数量阈值可以是预设的。例如，预设指令数量阈值为10，当需要重试的指令数量小于10时，对这些需要重试的指令不进行重试处理，只有当需要重试的指令数量达到10时，则对该10个需要重试的指令执行重试处理。

梯度重试是指对需要重试的指令设置重试时间，重试时间可以是时长，还可以是时间点，当达到该重试时间后再对指令执行重试处理。例如，在确定需要对第一指令执行重试处理后，设定重试时间为12点，则在到达12点前不会对该第一指令执行重试处理，当到达12点时对该第一指令执行重试处理。

图5示出了根据本公开的第二实施例的指令重试数据的示例的示意图。如图5所示，在上述图3所示的数据结构的基础上，指令重试数据还包括重试类型的字段，Type表示重试类型。图5所示的Id为1的指令重试数据中的重试类型为manual，即人工重试；Id为2的指令重试数据中的重试类型为system，即系统重试。

通过设置不同的重试类型，可以为指令重试提供更多的重试类型的选择。并且可以根据业务类型、业务要素特征信息等来设置重试类型，提高指令重试的成功率。

下面结合图4来描述根据本公开的第二实施例的指令重试过程。

在图4中示出的实施例中，块410、块420以及块450的操作分别与图2中的块210、块220以及块250相同，在此不再描述。下面仅仅对不同之处进行详细描述。

在块420中判断为第一指令运行失败时，在块430，判断在指令重试数据库中是否存在匹配的指令重试数据。如果判断出指令重试数据库中不存在匹配的指令重试数据，则流程结束。如果判断出指令重试数据库中存在匹配的指令重试数据，则流程进行块440。

在块440，基于第一指令和重试类型来创建第二指令。具体地，在判断出指令重试数据库中存在匹配的指令重试数据(即，确定需要对第一指令执行重试处理)后，可以从匹配的指令重试数据中获取重试类型，然后基于所获取的重试类型和第一指令来创建第二指令。

在本公开的第二实施例中，基于重试类型的多样性，可以有多种方式以供选择来执行指令重试处理。并且，可以根据每一指令重试数据所针对的业务，来合理地设置该业务对应的重试类型。例如，对于涉及用户体验的业务，为了减少指令重试的耗时，可以将重试类型设置为系统重试。而对于用时要求不太高的业务，则可以将重试类型设置为延迟重试。

在本公开中，在指令创建时需要使用处理器，不同的重试类型可以使用同一处理器，还可以使用不同的处理器。

在不同的重试类型使用不同的处理器的情况下，每一种重试类型对应至少一个处理器，各重试类型对应的处理器不相同。具体地，在确定出重试类型后，基于重试类型与处理器的对应关系，可以确定出用于创建第二指令的处理器，利用所确定的处理器来执行创建第二指令的操作。

对于不同的重试类型，对处理器的要求会有所不同。例如，人工重试时会有人工介入，因此在创建第二指令的过程中对处理器的处理能力的要求相对较低。系统重试时由处理器启动并完成整个创建第二指令的流程，因此对处理器的处理能力的要求较高。延迟重试时需要设定重试的触发时机，因此需要处理器具有计时或计数的功能。因此，基于各重试类型对处理器的不同需求，为每一种重试类型设置相应的处理器，这样按需分配处理器资源，避免浪费处理器资源，并提高处理器资源的利用率。

图6示出了根据本公开的第三实施例的指令重试方法的流程图。图6中所示的实施例是上述图4示出的实施例的修改实施例。

在图6示出的实施例中，指令重试数据库中的每一指令重试数据还包括优先级信息。每一指令重试数据中的优先级信息可以是预先设置的，不同的指令重试数据的优先级信息可以是不同的。

图7示出了根据本公开的第三实施例的指令重试数据的示例的示意图。如图7所示，在上述图5所示的数据结构的基础上，指令重试数据还包括优先级信息的字段，Priority表示优先级信息。图7所示的Id为1的指令重试数据中的优先级信息为10；Id为2的指令重试数据中的优先级信息为5。

通过为每一个指令重试数据设置优先级信息，即使匹配出多种重试类型的情况下，也可以基于优先级信息确定出一个重试类型，并且所确定出的重试类型是针对业务特征信息的较佳的重试类型，通过该较佳的重试类型来创建第二指令，可以提高效率。

下面结合图6来描述根据本公开的第三实施例的指令重试过程。

在图6中示出的实施例中，块610、块620、块630以及块670的操作分别与图4中的块410、块420、块430以及块450相同，在此不再描述。下面仅仅对不同之处进行详细描述。

在块620中判断为第一指令运行失败时，在块630，判断在指令重试数据库中是否存在匹配的指令重试数据。如果判断出指令重试数据库中不存在匹配的指令重试数据，则流程结束。如果判断出指令重试数据库中存在匹配的指令重试数据，则流程进行块640。

在块640，判断匹配的指令重试数据是否包括至少两条指令重试数据。如果判断出匹配的指令重试数据不包括至少两条指令重试数据，即匹配的指令重试数据仅一条，则流程进行块650。如果判断出匹配的指令重试数据包括至少两条指令重试数据，则流程进行块660。

在块650，基于第一指令和匹配的指令重试数据的重试类型来创建第二指令。

在块660，基于第一指令和具有最高优先级的指令重试数据的重试类型来创建第二指令。

在本公开的一个示例中，若匹配的至少两条指令重试数据的重试类型相同，则可以直接基于该相同的重试类型和第一指令来创建第二指令。若匹配的至少两条指令重试数据中存在至少两种重试类型，则确定出优先级最高的一个指令重试数据，并基于该指令重试数据的重试类型和第一指令来创建第二指令。

例如，匹配的指令重试数据包括指令重试数据1、指令重试数据2和指令重试数据3。指令重试数据1的重试类型为人工重试，指令重试数据2的重试类型为系统重试，指令重试数据3的重试类型为延迟重试。指令重试数据1的优先级为2，指令重试数据2的优先级为5，指令重试数据3的优先级为10。针对优先级，数值越小优先级越高，那么，具有最高优先级的指令重试数据为指令重试数据1。这样，基于第一指令和指令重试数据1的重试类型来创建第二指令。

通过本公开的第三实施例，为每一指令重试数据设置优先级，即使匹配出多个指令重试数据，也可以将最高优先级的指令重试数据的重试类型确定为用于创建第二指令的重试类型。避免了在得到多种重试类型的情况下不能进一步确定出用于创建第二指令的重试类型的问题。

图8示出了根据本公开的实施例的指令重试装置800的方框图。如图8所示，指令重试装置800包括信息接收单元810，重试处理确定单元820，指令创建单元830和指令发送单元840。

信息接收单元810被配置为从第一设备110接收针对第一指令的运行反馈信息，运行反馈信息包括返回码和业务特征信息，返回码用于表征第一指令的运行状态。在本公开的一个示例中，业务特征信息包括业务代码信息以及业务要素特征信息。信息接收单元810所执行的操作可以参考上面参照图2描述的块210的操作。

重试处理确定单元820被配置为在返回码指示第一指令运行失败时，基于业务特征信息确定是否需要对第一指令执行重试处理。在本公开的一个示例中，重试处理确定单元820被配置为在返回码指示第一指令运行失败并且在指令重试数据库中存在与业务特征信息匹配的指令重试数据时，确定需要对第一指令执行重试处理，指令重试数据包括业务代码信息和业务要素特征信息。在本公开的一个示例中，重试处理确定单元820被配置为在返回码指示第一指令运行失败并且在指令重试数据库中存在与业务特征信息和返回码均匹配的指令重试数据时，确定需要对第一指令执行重试处理，指令重试数据包括返回码、业务代码信息和业务要素特征信息。在本公开的一个示例中，指令重试数据中的业务要素特征信息包括采用表达式表征的业务要素特征信息，和/或，指令重试数据中的返回码包括采用表达式表征的返回码。重试处理确定单元820所执行的操作可以参考上面参照图2描述的块220和块230的操作。

指令创建单元830被配置为在确定为需要对第一指令执行重试处理时，基于第一指令来创建第二指令。在本公开的一个示例中，指令重试数据还包括重试类型，指令创建单元830被配置为基于第一指令和重试类型来创建第二指令。在本公开的一个示例中，重试类型包括人工重试、系统重试和延迟重试中的至少一种。在本公开的一个示例中，指令重试数据包括优先级信息，指令创建单元830被配置为在与业务特征信息匹配的指令重试数据包括至少两条指令重试数据时，基于第一指令和具有最高优先级的指令重试数据的重试类型来创建第二指令。指令创建单元830所执行的操作可以参考上面参照图2描述的块240的操作，图4描述的块440的操作以及图6描述的块640的操作。

指令发送单元840被配置为将所创建的第二指令发送给第一设备110来执行指令重试。指令发送单元840所执行的操作可以参考上面参照图2描述的块250的操作。

以上参照图1到图8，对根据本公开的指令重试方法及装置的实施例进行了描述。

本公开的指令重试装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将存储器中对应的计算机程序指令读取到内存中运行形成的。在本公开中，指令重试装置例如可以利用计算设备实现。

图9示出了根据本公开实施例的用于指令重试的计算设备900的方框图。如图9所示，计算设备900可以包括至少一个处理器910、存储器920、内存930和通信接口940，并且至少一个处理器910、存储器920、内存930和通信接口940经由总线960连接在一起。至少一个处理器910执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器910：从第一设备110接收针对第一指令的运行反馈信息，运行反馈信息包括返回码和业务特征信息，返回码用于表征第一指令的运行状态；在返回码指示第一指令运行失败时，基于业务特征信息确定是否需要对第一指令执行重试处理；在确定为需要对第一指令执行重试处理时，基于第一指令来创建第二指令；以及将所创建的第二指令发送给第一设备110来执行指令重试。

应该理解，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器910进行本公开的各个实施例中以上结合图1-8描述的各种操作和功能。

根据一个实施例，提供了一种例如机器可读介质的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本公开的各个实施例中以上结合图1-8描述的各种操作和功能。

具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

以上结合附图详细描述了本公开的实施例的可选实施方式，但是，本公开的实施例并不限于上述实施方式中的具体细节，在本公开的实施例的技术构思范围内，可以对本公开的实施例的技术方案进行多种简单变型，这些简单变型均属于本公开的实施例的保护范围。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (15)

1.一种指令重试方法，包括：

从第一设备接收针对第一指令的运行反馈信息，所述运行反馈信息包括返回码和业务特征信息，所述返回码用于表征所述第一指令的运行状态，所述运行状态包括运行成功状态和运行失败状态，所述业务特征信息包括业务代码信息以及业务要素特征信息，所述业务代码信息用于表示业务类型，所述业务要素特征信息用于表征业务特征信息所对应的关键要素信息，所述关键要素信息用于区分不同业务类型的业务；

在所述返回码指示所述第一指令运行失败时，基于所述业务特征信息确定是否需要对所述第一指令执行重试处理；

在确定为需要对所述第一指令执行重试处理时，基于所述第一指令来创建第二指令；以及

将所创建的第二指令发送给所述第一设备来执行指令重试。

2.如权利要求1所述的指令重试方法，其中，基于所述业务特征信息确定是否需要对所述第一指令执行重试处理包括：

在指令重试数据库中存在与所述业务特征信息匹配的指令重试数据时，确定需要对所述第一指令执行重试处理，所述指令重试数据包括业务代码信息和业务要素特征信息。

3.如权利要求2所述的指令重试方法，其中，基于所述业务特征信息确定是否需要对所述第一指令执行重试处理包括：

在指令重试数据库中存在与所述业务特征信息和所述返回码均匹配的指令重试数据时，确定需要对所述第一指令执行重试处理，所述指令重试数据包括返回码、业务代码信息和业务要素特征信息。

4.如权利要求3所述的指令重试方法，其中，所述指令重试数据中的返回码和业务要素特征信息采用表达式来表征。

5.如权利要求2或3所述的指令重试方法，其中，所述指令重试数据还包括重试类型，以及

基于所述第一指令来创建第二指令包括：

基于所述第一指令和所述重试类型来创建所述第二指令。

6.如权利要求5所述的指令重试方法，其中，所述重试类型包括下述重试类型中的至少一种：

人工重试；

系统重试；和

延迟重试。

7.如权利要求5所述的指令重试方法，其中，所述指令重试数据包括优先级信息，基于所述第一指令和所述重试类型来创建所述第二指令包括：

在匹配的指令重试数据包括至少两条指令重试数据时，基于所述第一指令和具有最高优先级的指令重试数据的重试类型来创建所述第二指令。

8.一种指令重试装置，包括：

信息接收单元，被配置为从第一设备接收针对第一指令的运行反馈信息，所述运行反馈信息包括返回码和业务特征信息，所述返回码用于表征所述第一指令的运行状态，所述运行状态包括运行成功状态和运行失败状态，所述业务特征信息包括业务代码信息以及业务要素特征信息，所述业务代码信息用于表示业务类型，所述业务要素特征信息用于表征业务特征信息所对应的关键要素信息，所述关键要素信息用于区分不同业务类型的业务；

重试处理确定单元，被配置为在所述返回码指示所述第一指令运行失败时，基于所述业务特征信息确定是否需要对所述第一指令执行重试处理；

指令创建单元，被配置为在确定为需要对所述第一指令执行重试处理时，基于所述第一指令来创建第二指令；以及

指令发送单元，被配置为将所创建的第二指令发送给所述第一设备来执行指令重试。

9.如权利要求8所述的指令重试装置，其中，所述重试处理确定单元被配置为：

在所述返回码指示所述第一指令运行失败并且在指令重试数据库中存在与所述业务特征信息匹配的指令重试数据时，确定需要对所述第一指令执行重试处理，所述指令重试数据包括业务代码信息和业务要素特征信息。

10.如权利要求9所述的指令重试装置，其中，所述重试处理确定单元被配置为：

在所述返回码指示所述第一指令运行失败并且在指令重试数据库中存在与所述业务特征信息和所述返回码均匹配的指令重试数据时，确定需要对所述第一指令执行重试处理，所述指令重试数据包括返回码、业务代码信息和业务要素特征信息。

11.如权利要求10所述的指令重试装置，其中，所述指令重试数据中的返回码和业务要素特征信息采用表达式来表征。

12.如权利要求10或11所述的指令重试装置，其中，所述指令重试数据还包括重试类型，以及

所述指令创建单元被配置为：

基于所述第一指令和所述重试类型来创建所述第二指令。

13.如权利要求12所述的指令重试装置，其中，所述指令重试数据包括优先级信息，所述指令创建单元被配置为：

在匹配的指令重试数据包括至少两条指令重试数据时，基于所述第一指令和具有最高优先级的指令重试数据的重试类型来创建所述第二指令。

14.一种计算设备，包括：

至少一个处理器，以及

与所述至少一个处理器耦合的存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求1到7中任一所述的方法。

15.一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求1到7中任一所述的方法。

Images