Calling retry method, device and equipment and computer storage medium

Abstract

The embodiment of the invention provides a calling retry method, device and equipment and a computer storage medium, the calling retry method is applied to a calling party, and the calling retry method comprises the steps that the number of calling failures is determined; the calling failure frequency represents the total frequency of calling failure of the called party; determining retry interval time according to the calling failure times and the random factor; and recalling the called party according to the retry interval time. Therefore, due to the fact that the random factor is introduced when the retry interval time is calculated, the randomness of the retry interval time is increased, instantaneous pulse type impact on the called party is avoided, and the success rate of retry is increased.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to a call retry method, a caller apparatus, a caller device, and a computer storage medium. Background Art

[0002] In computer network applications, whether interacting with local resources or remote resources or services, call failures may occur. This failure may be caused by network instability or an internal error on the called party. In these cases, retries are necessary to make the application more robust and improve the success rate of processing. Current retry methods can cause greater network impact on the called party and exacerbate the call failure, defeating the purpose of retrying. Summary of the Invention

[0003] The embodiments of the present application provide a call retry method, a caller apparatus, a caller device, and a computer storage medium, which can avoid causing a large network impact to the called party and reduce the probability of retry call failure.

[0004] In a first aspect, an embodiment of the present application provides a call retry method, which is applied to a caller, and the call retry method includes:

[0005] Determine the number of call failures; the number of call failures represents the total number of failed calls to the callee;

[0006] Determine the retry interval based on the number of call failures and a random factor;

[0007] The called party is re-called according to the retry interval.

[0008] In some embodiments, determining the retry interval based on the number of call failures and a random factor includes:

[0009] Determine an initial retry interval based on the number of call failures and an exponential backoff algorithm;

[0010] A random factor is obtained, and the retry interval is determined according to the random factor and the initial retry interval.

[0011] In some embodiments, determining the initial retry interval based on the number of call failures and an exponential backoff algorithm includes:

[0012] Determining the number of interval time slots based on the number of call failures and an exponential backoff algorithm;

[0013] The product of the number of interval time slots and a preset time slot is determined as the initial retry interval time.

[0014] In some embodiments, obtaining a random factor and determining the retry interval according to the random factor and the initial retry interval includes:

[0015] Generating the random factor using a random algorithm;

[0016] The sum of the initial retry interval and the random factor is determined as the retry interval.

[0017] In some embodiments, re-calling the callee according to the retry interval includes:

[0018] After the call to the callee fails and the retry interval has elapsed, determining whether a retry condition is met;

[0019] If the retry condition is met, re-call the callee;

[0020] If the retry condition is not met, the call is determined to have failed, and the retry interval is dynamically adjusted.

[0021] In some embodiments, determining whether a retry condition is met includes:

[0022] Determining the load status of the caller and the service status of the callee;

[0023] If the load of the caller is normal and the service of the callee is available, determining that the retry condition is met;

[0024] If the load of the caller is abnormal and / or the service of the callee is unavailable, it is determined that the retry condition is not met.

[0025] In some embodiments, when the service of the callee is unavailable, the call retry method further includes:

[0026] Determining a service unavailable time period of the called party;

[0027] During the service unavailable time period, the called party is not called again.

[0028] In a second aspect, an embodiment of the present application provides a caller device, the caller device comprising:

[0029] The first determining unit is configured to determine a number of call failures; the number of call failures represents a total number of failed calls to the callee;

[0030] A second determining unit is configured to determine a retry interval according to the number of call failures and a random factor;

[0031] The retry unit is configured to re-call the called party according to the retry interval time.

[0032] In a third aspect, an embodiment of the present application provides a caller device, the caller device including a memory and a processor; wherein:

[0033] The memory is used to store a computer program that can be run on the processor;

[0034] The processor is configured to execute the call retry method as described in any one of the first aspects when running the computer program.

[0035] In a fourth aspect, an embodiment of the present application provides a computer storage medium, wherein the computer storage medium stores a computer program, and when the computer program is executed by at least one processor, the call retry method as described in any one of the first aspects is implemented.

