业务请求重试方法、系统、计算机设备及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种业务请求重试方法、系统、计算机设备及存储介质。

背景技术

在互联网金融行业中，为了提高商品交易总额(Gross Merchandise Volume，GMV)，需要对不同的客户群体构建对应的营销策略。营销策略对应的流程中有多个节点参与执行，每个节点都有自己单独的逻辑，例如，有些逻辑是过滤用户，有些则是触达用户等。

在高并发的系统中，业务处理系统会存在一些节点由于负载过大等问题导致节点在处理请求时出现处理异常的情况，从而导致一些流程在执行过程中由于当前调用的节点异常而中断执行，系统稳定性差。故现亟需一种方法，可以提高系统的稳定性。

发明内容

本申请实施例提供了一种业务请求重试方法、系统、计算机设备及存储介质，可以提高业务处理系统的稳定性。

第一方面，本申请实施例提供了一种业务请求重试方法，其包括：

当监测到业务处理系统中的目标节点执行目标业务请求异常时，从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长，所述节点配置文件中存储有所述业务处理系统中多个节点中各节点分别对应的重试间隔时长；

确定所述目标重试间隔时长是否大于预设的间隔时长阈值；

若所述目标重试间隔时长小于或等于所述间隔时长阈值，则将所述目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中；当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求；

若所述目标重试间隔时长大于所述间隔时长阈值，则将所述目标业务请求存储至数据库中，所述数据库为本地数据库；当所述目标业务请求在所述数据库中的存储时长到达所述重试间隔时长时，发送所述数据库中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求。

第二方面，本申请实施例还提供了一种业务请求重试系统，其包括：

收发单元，用于获取目标业务请求；

处理单元，用于当监测到业务处理系统中的目标节点执行所述目标业务请求异常时，从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长，所述节点配置文件中存储有所述业务处理系统中多个节点中各节点分别对应的重试间隔时长；确定所述目标重试间隔时长是否大于预设的间隔时长阈值；若所述目标重试间隔时长小于或等于所述间隔时长阈值，则将所述目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中；当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，通过所述收发单元发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求；若所述目标重试间隔时长大于所述间隔时长阈值，则将所述目标业务请求存储至数据库中，所述数据库为本地数据库；当所述目标业务请求在所述数据库中的存储时长到达所述重试间隔时长时，通过所述收发单元发送所述数据库中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求。

第三方面，本申请实施例还提供了一种计算机设备，所述计算设备中部署有业务请求重试系统，其包括存储器及处理器，所述存储器上存储有计算机程序，所述处理器执行所述计算机程序时实现上述方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时可实现上述方法。

本申请实施例提供了一种业务请求重试方法、系统、计算机设备及存储介质。第一方面，由于本申请在监测到目标节点执行目标业务请求发生异常时，在目标节点对应的重试间隔时长之后会重新发送该目标业务请求至该目标节点进行重试处理，一般情况下，在目标节点对应的异重试间隔时长内，节点情况会从异常恢复为正常，所以在目标节点中对目标业务请求进行重试处理，可以避免流程在目标节点中中断处理，从而提高节点所在系统的稳定性；第二方面，本实施例会根据目标节点目标重试间隔时长的长短将目标业务请求存储到不同的位置，将重试间隔时长较短的请求直接存储到消息队列(延迟队列)中，将重试间隔时长较长的请求存储到数据库中，避免将全部异常的请求都持久化存储到数据库中，减少数据库对磁盘容量的占用，节约存储资源；第三方面，本实施例中的用户可以在节点配置文件中设置不同节点的重试间隔时长，即可以配置化对重试机制的参数进行调整，不需要通过发版调整，从而通过本申请可以更加灵活地对重试机制的参数进行调整。

附图说明

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

图1为本申请实施例提供的业务请求重试方法的应用场景示意图；

图2为本申请实施例提供的业务请求重试方法的流程示意图；

图3为本申请实施例提供的业务请求重试系统的示意性框图；

