CN109992431A - 一种实现重试的方法及终端 - Google Patents

Abstract

本发明公开了一种实现重试的方法及终端，通过在对一接口的访问失败时，获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若否，则不发送重试请求，若是，则向所述一接口发送重试请求，并判断重试时的访问是否成功，若不成功则再次获取所述请求成功率确定是否重试，以此循环，通过所述请求成功率在一定程度上可以反映对应接口的状态，在所述请求成功率较低时不进行重试，可以控制重试的次数，避免大规模的流量冲击，减少服务器压力，提高稳定性。

Description

一种实现重试的方法及终端

技术领域

本发明涉及互联网技术领域，尤其是涉及一种实现重试的方法及终端。

背景技术

在互联网产品中，每个产品应用都有对应的服务端，许多服务端都是采用微服务或者数据互相调用的方式来进行数据的交互与组装的。一般情况下，使用RPC或者HTTP的方式实现数据的调用，但在使用这些调用方式时，由于网络不通或对方服务器异常等问题，存在调用失败的情况，需要重新进行请求，这时，系统中最常用的方式是重试机制。

重试就是当某个接口调用失败后重新尝试，在重试过程中，如果使用不当，则可能带来调用系统的雪崩风险，由于重试意味着对调用系统双倍的请求量，一个功能不可用也许会造成用户反复点击，从而带来更大规模的流量冲击，给系统带来巨大压力。

发明内容

本发明所要解决的技术问题是：提供一种实现重试的方法及终端，可以避免大规模的流量冲击，提高稳定性。

为了解决上述技术问题，本发明采用的一种技术方案为：

一种实现重试的方法，包括步骤：

S1、接收对一接口的访问请求；

S2、判断所述访问是否成功，若否，则执行步骤S3；

S3、获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，否则，不发送重试请求。

为了解决上述技术问题，本发明采用的另一种技术方案为：

一种实现重试的终端，包括存储器、处理器及存储在存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

S1、接收对一接口的访问请求；

S2、判断所述访问是否成功，若否，则执行步骤S3；

S3、获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，否则，不发送重试请求。

本发明的有益效果在于：通过在对一接口的访问失败时，获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若否，则不发送重试请求，若是，则向所述一接口发送重试请求，并判断重试时的访问是否成功，若不成功则再次获取所述请求成功率确定是否重试，以此循环，通过所述请求成功率在一定程度上可以反映对应接口的状态，在所述请求成功率较低时不进行重试，可以控制重试的次数，避免大规模的流量冲击，减少服务器压力，提高稳定性。

附图说明

图1为本发明实施例的一种实现重试的方法的步骤流程图；

图2为本发明实施例的一种实现重试的终端的结构示意图；

图3为本发明实施例的一种实现重试的方法的各模块关系示意图；

标号说明：

1、一种实现重试的终端； 2、存储器； 3、处理器。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

本发明最关键的构思在于:在对一接口的访问失败时，获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，否则，不发送重试请求。

请参照图1，一种实现重试的方法，包括步骤：

S1、接收对一接口的访问请求；

S2、判断所述访问是否成功，若否，则执行步骤S3；

S3、获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，否则，不发送重试请求。

从上述描述可知，本发明的有益效果在于：通过在对一接口的访问失败时，获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若否，则不发送重试请求，若是，则向所述一接口发送重试请求，并判断重试时的访问是否成功，若不成功则再次获取所述请求成功率确定是否重试，以此循环，通过所述请求成功率在一定程度上可以反映对应接口的状态，在所述请求成功率较低时不进行重试，可以控制重试的次数，避免大规模的流量冲击，减少服务器压力，提高稳定性。

进一步的，所述步骤S1之前包括：

S01、实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量；

S02、计算在预设时间内各个接口的请求成功率，所述请求成功率为每个接口对应的访问成功的请求数量/访问请求数量；

S03、将各个接口的请求成功率写入缓存。

由上述描述可知，通过实时计算当前各个接口对应的请求成功率，可以及时反映对应接口的状态，便于在访问接口失败时确定是否进行重试，提高准确性，并且将所述请求成功率写入缓存，可以方便查询比对，提高便利性。

进一步的，所述步骤S2包括：

若所述访问不成功，则判断当前在预设时间内的所述一接口的访问请求数量是否大于预设数量，若是，则执行步骤S3，若否，则直接向所述一接口发送重试请求，并返回执行步骤S2。

由上述描述可知，只有在预设时间内的所述一接口的访问请求数量大于预设数量时，才会根据所述请求成功率进行重试的判断，若在预设时间内所述一接口的访问请求数量小于预设数量，则无需查询所述请求成功率，直接进行重试，可以提高判断是否重试的准确性，降低因统计到的请求数量太少带来的偶然性。