[0036] The embodiment of the present application provides a call retry method, a caller apparatus, a caller device, and a computer storage medium. The call retry method is applied to the caller, and the call retry method includes: determining the number of call failures; the number of call failures represents the total number of failed calls to the callee; determining the retry interval based on the number of call failures and a random factor; and re-calling the callee based on the retry interval. In this way, since a random factor is introduced when calculating the retry interval, the randomness of the retry interval is increased, and a personalized retry time is calculated for each failed call request, avoiding the situation where failed requests are retried at the same time point, thereby avoiding an instantaneous pulse-like impact on the callee and improving the success rate of the retry. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 A schematic diagram of a process for calling a retry method provided in an embodiment of the present application Figure 1 ;

[0038] Figure 2 A schematic diagram of a process for calling a retry method provided in an embodiment of the present application Figure 2 ;

[0039] Figure 3 A schematic diagram of a process for calling a retry method provided in an embodiment of the present application Figure 3 ;

[0040] Figure 4 A schematic diagram of a process for calling a retry method provided in an embodiment of the present application Figure 4 ;

[0041] Figure 5 A schematic diagram of the structure of a caller device provided in an embodiment of the present application;

[0042] Figure 6 A schematic diagram of the hardware structure of a calling device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. It should be understood that the specific embodiments described herein are only used to explain the related applications and are not intended to limit the applications. It should also be noted that for ease of description, only the portions relevant to the related applications are shown in the drawings.

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0045] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0046] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are only used to distinguish similar objects and do not represent a specific order for the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0047] The retry process can be simplified as follows Figure 1 ,like Figure 1 As shown, the process includes the following steps:

[0048] S101: Network call processing.

[0049] S102: Check whether the call process is successful or whether the termination condition is reached.

[0050] If the judgment result is yes, execute step S103; otherwise, retry and return to execute step S101.

[0051] S103: Continue subsequent processing.

[0052] It should be noted that there are mainly the following retry methods: (1) Continuous retry for a fixed number of times: After the call fails, a retry is initiated immediately, and it returns after a certain number of consecutive retries; (2) Retry with a fixed interval time: After the call fails, wait for a fixed interval time before retrying again, and the retry ends after reaching a certain retry limit; (3) Retry with a dynamic interval time, the interval time can be random or similar to the exponential backoff algorithm. As the number of retries increases, the interval time also increases until the retry termination condition is reached.

[0053] The shortcomings of the aforementioned retry methods are as follows: (1) Immediate retry after call failure and retry with fixed interval time. These two retry strategies may be applicable to deal with instantaneous network jitter, but if the called party is already running at full capacity or close to being unavailable, both strategies may bring greater network impact to the called party, and also make the call failure situation worse, and fail to achieve the purpose of retry; (2) Retry with dynamic interval time can avoid the problems of the above two retry methods to a certain extent, because the retry interval time is dynamic and nonlinear, which reduces the impact on the called party in a shorter time. However, due to the calculation of multiple call failure requests at the same time point, after the exponential backoff algorithm, they will also be retried at the same time point thereafter. Therefore, for the situation where a large number of calls fail instantly, the fixed exponential backoff algorithm may still form an instantaneous pulse-like impact on the called party.

[0054] Based on this, an embodiment of the present application provides a call retry method, which includes: determining the number of call failures; the number of call failures represents the total number of failed calls to the callee; determining the retry interval based on the number of call failures and a random factor; and re-calling the callee based on the retry interval. In this way, since a random factor is introduced when calculating the retry interval, the randomness of the retry interval is increased, and a personalized retry time is calculated for each failed call request, avoiding the situation where failed requests are retried at the same time point, thereby avoiding an instantaneous pulse impact on the callee and improving the success rate of the retry.

[0055] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0056] In one embodiment of the present application, see Figure 2 , which shows a flowchart of a calling retry method provided by an embodiment of the present application, such as Figure 2 As shown, the call retry method may include:

[0057] S201: Determine the number of call failures; the number of call failures represents the total number of failed calls to the callee.

[0058] S202: Determine a retry interval based on the number of call failures and a random factor.