图4为本申请实施例提供的计算机设备的示意性框图。

具体实施方式

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

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

本申请实施例提供了一种业务请求重试方法、系统、计算机设备及存储介质。

该业务请求重试方法的执行主体可以是本申请实施例提供的业务请求重试系统，或者集成了该业务请求重试系统的计算机设备，其中，该业务请求重试系统可以采用硬件或者软件的方式实现，该计算机设备可以为终端或服务器。

具体地，该业务请求重试系统用于对业务处理系统中的请求进行异常重试处理，当业务处理系统中由于某节点发生异常导致处理目标业务请求失败时，此时，需要通过业务请求重试系统对该目标业务请求进行重试处理，以避免请求中断处理。

请参阅图1，图1为本申请实施例提供的业务请求重试方法的应用场景示意图。该业务请求重试方法应用于图1中的业务请求重试系统10中，当该业务请求重试系统10当监测到业务处理系统20中的目标节点执行目标业务请求异常时，从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长，所述节点配置文件中存储有所述业务处理系统中多个节点中各节点分别对应的重试间隔时长；确定所述目标重试间隔时长是否大于预设的间隔时长阈值；若所述目标重试间隔时长小于或等于所述间隔时长阈值，则将所述目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中；当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求；若所述目标重试间隔时长大于所述间隔时长阈值，则将所述目标业务请求存储至数据库中；当所述目标业务请求在所述数据库中的存储时长到达所述重试间隔时长时，发送所述数据库中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求。

图2是本申请实施例提供的业务请求重试方法的流程示意图。如图2所示，该方法包括以下步骤S110-S160。

S110、当监测到业务处理系统中的目标节点执行目标业务请求异常时，从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长。

本实施例中，所述节点配置文件中存储有所述业务处理系统中多个节点中各节点分别对应的重试间隔时长，该重试间隔时长为可以重新在对应节点上执行请求的时间间隔，由于每个节点从异常恢复到正常的时间间隔不同，所以本实施例需要为不同的节点设置不同的重试间隔时长。

其中，本实施例中目标节点执行目标业务请求异常，具体可以为业务处理系统在执行目标业务请求时，执行目标节点，目标节点调用外部接口异常。

在一些实施例中，该目标业务请求可以为目标营销策略的执行请求，目标营销策略包括策略的执行节点以及每个执行节点的执行数据。

其中，目标业务请求需要通过业务处理系统中的至少一个节点进行处理，至少一个节点包括目标节点，该目标节点为业务处理系统当前执行的用于处理该目标业务请求的节点。

在一些实施例中，业务请求重试系统可以通过接收业务处理系统的节点异常信息监测目标节点在执行目标业务请求时是否发生异常，此时，步骤S110包括：接收所述业务处理系统发送的节点异常信息，所述节点异常信息包括所述目标节点的目标节点标识以及所述目标业务请求；根据所述目标节点标识从所述节点配置文件中获取所述目标重试间隔时长。

具体地，本实施例中的目标业务请求携带有上下文信息，该上下文信息包括目标业务请求的执行过程信息，上述节点异常信息中的目标节点标识可以包含在目标业务请求的上下文信息中，该目标节点标识用于指示业务处理系统中的中断节点(即目标节点)，以及读取与目标节点对应的目标重试间隔时长。

在另一些实施例中，业务请求重试系统还可以在业务处理系统中部署监控脚本，通过该监控脚本监控业务处理系统中是否有节点在执行目标业务请求时异常。

在一些实施例中，所述从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长之前，所述方法还包括：从所述目标业务请求的上下文信息中获取所述目标节点的重试次数；判断所述重试次数是小于所述目标节点对应的最大重试次数。当判断该重试次数小于对应的最大重试次数，才进一步从所述节点配置文件中获取所述目标重试间隔时长。其中，节点配置文件中还存储有业务处理系统中各节点分别对应的最大重试次数，此时，业务请求重试系统从该节点配置文件中获取该目标节点对应的最大重试次数。