进一步的，所述预设时间内各个接口的请求成功率对应有缓存过期时间；

所述步骤S3包括：

获取缓存的实时更新的所述一接口的请求成功率，根据所述一接口的请求成功率对应的缓存过期时间判断所述缓存中的请求成功率是否过期；

若是，则直接向所述一接口发送重试请求，并返回执行步骤S2；

否则，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，若否，不发送重试请求。

由上述描述可知，所述请求成功率具有对应的缓存过期时间，在所述请求成功率过期时直接进行重试，避免长时间未更新的请求成功率准确性不足的问题，进一步确保了所述请求成功率的准确性和及时性。

进一步的，所述步骤S01之前包括：

接收接口访问请求的第一消息，所述第一消息包括接口的标识；

接收接口访问成功的第二消息，所述第二消息包括接口的标识；

所述步骤S01包括：

根据所述接口的标识确定各个接口对应的第一消息和第二消息；

根据所述各个接口对应的第一消息和第二消息实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量。

由上述描述可知，通过所述接口的标识可以将各个接口的第一消息和第二消息对应起来，方便计算各个接口对应的请求成功率，避免各个接口的访问请求数量和访问成功的请求数量混淆，简单快捷地实现了所述请求成功率的计算，提高所述请求成功率的准确性。

请参照图2，一种实现重试的终端，包括存储器、处理器及存储在存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

S1、接收对一接口的访问请求；

S2、判断所述访问是否成功，若否，则执行步骤S3；

S3、获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，否则，不发送重试请求。

从上述描述可知，本发明的有益效果在于：通过在对一接口的访问失败时，获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若否，则不发送重试请求，若是，则向所述一接口发送重试请求，并判断重试时的访问是否成功，若不成功则再次获取所述请求成功率确定是否重试，以此循环，通过所述请求成功率在一定程度上可以反映对应接口的状态，在所述请求成功率较低时不进行重试，可以控制重试的次数，避免大规模的流量冲击，减少服务器压力，提高稳定性。

进一步的，所述步骤S1之前包括：

S01、实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量；

S02、计算在预设时间内各个接口的请求成功率，所述请求成功率为每个接口对应的访问成功的请求数量/访问请求数量；

S03、将各个接口的请求成功率写入缓存。

由上述描述可知，通过实时计算当前各个接口对应的请求成功率，可以及时反映对应接口的状态，便于在访问接口失败时确定是否进行重试，提高准确性，并且将所述请求成功率写入缓存，可以方便查询比对，提高便利性。

进一步的，所述步骤S2包括：

若所述访问不成功，则判断当前在预设时间内的所述一接口的访问请求数量是否大于预设数量，若是，则执行步骤S3，若否，则直接向所述一接口发送重试请求，并返回执行步骤S2。

由上述描述可知，只有在预设时间内的所述一接口的访问请求数量大于预设数量时，才会根据所述请求成功率进行重试的判断，若在预设时间内所述一接口的访问请求数量小于预设数量，则无需查询所述请求成功率，直接进行重试，可以提高判断是否重试的准确性，降低因统计到的请求数量太少导致的偶然性。

进一步的，所述预设时间内各个接口的请求成功率对应有缓存过期时间；

所述步骤S3包括：

获取缓存的实时更新的所述一接口的请求成功率，根据所述一接口的请求成功率对应的缓存过期时间判断所述缓存中的请求成功率是否过期；

若是，则直接向所述一接口发送重试请求，并返回执行步骤S2；

否则，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，若否，不发送重试请求。

由上述描述可知，所述请求成功率具有对应的缓存过期时间，在所述请求成功率过期时直接进行重试，避免长时间未更新的请求成功率准确性不足的问题，进一步确保了所述请求成功率的准确性和及时性。

进一步的，所述步骤S01之前包括：

接收接口访问请求的第一消息，所述第一消息包括接口的标识；

接收接口访问成功的第二消息，所述第二消息包括接口的标识；

所述步骤S01包括：

根据所述接口的标识确定各个接口对应的第一消息和第二消息；

根据所述各个接口对应的第一消息和第二消息实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量。

由上述描述可知，通过所述接口的标识可以将各个接口的第一消息和第二消息对应起来，方便计算各个接口对应的请求成功率，避免各个接口的访问请求数量和访问成功的请求数量混淆，简单快捷地实现了所述请求成功率的计算，提高所述请求成功率的准确性。

实施例一

请参照图1和图3，本实施例是以计算模块的角度进行描述，一种实现重试的方法，包括步骤：