[0059] S203: Re-call the called party according to the retry interval.

[0060] It should be noted that the call retry method provided in the embodiment of the present application can be applied to the caller, and the caller can be specifically a caller device or a caller device integrated with the caller device, a caller platform, etc. When the caller fails to call the callee, a reasonable retry plan is formulated to improve the success rate of the retry. Among them, the caller can be a real-name authentication platform (referred to as the real-name platform), etc., and the callee can be a telecommunications operator, etc., which is not specifically limited here. It can be understood that in some cases, the identity of the callee may also be converted to the caller, and the identity of the caller may also be converted to the callee, which is related to the actual application scenario.

[0061] For example, in the field of IoV real-name authentication, real-name registration is a compliance requirement imposed by the Ministry of Industry and Information Technology on automakers. This means that when automakers sell IoV cards to users, they must truthfully register the user's real identity information and upload the collected information to the MIIT regulatory platform via the telecom operator's platform. The automaker real-name workstation is a platform built for automakers to collect and upload real user identity information for IoV cards, in accordance with MIIT requirements. This embodiment of the present application can improve the success rate of retries and reduce the negative impact on associated systems in the event of real-name authentication errors.

[0062] The call retry method provided in this application can help automakers improve the success rate of real-name authentication and better meet the relevant requirements of the Ministry of Industry and Information Technology. At the same time, this call retry method can also be applied in call failure scenarios of general computer network applications. Therefore, this method is widely applicable to various scenarios requiring network calls, including but not limited to the Internet of Vehicles, the Internet of Things, edge computing and other fields.

[0063] It should also be noted that, for a task executed by the caller, embodiments of the present application can formulate a complete retry plan after the first call fails to execute subsequent retries; or calculate the retry interval in real time after each call fails, which is not specifically limited here. Each of these will be explained below.

[0064] In the implementation method of formulating a complete retry plan, after the first call fails, a preset number of retry intervals are determined. The preset number here is the pre-set maximum number of retries, that is, the number of retries after the first call fails (retry means retrying to call the callee after the call fails). If the number of retries reaches the preset number (the other implementation methods also set the preset number to avoid meaningless retries), no more retries will be made and the call will be abandoned.

[0065] Assuming the preset number of times is 3, 3 retry intervals need to be generated. For the first retry, if the number of call failures is 1, the first retry interval between the first retry and the first call failure is determined based on 1 and the first random factor. For the second retry, if the number of call failures is 2, the second retry interval between the second retry and the first call failure is determined based on 2 and the second random factor. For the third retry, if the number of call failures is 3, the third retry interval between the third retry and the first call failure is determined based on 3 and the third random factor. Then, after the first retry interval from the first call failure, the first retry is performed. If it still fails, the second retry is performed after the second retry interval from the first call failure. If it still fails, the third retry is performed after the third retry interval from the first call failure. If it still fails, the current call task is abandoned.

[0066] In the implementation method of calculating the retry interval in real time after each call failure, the preset number of times is still set to 3. After the first call fails, the number of call failures is 1. The first retry interval between the first retry and the first call failure is determined based on 1 and the first random factor, and the first retry is performed after the first retry interval. If the call is successful, the current call task is completed. If it still fails, the number of call failures is 2. The second retry interval between the second retry and the first call failure is determined based on 2 and the second random factor, and the second retry is performed after the second retry interval from the first call failure. If the call is successful, the current call task is completed. If it still fails, the number of call failures is 3. The third retry interval between the third retry and the first call failure is determined based on 3 and the third random factor, and the third retry is performed after the third retry interval from the first call failure. If the call is successful, the current call is completed. If it still fails, the current call is abandoned.

[0067] In an embodiment of the present application, a random factor is introduced each time the retry interval is determined, thereby increasing the randomness of the retry interval, so that the retry interval is dynamically nonlinear, thereby avoiding the problem of instantaneous pulse-like impact on the called party caused by multiple callers that have failed to call retrying the called party at the same time.