例如，当监测到业务处理系统中的目标节点执行目标业务请求异常时，会先从节点配置文件中读取目标节点对应的最大重试次数，并从目标业务请求的上下文信息中提取目标节点对应的重试次数(即目标业务请求已经在目标节点上执行过的次数)，若最大重试次数小于目标业务请求在目标节点上的重试次数时，此时，允许目标业务请求在目标节点上再进行重试，例如，最大重试次数为3次，从上下文信息中提取的重试次数为2次，此时，可以在目标节点上再对该目标业务请求进行重试处理。

若所述重试次数大于或等于所述最大重试次数，则中断执行所述目标业务请求。

例如，获取到的重试次数为3次，最大重试次数也为3次，此时，说明目标业务请求在目标节点上的重试次数已经到达最大重试次数，此时需要中断执行所述目标业务请求，并介入人工处理。

S120、确定所述目标重试间隔时长是否大于预设的间隔时长阈值；若否，则执行步骤S130-S140；若是，则执行步骤S150-S160。

本实施例中，可以为业务处理系统中的每个节点设置同一个间隔时长阈值，也可以为不同的节点分别设置一个间隔时长阈值，该间隔时长阈值可以设置在节点配置文件中。

其中，本实施例判断目标重试间隔时长是否大于预设的间隔时长阈值的目的是为了对目标业务请求进行不同的处理，若所述目标重试间隔时长小于或等于所述间隔时长阈值，则将该目标业务请求存储在消息队列中，若大于所述间隔时长阈值，则将该目标业务请求存储在数据库中。

对于突发场景，并发量较高的延迟重试，如果将重试请求一次性全放到数据库中，不仅对数据库负载高，而且存储的数据也比较大，通过消息队列实现可以避免不必要的资源浪费，又可以使得系统的可用性提高，但是由于消息队列的延迟消息的最大延迟时间有限制，所以针对需要延迟较久时间重试的场景就需要再通过数据库对重试请求进行持久化。

其中，本实施例中的延迟队列可以使用RocketMQ(一款纯java、分布式、队列模型的开源消息中间件)。

S130、将所述目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中。

本实施例中，若所述目标重试间隔时长小于或等于所述间隔时长阈值，则将该目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中，具体地，可以将该目标业务请求的上下文信息存储至该目标延迟队列中，后续基于该上下文信息对请求进行重试。

具体地，在一些实施例中，所述将所述目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中之前，所述方法还包括：从预设的多个消息延迟队列中确定与所述目标重试间隔时长对应的所述目标延迟队列。

即，本实施例的业务请求重试系统中存在多条对应不同延迟时间的消息延迟队列，将延迟时间与目标重试间隔相同或者时间最接近的队列确定为目标延迟队列。

例如，存在延迟时间分别为3分钟、5分钟以及10分钟的消息延迟队列，但获取到的目标重试间隔时长为5分钟时，需要将延迟时间为5分钟的消息延迟队列确定为目标延迟队列，保证消息的顺序消费。

在另一些实施例中，业务请求重试系统中包括一个目标延迟队列，此时，需要将目标业务请求以及对应的重试时间间隔存储到目标延迟队列中，由目标延迟队列根据对应的重试时间间隔判断重试时间间隔的存储时长是否到达重试时间间隔。

S140、当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求。

本实施例中，当目标延迟队列中的目标业务请求在目标延迟队列中的存储时长到达目标重试间隔时长时，将该目标业务请求发送至业务处理系统，使得业务处理系统通过目标节点对该请求进行重试处理。

其中，不同的消息队列可以对应不同的延迟时间，例如，目标延迟队列对应的延迟时间为5分钟，此时，目标业务请求在目标延迟队列中的存储时长到达5分钟时，则将该目标业务请求发送给目标节点。具体地，业务请求重试系统将该目标业务请求发送至业务处理系统，然后业务处理系统再进一步根据目标业务请求中的上下文信息找到之前中断的节点(即目标节点)继续执行。