接收接口访问请求的第一消息，所述第一消息包括接口的标识；

接收接口访问成功的第二消息，所述第二消息包括接口的标识；

具体地，客户端请求接口，接口接收到接口访问请求时发送第一消息至计算模块；

接口成功处理所述接口访问请求所需的业务逻辑时，向所述计算模块发送第二消息；

计算模块接收众多接口的第一消息和第二消息；

S01、实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量；

具体地，每个接口都对应有自身特定的标识，所述接口的标识包括接口类型和操作类型，所述接口类型与所述接口具体业务相关，所述操作类型用于区分第一消息和第二消息；

优选地，所述操作类型可以是oper_0或oper_1，所述oper_0表示消息为第一消息，用于计算接口的访问请求数量，oper_1表示消息为第二消息，用于计算接口访问成功的请求数量；

根据所述接口的标识确定各个接口对应的第一消息和第二消息；

根据所述各个接口对应的第一消息和第二消息实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量；

例如，A接口为A类型，所述A类型为接口类型，所述A接口对应的接口的标识有A_oper_0和A_oper_1，其中，A接口对应的第一消息带有A_oper_0标识，A接口对应的第二消息带有A_oper_1标识；

统计带有A_oper_0标识的消息数量作为所述A接口的访问请求数量，统计带有A_oper_1标识的消息数量作为所述A接口的访问成功的请求数量；

S02、计算在预设时间内各个接口的请求成功率，所述请求成功率为每个接口对应的访问成功的请求数量/访问请求数量；

S03、将各个接口的请求成功率写入缓存；

优选地，将各个接口的请求成功率写入redis缓存；

S1、接收对一接口的访问请求；

S2、判断所述访问是否成功，若否，则执行步骤S3；

具体地，接口在执行接口访问请求所需的业务逻辑需要访问其他接口服务获取数据时，若无法获取到数据，则说明该接口执行失败，即所述访问不成功；

在所述访问不成功时，判断当前在预设时间内的所述一接口的访问请求数量是否大于预设数量，若是，则执行步骤S3，若否，则直接向所述一接口发送重试请求，并返回执行步骤S2，将重试时进行的访问也用于计算所述接口对应的请求成功率；

优选地，所述预设数量为1000，即在接口访问请求数量大于1000时才通过对应的请求成功率进行重试的判断；

S3、获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，否则，不发送重试请求。

具体地，查询所述redis缓存获取实时更新的、接口对应的请求成功率；

当所述请求成功率小于预设值时，说明当前重试的成功率较低，这时直接不进行重试，避免后续持续的循环重试带来的流量冲击；

当所述请求成功率大于预设值时，将向所述一接口发送重试请求进行重试，并返回步骤S2，对重试时的访问进行成功与否的判断，将重试时进行的访问也用于计算所述接口对应的请求成功率；

此时，还需统计一定时间段内重试的次数，若在统计时间段内的重试请求失败次数达到预设阈值，则发出报警消息通知报警模块，由所述报警模块通知相关人员。

实施例二

本实施例与实施例一的不同在于：

所述预设时间内各个接口的请求成功率对应有缓存过期时间；

具体地，在预设时间内，接口接收到访问请求时需要根据此次访问是否成功来更新对应的请求成功率，在更新所述请求成功率的同时刷新所述请求成功率对应的缓存过期时间；

优选地，所述缓存过期时间为30分钟，在预设时间内，若接口在20分钟内均未接收到访问请求，则距离所述接口对应的请求成功率过期的时间还剩10分钟，这时若所述接口接收到访问请求，并根据所述访问请求的情况更新对应的请求成功率，则刷新了所述请求成功率的缓存过期时间，这时距离所述请求成功率过期的时间被重置为30分钟；

所述缓存过期时间还可以根据具体的业务场景进行自适应设定，优选的，可以根据缓存过期时间内接收到的接口访问请求数量进行自适应调整，例如，若是在30分钟内只有少量的接口访问请求，这时可以适当延长所述缓存过期时间；

所述步骤S3包括：

获取缓存的实时更新的所述一接口的请求成功率，根据所述一接口的请求成功率对应的缓存过期时间判断所述缓存中的请求成功率是否过期；

若是，则直接向所述一接口发送重试请求，并返回执行步骤S2；

否则，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，若否，不发送重试请求。

具体地，在所述请求成功率过期后，重新开始计算所述请求成功率；

若在所述请求成功率过期后的一段时间内没有访问请求，此时缓存中将不存在实时可用的请求成功率，这时若需要重试，则直接进行重试。

实施例三

请参照图2，一种实现重试的终端1，包括存储器2、处理器3及存储在存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现实施例一中的各个步骤。

实施例四