[0068] It should also be noted that in this example, the retry interval refers to the interval between the retry attempt and the initial call failure. In other examples, the retry interval can also refer to the interval between two calls. By setting an appropriate range for the random factor, the retry success rate can be improved regardless of the definition of the retry interval. The subsequent description uses the interval between the initial call failure as an example of the retry interval.

[0069] In some embodiments, determining the retry interval based on the number of call failures and a random factor may include:

[0070] Determine the initial retry interval based on the number of call failures and the exponential backoff algorithm;

[0071] Get a random factor and determine the retry interval based on the random factor and the initial retry interval.

[0072] Get random factors, which can include:

[0073] Generate random factors using a random algorithm.

[0074] It should be noted that the embodiment of the present application can use an exponential backoff algorithm to calculate an initial retry interval, and use a random algorithm to generate a random factor, and then use the random factor to introduce randomness into the initial retry interval to obtain the final retry interval.

[0075] Exponential backoff is an error handling strategy for network applications. When using this strategy, the client will periodically retry failed requests, and the retry interval will increase exponentially as the number of failures increases.

[0076] Here, the initial retry interval may be a time directly calculated using an exponential backoff algorithm. Alternatively, in some embodiments, the initial retry interval may be determined based on the number of call failures and the exponential backoff algorithm, which may include:

[0077] Determine the number of interval time slots based on the number of call failures and the exponential backoff algorithm;

[0078] The product of the number of interval time slots and the preset time slot is determined as the initial retry interval time.

[0079] The number of interval time slots E(c) is calculated as follows: c -1.

[0080]

[0081] Where c is the number of failed calls, and the product of the number of interval slots, E(c), and the preset time slot, t, is the initial retry interval. In other words, E(c) represents the number of preset time slots between the cth failed call and the c+1th failed call.

[0082] The initial retry interval T(c) is calculated as follows:

[0083] T(c)=E(c)×t (2)

[0084] Wherein, t represents a preset time slot.

[0085] In the embodiment of the present application, the random factor can be a specific random time value or a random time slot number value. In the case where the random factor is a random time value, the retry interval is determined based on the random factor and the initial retry interval, including:

[0086] The retry interval is determined as the sum of the initial retry interval and the random factor.

[0087] It should be noted that, when the random factor δ is a random time value, the retry interval F(c) can be calculated as follows:

[0088] F(c)=T(c)+δ=E(c)×t+δ (3)

[0089] Where F(c) represents the retry interval, E(c) represents the number of interval time slots, t represents the preset time slot, and δ represents the random factor.

[0090] When the random factor δ is a random number of time slots, the retry interval F(c) can be calculated as follows:

[0091] F(c)=(E(c)+δ)t=E(c)×t+δ×t=T(c)+δ×t (4)

[0092] In the embodiment of the present application, the random factor δ is calculated by a random algorithm, and the value range can be (0, 1 preset time slots]. If the preset time slot is 60 seconds (s), the possible value range of the random factor δ as the random time value is (0, 60], and the possible value range of the random factor δ as the random time slot number value is (0, 1]. In this embodiment, the introduction of the random factor is mainly to disperse the execution time of the retry task and reduce the probability of generating a large number of retry requests at the same time. When the number of tasks that need to be retried is too large, it is also possible to consider expanding the value range accordingly, but the value range should not be too large to avoid exceeding the retry time of the next round.

[0093] Furthermore, the existing retry method lacks monitoring of the caller's system load and dynamic identification and processing of the called party's feedback information. Based on this, the embodiment of the present application adds a judgment condition before retrying, thereby dynamically adjusting the retry mechanism.

[0094] In some embodiments, re-calling the callee based on the retry interval may include:

[0095] After the call to the callee fails and the retry interval has elapsed, determine whether the retry conditions are met;

[0096] If the retry conditions are met, the callee is re-invoked;

[0097] If the retry conditions are not met, the call is determined to have failed and the retry interval is dynamically adjusted.

[0098] It should be noted that in the aforementioned scheme, after the first call fails, the cth retry is performed after the retry interval time. If the caller is overloaded or the called party is unavailable, the call will still fail and increase the burden on the platform. Therefore, in order to further improve the retry success rate and reduce the platform pressure, before retrying, the embodiment of the present application first determines whether both the caller and the called party meet the retry conditions. If both meet the conditions, the retry is performed normally. Otherwise, if either one does not meet the retry conditions, the retry is suspended and the retry plan is dynamically adjusted.