具体地，在一些实施例中，所述当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统，包括：

当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，将所述目标业务请求发送至实时队列中；通过所述实时队列发送所述目标业务请求至所述业务处理系统。

具体地，业务处理系统为实时队列的消费者，即业务处理系统与实时队列之间有通信接口，不同延迟时长的延迟队列中的信息到达延迟时间后，都将到达时间的信息发送给实时队列，通过实时队列将目标业务请求发送给实时队列时，不同延迟时长的延迟队列共用同一个实时队列，从而减少队列与业务处理系统之间通信接口的数量。

本实施例通过消息队列进行数据存储，不需要对数据进行持久化，可以节省磁盘的存储资源。

S150、将所述目标业务请求存储至数据库中。

本实施例中，若所述目标重试间隔时长大于所述间隔时长阈值，则通过数据库持久化所述目标业务请求，解决了消息队列对最大延迟时间有间隔的限制，其中，该数据库可以为本地数据库。

具体地，可以将该目标业务请求对应的上下文信息存储至数据库中，同时存储的还有对应的目标重试间隔时长以及进入数据库的存储时间。

S160、当所述目标业务请求在所述数据库中的存储时长到达所述重试间隔时长时，发送所述数据库中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求。

本实施例的数据库配合有数据库扫描脚本，该数据库扫描脚本用于根据预设的时间间隔(例如每隔10分钟)扫描数据库，确定数据库中是否存在到达重试时间的业务请求，若有，则发送该业务请求至对应的节点进行重试处理。

具体地，在一些实施例中，步骤S160具体通过步骤实现：

通过预设的数据库扫描脚本扫描所述数据库，获取所述目标业务请求的所述存储时长；判断所述存储时长是否大于或等于所述重试时间间隔；若所述存储时长大于或等于所述重试时间间隔，则发送所述目标业务请求至所述业务处理系统进行重试处理。

具体地，业务请求重试系统将该目标业务请求发送至业务处理系统，然后业务处理系统再进一步根据目标业务请求中的上下文信息找到之前中断的节点继续执行。

在一些实施例中，用户可以修改(包括新增、删除或调整)节点配置文件中节点的重试间隔时长，此时，方法还包括：获取针对多个所述节点中指定节点的重试间隔时长修改指令；根据所述重试间隔时长修改指令修改所述节点配置文件中所述指定节点的重试间隔时长。

通过调整重试间隔时长可以调整数据库以及消息队列的负载。

同理，用户可以修改节点配置文件中节点的最大重试次数，此时，方法还包括：获取针对多个所述节点中指定节点的最大重试次数修改指令；根据所述最大重试次数指令修改所述节点配置文件中所述指定节点的最大重试次数。

可见，通过本实施例可以配置化实现重试机制的参数(重试间隔时长以及最大重试次数)，动态控制负载，提高系统的可用性和稳定性。

综上所述，第一方面，由于本申请在监测到目标节点执行目标业务请求发生异常时，在目标节点对应的重试间隔时长之后会重新发送该目标业务请求至该目标节点进行重试处理，一般情况下，在目标节点对应的异重试间隔时长内，节点情况会从异常恢复为正常，所以在目标节点中对目标业务请求进行重试处理，可以避免流程在目标节点中中断处理，从而提高节点所在系统的稳定性；第二方面，本实施例会根据目标节点目标重试间隔时长的长短将目标业务请求存储到不同的位置，将重试间隔时长较短的请求直接存储到消息队列中，将重试间隔时长较长的请求存储到数据库中，避免将全部异常的请求都持久化存储到数据库中，减少数据库对磁盘容量的占用，节约存储资源；第三方面，本实施例中的用户可以在节点配置文件中设置不同节点的重试间隔时长，即可以配置化对重试机制的参数进行调整，不需要通过发版调整，从而通过本申请可以更加灵活地对重试机制的参数进行调整。