请参照图2，一种实现重试的终端1，包括存储器2、处理器3及存储在存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现实施例二中的各个步骤。

综上所述，本发明提供的一种实现重试的方法及终端，通过实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量计算各个接口对应的请求成功率，将计算得到的请求成功率存入缓存，在对一接口的访问失败时，获取缓存的实时更新的所述一接口的请求成功率，在所述一接口的访问请求数大于预设数量时，判断所述请求成功率是否大于预设值，若否，则不发送重试请求，若是，则向所述一接口发送重试请求，并判断重试时的访问是否成功，若不成功则再次获取所述请求成功率确定是否重试，以此循环，可以及时通过所述请求成功率在一定程度上可以反映对应接口的状态，避免偶然因素，提高请求成功率的准确性，方便查询比对所述请求成功率，在所述请求成功率较低时不进行重试，可以控制重试的次数，避免大规模的流量冲击，减少服务器压力，提高稳定性。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种实现重试的方法，其特征在于，包括步骤：

S1、接收对一接口的访问请求；

S2、判断所述访问是否成功，若否，则执行步骤S3；

S3、获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，否则，不发送重试请求。

2.根据权利要求1所述的一种实现重试的方法，其特征在于，所述步骤S1之前包括：

S01、实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量；

S02、计算在预设时间内各个接口的请求成功率，所述请求成功率为每个接口对应的访问成功的请求数量/访问请求数量；

S03、将各个接口的请求成功率写入缓存。

3.根据权利要求1或2所述的一种实现重试的方法，其特征在于，所述步骤S2包括：

若所述访问不成功，则判断当前在预设时间内的所述一接口的访问请求数量是否大于预设数量，若是，则执行步骤S3，若否，则直接向所述一接口发送重试请求，并返回执行步骤S2。

4.根据权利要求1或2所述的一种实现重试的方法，其特征在于，所述预设时间内各个接口的请求成功率对应有缓存过期时间；

所述步骤S3包括：

获取缓存的实时更新的所述一接口的请求成功率，根据所述一接口的请求成功率对应的缓存过期时间判断所述缓存中的请求成功率是否过期；

若是，则直接向所述一接口发送重试请求，并返回执行步骤S2；

否则，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，若否，不发送重试请求。

5.根据权利要求2所述的一种实现重试的方法，其特征在于，所述步骤S01之前包括：

接收接口访问请求的第一消息，所述第一消息包括接口的标识；

接收接口访问成功的第二消息，所述第二消息包括接口的标识；

所述步骤S01包括：

根据所述接口的标识确定各个接口对应的第一消息和第二消息；

根据所述各个接口对应的第一消息和第二消息实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量。

6.一种实现重试的终端，包括存储器、处理器及存储在存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：

S1、接收对一接口的访问请求；

S2、判断所述访问是否成功，若否，则执行步骤S3；

S3、获取缓存的实时更新的所述一接口的请求成功率，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，否则，不发送重试请求。

7.根据权利要求6所述的一种实现重试的终端，其特征在于，所述步骤S1之前包括：

S01、实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量；

S02、计算在预设时间内各个接口的请求成功率，所述请求成功率为每个接口对应的访问成功的请求数量/访问请求数量；

S03、将各个接口的请求成功率写入缓存。

8.根据权利要求6或7所述的一种实现重试的终端，其特征在于，所述步骤S2包括：

若所述访问不成功，则判断当前在预设时间内的所述一接口的访问请求数量是否大于预设数量，若是，则执行步骤S3，若否，则直接向所述一接口发送重试请求，并返回执行步骤S2。

9.根据权利要求6或7所述的一种实现重试的终端，其特征在于，所述预设时间内各个接口的请求成功率对应有缓存过期时间；

所述步骤S3包括：

获取缓存的实时更新的所述一接口的请求成功率，根据所述一接口的请求成功率对应的缓存过期时间判断所述缓存中的请求成功率是否过期；

若是，则直接向所述一接口发送重试请求，并返回执行步骤S2；

否则，判断所述请求成功率是否大于预设值，若是，则向所述一接口发送重试请求，并返回执行步骤S2，若否，不发送重试请求。

10.根据权利要求7所述的一种实现重试的终端，其特征在于，所述步骤S01之前包括：

接收接口访问请求的第一消息，所述第一消息包括接口的标识；

接收接口访问成功的第二消息，所述第二消息包括接口的标识；

所述步骤S01包括：

根据所述接口的标识确定各个接口对应的第一消息和第二消息；

根据所述各个接口对应的第一消息和第二消息实时统计当前在预设时间内接收到的各个接口的访问请求数量和各个接口访问成功的请求数量。