[0099] Specifically, determining whether the retry conditions are met includes:

[0100] Determine the load status of the caller and the service status of the callee;

[0101] If the caller's load is normal and the callee's service is available, the retry condition is determined to be met;

[0102] If the load of the caller is abnormal and / or the service of the callee is unavailable, it is determined that the retry condition is not met.

[0103] It should be noted that, assuming that the upper limit of the number of tasks that the caller can execute simultaneously is the first threshold, then if after initiating the current retry task, the number of tasks of the caller exceeds the first threshold, the caller load is overloaded, and the caller load is considered abnormal; otherwise, if after initiating the current retry task, the number of tasks of the caller does not exceed the first threshold, the caller load is not overloaded, and the caller load is considered normal.

[0104] Assuming that the callee's service is unavailable within a certain time period, the result of the call will be a call failure regardless of how many times the call is made. Therefore, if the time of initiating a retry falls within the time period, the callee's service is determined to be unavailable; if the time of initiating a retry does not fall within the time period, the callee's service is determined to be available. It can be seen that in the case that the callee's service is unavailable, the call retry method may further include: determining a time period during which the callee's service is unavailable; and not re-calling the callee during the time period during which the service is unavailable.

[0105] Only when the caller's load is normal and the callee's service is available, the retry condition is considered met and a retry is performed; otherwise, no retry is performed for the time being.

[0106] In other words, the embodiments of the present application can dynamically adjust the initiation of retries. If the caller's load is abnormal and / or the callee's service is unavailable, it is determined that the retry conditions are not met, and the current retry is considered to have failed. The retry interval is then recalculated, and the next retry is performed. Here, when recalculating the retry interval, the caller's load status and / or the callee's service status can also be taken into account to avoid initiating invalid retries again.

[0107] For example, if a retry cannot be initiated because the caller's load is overloaded, the time it will take for the caller's load to return to normal can be calculated (usually, the time it takes for the caller to execute a task is an empirical value or a calculated value, which can be used for calculation). The new retry interval is calculated based on this time, and a retry is initiated after the retry interval has elapsed since the first call failure, ensuring that the caller's load is normal and the callee's service is available. Alternatively, the caller's load status can be monitored in real time or at preset intervals, ready to initiate a retry at any time.

[0108] For example, if a retry cannot be initiated because the called party's service is unavailable, the time left before the called party's service is available can be calculated, and a new retry interval can be calculated based on this time. A retry can be initiated after the retry interval has passed since the first call failure or after it is greater than the retry interval (to avoid call failures caused by a large number of calls to the called party right after the service is enabled), and the caller's load is guaranteed to be normal and the called party's service is available.

[0109] In addition, the above-mentioned method of determining the load status of the caller and the service status of the callee and the method of dynamic adjustment are only exemplary. In actual implementation, status judgment and dynamic adjustment can be performed in any feasible way while considering the load status of the caller and the service status of the callee.

[0110] An embodiment of the present application provides a call retry method. On the one hand, a random factor is introduced when calculating the retry interval, thereby obtaining a dynamic nonlinear retry interval, and introducing randomness, thereby avoiding instantaneous pulse shocks to the called party and improving the success rate of the retry; on the other hand, in the process of executing the retry, the actual conditions of the caller and the called party are also taken into consideration, and the retry mechanism is dynamically adjusted to reduce the possibility of retry failure.

[0111] Based on the above embodiments, the calling retry method provided by the embodiment of the present application can be mainly divided into two parts: generating a retry plan, and dynamically correcting the retry time during the execution of the retry plan. Among them, the process of generating a retry plan is as follows: Figure 3 As shown, including:

[0112] S301: Calculate the initial retry interval based on the exponential backoff algorithm.

[0113] S302: Introduce a random factor δ.

[0114] S303: Generate a retry plan.

[0115] It should be noted that if Figure 3 As shown, the process of generating a retry plan mainly involves the following steps:

[0116] Step 1: After a call failure occurs, an initial retry interval is calculated using the exponential backoff algorithm. Considering the uniform distribution of backoff times, the mathematical expectation of the backoff time is the average of all possibilities. That is, after the cth call failure, the number of interval time slots E(c) is calculated as shown in the above formula (1).

[0117] According to formula (1), we can know that:

[0118] The number of time slots between retries after the first failure is:

[0119] The number of time slots between the second failed retries is:

[0120] The number of time slots between the third failed retries is:

[0121] And so on….

[0122] Assuming an interval time slot t (i.e., the preset time slot) is 60 seconds, after the initial call fails, the first retry will be performed after 0.5×60=30 seconds, the second retry after 1.5×60=90 seconds, and the third retry after 3.5×60=210 seconds, until the call succeeds or the maximum number of retries is reached. If the maximum number of retries is limited to 3, the entire retry process will take at most 210 seconds to complete.

[0123] Step 2: Based on the initial retry interval calculated in step 1 using the exponential backoff algorithm, a random factor δ is introduced to make the calculation of each retry time random, thus avoiding the impact on the callee caused by too many retry requests at the same time. The details are as shown in the above formula (3).

[0124] The random factor δ can be calculated by a random algorithm. As an example, the value range of the random factor δ can be (0, 1 interval time slots]. If the interval time slot is 60s, the possible value range of the random factor is (0, 60]. The introduction of the random factor is mainly to disperse the execution time of the retry task and reduce the probability of generating a large number of retry requests at the same time. Because if the caller has too many failed requests at the same time, it may initiate retries again at the same time. A large number of retry requests will increase the request failure rate. If the number of tasks that need to be retried is too large, you can also consider expanding the value range accordingly. However, it is not recommended to set the value range too large to exceed the retry time of the next round, because this may cause confusion in the retry plan, which is not worth the loss.

[0125] Step 3: Associate the retry time calculated in steps 1 and 2 with each call request to form a retry plan for subsequent retry mechanism implementation.

[0126] The dynamic modification process of the retry plan is as follows Figure 4 As shown, including:

[0127] S401: Determine whether the caller load is normal.

[0128] If the judgment result is yes, execute step S402; otherwise, execute step S404.

[0129] S402: Determine whether the called party is available.

[0130] If the judgment result is yes, execute step S403; otherwise, execute step S404.

[0131] S403: Continue subsequent processing.

[0132] S404: Dynamically modify the retry plan.

[0133] It should be noted that the main steps involved in the dynamic modification process of the retry plan are as follows:

[0134] Step 1: When retrying, first determine whether the caller's load is normal. For example, if the caller is a real-name authentication platform, the platform can determine whether its load is normal based on the platform's stress test results. If the number of simultaneous real-name authentication tasks is less than 1,000, the platform can operate normally. If the number exceeds 1,000, the platform will have difficulty running stably. If a new retry task needs to be executed, the platform will automatically enter a waiting state until the platform load drops to a reasonable level.

[0135] Step 2: If the caller's load is normal, obtain the result information returned by the call. For example, if a certain operator's platform is unavailable from 22:00 to 7:30 in the morning, the retry task during this time period enters a waiting state until the called party's platform returns to an available state.

[0136] In short, the embodiment of the present application proposes a real-name retry method based on an exponential backoff strategy, which mainly solves the following problems: (1) the retry interval is dynamically nonlinear, and at the same time, it is necessary to avoid instantaneous pulse shocks to the callee; (2) during the execution of the retry strategy, the retry mechanism can be dynamically adjusted according to the caller system load and the information fed back by the callee.

[0137] The overall solution of the embodiment of the present application is: based on the exponential backoff algorithm and the introduced random factor, a personalized retry time is calculated for each failed call request. At the same time, if it is monitored that the caller system load is too large or the callee service is unavailable, the real-name retry time is dynamically modified; a random factor is introduced into the retry time generated by the exponential backoff strategy to further reduce the retry impact on the callee caused by too many failed requests at the same time; according to the caller system load and the return information of the callee system, the retry time is further dynamically corrected to avoid invalid retries and improve retry efficiency.