图3是本申请实施例提供的一种业务请求重试系统的示意性框图。如图3所示，对应于以上业务请求重试方法，本申请还提供一种业务请求重试系统。该业务请求重试系统包括用于执行上述业务请求重试方法的单元。具体地，请参阅图3，该业务请求重试系统300包括收发单元301以及处理单元302，其中：

收发单元301，用于获取目标业务请求；

处理单元302，用于当监测到业务处理系统中的目标节点执行所述目标业务请求异常时，从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长，所述节点配置文件中存储有所述业务处理系统中多个节点中各节点分别对应的重试间隔时长；确定所述目标重试间隔时长是否大于预设的间隔时长阈值；若所述目标重试间隔时长小于或等于所述间隔时长阈值，则将所述目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中；当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，通过所述收发单元301发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求；若所述目标重试间隔时长大于所述间隔时长阈值，则将所述目标业务请求存储至数据库中，所述数据库为本地数据库；当所述目标业务请求在所述数据库中的存储时长到达所述重试间隔时长时，通过所述收发单元301发送所述数据库中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求。

在一些实施例中，所述处理单元302在执行所述当所述目标业务请求在所述数据库中的存储时长到达所述重试间隔时长时，通过所述收发单元301发送所述数据库中的所述目标业务请求至所述业务处理系统，具体用于：

通过预设的数据库扫描脚本扫描所述数据库，获取所述目标业务请求的所述存储时长；判断所述存储时长是否大于或等于所述重试时间间隔；若所述存储时长大于或等于所述重试时间间隔，则通过所述收发单元301发送所述目标业务请求至所述业务处理系统。

在一些实施例中，所述处理单元302在执行所述当监测到业务处理系统中的目标节点执行目标业务请求异常之后，且所述从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长步骤之前，还用于：

从所述目标业务请求的上下文信息中获取所述目标节点的重试次数；判断所述重试次数是小于所述目标节点对应的最大重试次数；

此时，所述处理单元302在执行所述从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长步骤时，具体用于：

若所述重试次数小于所述最大重试次数，则从所述节点配置文件中获取所述目标重试间隔时长。

在一些实施例中，所述处理单元302在执行所述判断所述重试次数是否小于所述目标节点对应的最大重试次数步骤之后，还用于：

若所述重试次数大于或等于所述最大重试次数，则中断执行所述目标业务请求。

在一些实施例中，所述处理单元302在执行所述当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统步骤时，具体用于：

当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，将所述目标业务请求发送至实时队列中；通过所述实时队列发送所述目标业务请求至所述业务处理系统。

在一些实施例中，所述处理单元302在执行所述当监测到业务处理系统中的目标节点执行目标业务请求异常时，从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长步骤时，具体用于：

通过所述收发单元301接收所述业务处理系统发送的节点异常信息，所述节点异常信息包括所述目标节点的目标节点标识以及所述目标业务请求；根据所述目标节点标识从所述节点配置文件中获取所述目标重试间隔时长。

在一些实施例中，所述处理单元302还用于：

通过所述收发单元301获取针对多个所述节点中指定节点的重试间隔时长修改指令；根据所述重试间隔时长修改指令修改所述节点配置文件中所述指定节点的重试间隔时长。

综上所述，第一方面，由于本申请中的业务请求重试系统300在监测到目标节点执行目标业务请求发生异常时，在目标节点对应的重试间隔时长之后会重新发送该目标业务请求至该目标节点进行重试处理，一般情况下，在目标节点对应的异重试间隔时长内，节点情况会从异常恢复为正常，所以在目标节点中对目标业务请求进行重试处理，可以避免流程在目标节点中中断处理，从而提高节点所在系统的稳定性；第二方面，本实施例会根据目标节点目标重试间隔时长的长短将目标业务请求存储到不同的位置，将重试间隔时长较短的请求直接存储到消息队列中，将重试间隔时长较长的请求存储到数据库中，避免将全部异常的请求都持久化存储到数据库中，减少数据库对磁盘容量的占用，节约存储资源；第三方面，本实施例中的用户可以在节点配置文件中设置不同节点的重试间隔时长，即可以配置化对重试机制的参数进行调整，不需要通过发版调整，从而通过本申请可以更加灵活地对重试机制的参数进行调整。