[0138] Compared with "retry with dynamic interval time", this solution has at least the following advantages: due to the introduction of random factors, even if the requests fail at the same time, different retry times will be calculated, reducing the impact on the callee, thereby reducing the load on the related system, improving the retry success rate, and ultimately improving the processing success rate of the entire business; by monitoring the caller's system load and in-depth analysis and classification of the information returned by the callee, the retry time is dynamically corrected, so that the retry time of the failed request is better adapted to the callee, avoiding the initiation of invalid retry requests.

[0139] The principle of this solution is to introduce a random factor based on the retry interval calculated by the current exponential backoff algorithm, and calculate a personalized retry time for each failed request, so as to avoid the situation where failed requests are retried at the same time. At the same time, during the real-name authentication process, if it is monitored that the caller's system load is too large, or the error message returned by the called party (telecom operator platform) is parsed and classified, and it is found that the called party is unable to provide services (such as not providing services at night, occasional abnormal errors, etc.), the real-name retry plan correction mechanism will be triggered, and the real-name retry time will be dynamically modified to achieve staggered real-name retries, reduce the impact of batch retries on downstream systems, and ultimately improve the real-name success rate.

[0140] In another embodiment of the present application, see Figure 5 , which shows a schematic diagram of the structure of a calling device 50 provided in an embodiment of the present application. Figure 5 As shown, the calling device 50 may include a first determining unit 501, a second determining unit 502, and a retrying unit 503, wherein:

[0141] The first determining unit 501 is configured to determine the number of call failures; the number of call failures represents the total number of failed calls when the call to the callee fails;

[0142] The second determining unit 502 is configured to determine a retry interval according to the number of call failures and a random factor;

[0143] The retry unit 503 is configured to re-call the called party according to the retry interval.

[0144] In some embodiments, the second determining unit 502 is configured to determine an initial retry interval based on the number of call failures and an exponential backoff algorithm; and obtain a random factor, and determine a retry interval based on the random factor and the initial retry interval.

[0145] In some embodiments, the second determining unit 502 is configured to determine the number of interval time slots according to the number of call failures and the exponential backoff algorithm; and determine the product of the number of interval time slots and the preset time slot as the initial retry interval.

[0146] In some embodiments, the second determining unit 502 is configured to generate a random factor using a random algorithm; and determine the sum of the initial retry interval and the random factor as the retry interval.

[0147] In some embodiments, the retry unit 503 is configured to determine whether a retry condition is met after the call to the callee fails and a retry interval is set; if the retry condition is met, the callee is re-called; if the retry condition is not met, the call is determined to have failed, and the retry interval is dynamically adjusted.

[0148] In some embodiments, the retry unit 503 is configured to determine the load status of the caller and the service status of the callee; if the load of the caller is normal and the service of the callee is available, it is determined that the retry condition is met; if the load of the caller is abnormal and / or the service of the callee is unavailable, it is determined that the retry condition is not met.

[0149] In some embodiments, the retry unit 503 is configured to determine a service unavailable time period of the callee; and not re-call the callee during the service unavailable time period.

[0150] It should be noted that the calling device 50 provided in the embodiment of the present application is used to execute the aforementioned call retry method. For details not described in the embodiment of the present application, please refer to the description of the aforementioned embodiment for understanding. This solution can be widely used in application scenarios that require network calls, including but not limited to the Internet of Vehicles, the Internet of Things, cloud-edge collaboration and other fields.

[0151] It is understood that in this embodiment, a "unit" can be a portion of a circuit, a portion of a processor, a portion of a program or software, etc., and can also be a module or a non-modular system. Furthermore, the various components in this embodiment can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit. The aforementioned integrated units can be implemented in the form of hardware or software functional modules.

[0152] If the integrated unit is implemented in the form of a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, or the part that contributes to the existing technology, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the call retry method described in this embodiment. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0153] Therefore, this embodiment provides a computer storage medium storing a computer program. When the computer program is executed by at least one processor, the call retry method described in any one of the aforementioned embodiments is implemented.

[0154] Based on the above-mentioned composition of the calling device 50 and the computer storage medium, see Figure 6 , which shows a specific hardware structure example of a caller device 60 provided in an embodiment of the present application, which may include: a communication interface 601, a memory 602 and a processor 603; each component is coupled together through a bus system 604. It can be understood that the bus system 604 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 604 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 6 In FIG, various buses are labeled as bus system 604.

[0155] Communication interface 601, used for sending and receiving signals during the process of sending and receiving information with other external network elements;

[0156] Memory 602, used to store computer programs that can be run on processor 603;

[0157] The processor 603 is configured to execute the call retry method in any one of the aforementioned embodiments when running the computer program.

[0158] It is understood that the memory 602 in the embodiment of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDRSDRAM), enhanced synchronous DRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus random access memory (DRRAM). The memory 602 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0159] Processor 603 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits or software instructions in processor 603. The above processor 603 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in memory 602, and processor 603 reads the information in memory 602 and, in conjunction with its hardware, completes the steps of the above method.

[0160] It is understood that the embodiments described herein may be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, or other electronic units or combinations thereof for performing the functions described herein.

[0161] For software implementation, the techniques described herein can be implemented by modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0162] It should be noted that, in this application, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0163] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0164] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0165] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0166] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0167] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0168] The above description is merely a preferred embodiment of the present application and is not intended to limit the scope of protection of the present application.

[0169] It should be noted that, in this application, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0170] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0171] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0172] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0173] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0174] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A call retry method, characterized in that: Applied to the caller, the call retry method includes: Determine the number of call failures; the number of call failures represents the total number of failed calls to the callee; Determine the retry interval based on the number of call failures and a random factor; The called party is re-called according to the retry interval.

2. The call retry method according to claim 1, characterized in that: Determining the retry interval according to the number of call failures and a random factor includes: Determine an initial retry interval based on the number of call failures and an exponential backoff algorithm; A random factor is obtained, and the retry interval is determined according to the random factor and the initial retry interval.

3. The call retry method according to claim 2, characterized in that: The determining of the initial retry interval according to the number of call failures and the exponential backoff algorithm includes: Determining the number of interval time slots based on the number of call failures and an exponential backoff algorithm; The product of the number of interval time slots and a preset time slot is determined as the initial retry interval time.

4. The call retry method according to claim 2, characterized in that: The obtaining of a random factor and determining the retry interval according to the random factor and the initial retry interval includes: Generating the random factor using a random algorithm; The sum of the initial retry interval and the random factor is determined as the retry interval.

5. The call retry method according to claim 1, characterized in that: The re-calling of the called party according to the retry interval time includes: After the call to the callee fails and the retry interval has elapsed, determining whether a retry condition is met; If the retry condition is met, re-call the callee; If the retry condition is not met, the call is determined to have failed, and the retry interval is dynamically adjusted.

6. The call retry method according to claim 5, characterized in that: The determining whether the retry condition is met includes: Determining the load status of the caller and the service status of the callee; If the load of the caller is normal and the service of the callee is available, determining that the retry condition is met; If the load of the caller is abnormal and / or the service of the callee is unavailable, it is determined that the retry condition is not met.

7. The call retry method according to claim 6, characterized in that: In the case that the service of the called party is unavailable, the call retry method further includes: Determining a service unavailable time period of the called party; During the service unavailable time period, the called party is not called again.

8. A calling device, characterized in that: The calling device includes: The first determining unit is configured to determine a number of call failures; the number of call failures represents a total number of failed calls to the callee; A second determining unit is configured to determine a retry interval according to the number of call failures and a random factor; The retry unit is configured to re-call the called party according to the retry interval time.

9. A calling device, characterized in that: The calling device includes a memory and a processor; wherein: The memory is used to store a computer program that can be run on the processor; The processor is configured to execute the call retry method according to any one of claims 1 to 7 when running the computer program.

10. A computer storage medium, characterized in that The computer storage medium stores a computer program, and when the computer program is executed by at least one processor, the call retry method according to any one of claims 1 to 8 is implemented.

Images