需要说明的是，所属领域的技术人员可以清楚地了解到，上述业务请求重试系统和各单元的具体实现过程，可以参考前述方法实施例中的相应描述，为了描述的方便和简洁，在此不再赘述。

上述业务请求重试系统可以实现为一种计算机程序的形式，该计算机程序可以在如图4所示的计算机设备上运行。

请参阅图4，图4是本申请实施例提供的一种计算机设备的示意性框图。该计算机设备400可以是终端，也可以是服务器，其中，该计算机设备400中部署有业务请求重试系统。

参阅图4，该计算机设备400包括通过系统总线401连接的处理器402、存储器和网络接口405，其中，存储器可以包括非易失性存储介质403和内存储器404。

该非易失性存储介质403可存储操作系统4031和计算机程序4032。该计算机程序4032包括程序指令，该程序指令被执行时，可使得处理器402执行一种业务请求重试方法。

该处理器402用于提供计算和控制能力，以支撑整个计算机设备400的运行。

该内存储器404为非易失性存储介质403中的计算机程序4032的运行提供环境，该计算机程序4032被处理器402执行时，可使得处理器402执行一种业务请求重试方法。

该网络接口405用于与其它设备进行网络通信。本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备400的限定，具体的计算机设备400可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

其中，所述处理器402用于运行存储在存储器中的计算机程序4032，以实现如下步骤：

当监测到业务处理系统中的目标节点执行目标业务请求异常时，从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长，所述节点配置文件中存储有所述业务处理系统中多个节点中各节点分别对应的重试间隔时长；

确定所述目标重试间隔时长是否大于预设的间隔时长阈值；

若所述目标重试间隔时长小于或等于所述间隔时长阈值，则将所述目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中；当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求；

若所述目标重试间隔时长大于所述间隔时长阈值，则将所述目标业务请求存储至数据库中，所述数据库为本地数据库；当所述目标业务请求在所述数据库中的存储时长到达所述重试间隔时长时，发送所述数据库中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求。

应当理解，在本申请实施例中，处理器402可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器402还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本领域普通技术人员可以理解的是实现上述实施例的方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成。该计算机程序包括程序指令，计算机程序可存储于一存储介质中，该存储介质为计算机可读存储介质。该程序指令被该计算机系统中的至少一个处理器执行，以实现上述方法的实施例的流程步骤。

因此，本申请还提供一种存储介质。该存储介质可以为计算机可读存储介质。该存储介质存储有计算机程序，其中计算机程序包括程序指令。该程序指令被处理器执行时使处理器执行如下步骤：

当监测到业务处理系统中的目标节点执行目标业务请求异常时，从预设的节点配置文件中获取所述目标节点对应的目标重试间隔时长，所述节点配置文件中存储有所述业务处理系统中多个节点中各节点分别对应的重试间隔时长；

确定所述目标重试间隔时长是否大于预设的间隔时长阈值；

若所述目标重试间隔时长小于或等于所述间隔时长阈值，则将所述目标业务请求存储至延迟时长与所述目标重试间隔时长对应的目标延迟队列中；当所述目标业务请求在所述目标延迟队列中的存储时长到达所述目标延迟队列的延迟时长时，发送所述目标延迟队列中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求；

若所述目标重试间隔时长大于所述间隔时长阈值，则将所述目标业务请求存储至数据库中，所述数据库为本地数据库；当所述目标业务请求在所述数据库中的存储时长到达所述重试间隔时长时，发送所述数据库中的所述目标业务请求至所述业务处理系统，使得所述业务处理系统通过所述目标节点重新执行所述目标业务请求。

所述存储介质可以是U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的计算机可读存储介质。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的。例如，各个单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。本申请实施例装置中的单元可以根据实际需要进行合并、划分和删减。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。

该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，终端，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。