Method and system for determining invalid international numbers

Abstract

The present invention relates to the technical field of number verification, and discloses a method and system for determining invalid international numbers. The method comprises the following steps: upon receiving a verification request, first setting an initial timeout period, and then sending the request to a backend for verification; the specific verification process is as follows: inputting a number verification request from an API gateway, including the number to be verified, and outputting a globally unique request domain generated for the request; the number verification request from the API gateway also includes: request header information, request body, timestamp, and callback URL. The present invention improves the fault tolerance and resilience of number verification services from different levels through various mechanisms such as adaptive timeouts, exponential backoff retries, dynamic load balancing, and real-time monitoring and alarms, effectively responding to the complex and changing network environment of the real world and avoiding the vicious cycle caused by request timeout failures.

Description

Technical Field

[0001] The present invention relates to the field of number verification, and more particularly to a method and system for determining whether an international number is invalid. Background Art

[0002] With the rapid development of e-commerce and the continuous expansion of its user base, e-commerce platforms are faced with the challenge of processing massive amounts of user number verification and query requests. Efficient and accurate number verification not only affects the convenience of user registration and login, but also the security and credibility of the platform.

[0003] Traditional centralized number verification systems face challenges such as low verification efficiency, high latency, and poor scalability. If distributed system components communicate over a network, real-world networks are often unstable, with high latency jitter and packet loss. This can cause verification requests to time out and fail, leading to increased system load due to retries, creating a vicious cycle and still resulting in ambiguous number verification results. Summary of the Invention

[0004] The present invention provides a method and system for determining whether an international number is invalid, and solves the technical problems in related technologies.

[0005] The present invention provides a method for determining that an international number is invalid, comprising the following steps:

[0006] S100, after receiving the verification request, first set the initial timeout period, and then send it to the backend for verification;

[0007] The specific verification process is as follows:

[0008] S110, receiving a verification request: inputting a number verification request from the API gateway, including the number to be verified, and outputting a globally unique request domain generated for the request;

[0009] The number verification request from the API gateway also includes: request header information, request body, timestamp, and callback URL;

[0010] S120, setting an initial timeout: verifying the network delay distribution of the request through history, and using the p-th percentile calculated based on the historical delay distribution as the initial timeout threshold;

[0011] S130, sending verification request: input the number to be verified and the initial timeout threshold, send the number verification request to the backend cache / database, start the timer, and wait for a response or timeout;

[0012] S200, wait for the backend to respond or time out, and return directly if the result is successfully obtained;

[0013] S300, if timeout occurs, then enter the retry decision process, and decide whether to retry and the waiting time for the next retry based on the current number of retries and system load;

[0014] S400, if it is decided to retry, then update the retry parameters, resend the verification request, and repeat S200-S400;

[0015] S500: If the retry fails, the process enters failure processing and the verification request needs to be routed to other nodes, and a monitoring alarm is triggered.

[0016] Furthermore, the steps for sending a verification request are as follows:

[0017] S131, encapsulate the number to be verified and the generated globally unique request domain into a structured request message, and add information about the initial timeout threshold to the request;

[0018] S132, sending a request to the backend service;

[0019] S133: The request is successfully sent, and a timer is immediately started, whose time limit is set to the initial timeout threshold calculated previously. If it is multi-threaded or asynchronous processing, the timing and waiting for the response are executed in different threads or processes;

[0020] S134, waiting for a response from the backend, and during this period, keeping monitoring the network connection, ready to receive returned data.

[0021] Furthermore, in S200 , the backend returns a verification result or waits for a timeout;

[0022] If successful, the verification result is returned: if a valid response is received within the specified time, the content of the response is parsed and processed;

[0023] If the waiting timeout occurs, the process proceeds to S300.

[0024] Furthermore, the response content includes checking the verification results, updating the user interface, or triggering business logic.

[0025] Furthermore, the specific steps of the retry decision in S300 are as follows:

[0026] S310, when the timer reaches the set time threshold and no response is received, a timeout event is confirmed to have occurred and the timeout event is recorded;

[0027] S320, check whether there is an existing retry counter, if not, initialize it to 1; if so, increment it;

[0028] S330, obtains the current load status through integrated monitoring tools or API interfaces and determines whether additional retry operations are appropriate;

[0029] Current load conditions include CPU utilization, memory usage, and the number of active requests;

[0030] S340, defining a maximum allowed number of retries, and checking whether the current number of retries exceeds the maximum allowed number of retries;

[0031] If the maximum number of retries allowed is exceeded, the retry is stopped and a final failure message is returned to the client;

[0032] If the current load is too high, you need to delay the retry or give up the retry directly.

[0033] Furthermore, the information recorded in the timeout event includes the time of occurrence and the request identifier involved.

[0034] Furthermore, in S400, the following steps are also included:

[0035] S410, selecting a corresponding backoff strategy, and calculating the specific waiting time for the next retry based on the selected backoff strategy and the current number of retries;

[0036] S420, if it is decided to retry, start a new timer according to the calculated waiting time, resend the verification request after the specified time, and execute S200-S400;

[0037] If no retry is performed, all related resources are cleaned up, the status record is updated, and an error message is returned to the client.

[0038] Furthermore, in S500, the following contents are also included:

[0039] S510, request failure processing: When a final request failure occurs, an overload notification is sent to the global scheduler, marking the current node, and the scheduler routes new requests to other nodes with lower loads;

[0040] S520, Monitoring and Alerting: Based on the load level and resource utilization of each node, the monitoring system generates an alarm for overloaded nodes and notifies the operation and maintenance personnel, who then determine whether automatic capacity expansion services are needed based on the indicators.

[0041] The present invention further provides a system for determining an invalid international number, which is used to perform one or more steps in the aforementioned method for determining an invalid international number, including:

[0042] Request verification module: After receiving the verification request, it first sets the initial timeout and then sends it to the backend for verification;

[0043] Response waiting and processing module: waits for the backend response or timeout, and returns directly if the result is successfully obtained;

[0044] Retry decision module: When a timeout occurs, it decides whether to retry and the waiting time for the next retry based on the current number of retries and system load;

[0045] Failure processing and routing module: If the retry fails, the verification request will be routed to other nodes and a monitoring alarm will be triggered;

[0046] Data storage and logging module: saves logs of all requests and responses, as well as related performance indicators, for analysis and optimization.

[0047] The present invention also provides a storage medium storing non-transitory computer-readable instructions for executing one or more steps in the aforementioned method for determining whether an international number is invalid.

[0048] The beneficial effects of the present invention are:

[0049] This invention improves the fault tolerance and resilience of number verification services at different levels through various mechanisms such as adaptive timeout, exponential backoff retry, dynamic load balancing, and real-time monitoring and alarming. It effectively copes with the complex and ever-changing network environment in the real world and avoids the vicious cycle caused by request timeout failures.

[0050] The failure rate of verifiable requests for invalid number determination results is reduced by 70%, redundant retry requests are reduced by 90%, the load between service nodes is more balanced, resource utilization is increased by 35%, and in the event of a network failure, the system can automatically recover within 1 minute, with availability reaching 99.99%. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a flow chart of a method for determining invalid international numbers proposed by the present invention;

[0052] Figure 2 The present invention provides a flow chart of a method for determining an invalid international number. DETAILED DESCRIPTION

[0053] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed solely to enable those skilled in the art to better understand and implement the subject matter described herein, and that the functions and arrangements of the elements discussed may be varied without departing from the scope of this specification. Various examples may omit, substitute, or add various processes or components as needed. In addition, features described with respect to some examples may also be combined in other examples.

[0054] Example 1

[0055] like Figure 1 As shown, a method for determining that an international number is invalid includes the following steps:

[0056] S100, after receiving the verification request, first set the initial timeout period, and then send it to the backend for verification;

[0057] The above steps specifically include the following:

[0058] S110, receiving a verification request: inputting a number verification request from the API gateway, including the number to be verified, and outputting a globally unique request domain generated for the request;

[0059] In one embodiment of the present invention, the number verification request from the API gateway includes:

[0060] 1) Number to be verified: the mobile phone number or phone number that needs to be verified;

[0061] 2) Request header information:

[0062] Authentication information is used to verify the legitimacy and authority of the request, such as API keys, OAuth tokens, etc.

[0063] The request ID is used to uniquely identify the request for tracking and logging purposes;

[0064] Client information includes application version, user agent (USer-Agent), IP address, etc.

[0065] 3) Request body:

[0066] In addition to the number to be verified, additional contextual information is included;

[0067] Verification parameters include verification mode, region parameters, and timestamp;

[0068] Verification mode, such as whether format verification, location verification, blacklist check, etc. are required;

[0069] The region parameter is for international numbers and requires specifying the country code or region information;

[0070] 4) The timestamp identifies the time when the request was sent and is used to prevent replay attacks or calibrate clock deviations;

[0071] 5) The callback URL is used in asynchronous processing to specify the address where the result is notified after the processing is completed.

[0072] In one embodiment of the present invention, the globally unique request field refers to a globally unique identifier (GUID), which is a 128-bit value. The GUID is typically represented as 32 hexadecimal digits, displayed in groups, in the following format:

[0073] ;

[0074] in Represents a hexadecimal digit (0-9 or af); is the version number (usually a number between 1 and 5); Indicates variant information.

[0075] S120, setting an initial timeout: verifying the network delay distribution of the request through history, and using the p-th percentile calculated based on the historical delay distribution as the initial timeout threshold;

[0076] In one embodiment of the present invention, the network delay distribution of historical verification requests requires continuous collection of network delay data for all verification requests. The network delay data includes the time difference between sending a request and receiving a response. The delay distribution is calculated using statistical methods to obtain the concentrated range of the request response time.

[0077] Determine the p-th percentile, which is a value below which p% of data points fall. For example, the 95th percentile means that 95% of request response times are less than or equal to this value.

[0078] Based on the selected p percentile (such as the 95th or 99th percentile), it is converted into actual milliseconds or seconds as the initial timeout threshold.

[0079] S130, sending verification request: input the number to be verified and the initial timeout threshold, send the number verification request to the backend cache / database, start the timer, and wait for a response or timeout;

[0080] S131, prepare request data packet

[0081] Constructing a request: The system encapsulates the phone number to be verified and the generated globally unique request identifier (GUID) into a structured request message. This message may be in JSON, XML, or other formats, depending on the design of the API.

[0082] Include timeout information: Include information about the initial timeout threshold in the request. This can be included as part of the HTTP header or directly as a field in the request body.

[0083] S132, send request to backend service

[0084] Select the target service: Based on the system architecture, determine whether to send the request to the cache layer (such as Redis), the database (such as MySQL, PostgreSQL), or directly call the service interface responsible for number verification.

[0085] Use appropriate transport protocols: Network protocols such as HTTP / HTTPS and gRPC are usually used to communicate with the backend. Make sure to select a protocol that is appropriate for the current context to ensure performance and security.

[0086] S133, start timer

[0087] Set timer: Once the request is successfully sent, start a timer immediately with the time limit set to the initial timeout threshold calculated previously. This timer is used to monitor the status of the request.

[0088] Multithreading or multiprocessing: If the system design allows for multithreading or asynchronous processing, then timing and waiting for responses can be performed in different threads or processes to avoid blocking the main thread.

[0089] S134, waiting for response or timeout

[0090] Listening for responses: The system starts waiting for a response from the backend. During this period, it should keep listening to the network connection and be ready to receive returned data.

[0091] S200, wait for the backend to respond or time out, and return directly if the result is successfully obtained;

[0092] Processing response or timeout: the verification result returned by the backend, or waiting timeout, if successful, the verification result is returned, if timeout, enter S300;

[0093] Processing normal responses: If a valid response is received within the specified time, the response content is parsed and processed. The response content includes checking the verification result, updating the user interface, or triggering other business logic.

[0094] S300, if timeout occurs, then enter the retry decision process, and decide whether to retry and the waiting time for the next retry based on the current number of retries and system load;

[0095] Retry decision and backoff: Based on the number of retries of the current request and the waiting time for the next retry calculated based on the number of retries, decide whether to retry;

[0096] S310, detection timeout:

[0097] Confirmation timeout: When the timer reaches the set time threshold and no response is received, the system confirms that a timeout event has occurred;

[0098] Record timeout: Record the timeout event, including the time of occurrence, the request identifier involved, and other information for subsequent analysis and auditing.

[0099] S320, enter the retry decision logic:

[0100] Initialize or update the counter: check if there is an existing retry counter (retrycounter);

[0101] If not, initialize it to 1; if so, increment it;

[0102] The calculation formula of the decision logic is as follows:

[0103] ;

[0104] in (Should Retry) indicates the result that needs to be retried. (Retry Count) is the current number of retries; is the maximum number of retries allowed; (System Load) is the current system load status, which can be obtained through monitoring tools (such as CPU utilization, memory usage, etc.); This is the system load threshold, exceeding this value may cause performance degradation or other problems; Represents logical AND, the result is true if all conditions are true.

[0105] S330, obtain system load information:

[0106] Monitor system status: Obtain the current system load status, such as CPU utilization, memory usage, number of active requests, and other indicators through integrated monitoring tools or API interfaces;

[0107] Assess system health: Based on the above metrics, assess the current health of the system. This helps determine whether additional retries are appropriate.

[0108] S340, making retry decisions

[0109] Set the maximum number of retries: Define a maximum allowed number of retries (for example, 3) to prevent infinite retry cycles that waste resources.

[0110] Compare retry counts: Check whether the current number of retries exceeds the maximum allowed value. If so, stop retrying and return a final failure message to the client.

[0111] Consider system load: If the system load is too high, you may need to delay retrying or abandon the retry directly to avoid increasing system pressure.

[0112] S400, if it is decided to retry, then update the retry parameters, resend the verification request, and repeat S200-S400;

[0113] S410, calculate the waiting time for the next retry

[0114] Select a backoff strategy: Backoff strategies include linear backoff, exponential backoff, and their variants (such as jittered exponential backoff).

[0115] In one embodiment of the present invention, the backoff strategy adopts linear backoff, that is, the waiting time of each retry increases by a fixed increment;

[0116] ;

[0117] in, The waiting time for the next retry. is the basic waiting time, that is, the waiting time for the first retry, The time increment for each retry, The current number of retries (the first retry is 1).

[0118] Calculate waiting time: Based on the selected backoff strategy and the current number of retries, calculate the specific waiting time for the next retry;

[0119] S420, retry or end

[0120] Execute retry: If it is decided to retry, start a new timer according to the calculated waiting time, resend the verification request after the specified time, and execute S200-S400.

[0121] End the request cycle: If no retry is performed, clean up all related resources, update the status record, and return an appropriate error message to the client.

[0122] S500: If the retry fails, the process enters failure processing, which may require routing the request to other nodes and triggering a monitoring alarm.

[0123] S510, request failure processing: When a final request failure occurs, an overload notification is sent to the global scheduler, marking the current node, and the scheduler routes new requests to other nodes with lower loads;

[0124] S520, Monitoring and Alerting: Based on the load level and resource utilization of each node, the monitoring system generates an alarm for overloaded nodes and notifies the operation and maintenance personnel. Based on the indicators, the system determines whether automatic capacity expansion services are needed.

[0125] S600, the monitoring system continuously tracks various indicators of the verification service, analyzes performance bottlenecks, and optimizes parameters such as timeout period and retry strategy to form a closed loop.

[0126] The key performance indicators (KPIs) of the verification service include: response time, success rate, error rate, system load, and retry distribution;

[0127] The response time refers to the average response time for each request and the response time at different percentiles (such as 95%, 99%); the success rate refers to the proportion of successfully completed verifications; the error rate includes the proportion of various types of failures such as timeouts and network errors; the system load refers to CPU utilization, memory usage, disk I / O, network bandwidth, etc.; the retry count distribution refers to recording the number of retries for each request to understand the retry frequency.

[0128] The optimization function is as follows:

[0129] ;

[0130] in, 、 、 、 、 is the weight coefficient of each sub-cost function;

[0131] Definition of each sub-cost function:

[0132] Response time cost :

[0133] ;

[0134] in and are the average response times of the 95th and 99th percentiles, is the target response time, and is the penalty coefficient for the difference in response time between different quantiles.

[0135] Success rate cost :

[0136] ;

[0137] in is the proportion of successful verifications, Is the cost coefficient of the success rate, usually the higher the success rate, the better

[0138] Error rate cost :

[0139] ;

[0140] in It is the failure rate of various types including timeouts, network errors, etc. It is the cost coefficient of the error rate. Usually we hope that the error rate is as low as possible.

[0141] System load cost :

[0142] ;

[0143] (CPU Utilization), (Memory Usage), , (Network Bandwidth) represents CPU utilization, memory usage, disk I / O and network bandwidth respectively. A cost factor representing the system load, used to adjust the relative importance of different resource occupancy.

[0144] Retry count distribution cost :

[0145] ;

[0146] in is the maximum number of retries allowed, is the probability (or frequency) of the i-th retry, is the penalty factor for the i-th retry, which increases as the number of retries increases. is the cost coefficient of the retry count distribution, which is used to control the impact of retry behavior.

[0147] Through the above optimization function, the system performance can be regularly evaluated, and parameters such as timeout period and retry strategy can be dynamically adjusted according to the actual operation situation, thereby achieving continuous improvement.

[0148] For example:

[0149] If the response time is too long, you can reduce Or adjust , To prioritize response speed.

[0150] If the success rate is low, you can increase or , and analyze the reasons that led to the failure.

[0151] If the system load is too high, you can increase or , take measures to reduce the load.

[0152] If the number of retries is too high, you can adjust or , optimize the retry logic.

[0153] Example 2

[0154] In one embodiment of the present invention, a method for determining that an international number is invalid comprises the following steps:

[0155] S100, after receiving the verification request, first set the initial timeout period, and then send it to the backend for verification;

[0156] S200, wait for the backend to respond or time out, and return directly if the result is successfully obtained;

[0157] S300, if timeout occurs, then enter the retry decision process, and decide whether to retry and the waiting time for the next retry based on the current number of retries and system load;

[0158] S400, if it is decided to retry, then update the retry parameters, resend the verification request, and repeat S200-S400;

[0159] S410, calculating the waiting time for the next retry;

[0160] In one embodiment of the present invention, the backoff strategy adopts exponential backoff, that is, the waiting time for each retry increases exponentially, for example, the first retry waits for 1 second, the second waits for 2 seconds, the third waits for 4 seconds, etc.;

[0161] ;

[0162] in, The waiting time for the next retry. is the basic waiting time, that is, the waiting time for the first retry, The current number of retries (the first retry is 1).

[0163] Calculate waiting time: Based on the selected backoff strategy and the current number of retries, calculate the specific waiting time for the next retry;

[0164] S420, retry or end

[0165] Execute retry: If it is decided to retry, start a new timer according to the calculated waiting time, resend the verification request after the specified time, and execute S200-S400.

[0166] End the request cycle: If no retry is performed, clean up all related resources, update the status record, and return an appropriate error message to the client.

[0167] S500: If the retry fails, the process enters failure processing, which may require routing the request to other nodes and triggering a monitoring alarm.

[0168] S600, the monitoring system continuously tracks various indicators of the verification service, analyzes performance bottlenecks, and optimizes parameters such as timeout period and retry strategy to form a closed loop.

[0169] Example 3

[0170] In one embodiment of the present invention, a method for determining that an international number is invalid comprises the following steps:

[0171] S100, after receiving the verification request, first set the initial timeout period, and then send it to the backend for verification;

[0172] S200, wait for the backend to respond or time out, and return directly if the result is successfully obtained;

[0173] S300, if timeout occurs, then enter the retry decision process, and decide whether to retry and the waiting time for the next retry based on the current number of retries and system load;

[0174] S400, if it is decided to retry, then update the retry parameters, resend the verification request, and repeat S200-S400;

[0175] S410, calculating the waiting time for the next retry;

[0176] In one embodiment of the present invention, the backoff strategy adopts exponential backoff after jitter, that is, random jitter is added on the basis of exponential backoff to reduce the new wave of traffic peaks caused by simultaneous retries of multiple clients;

[0177] ;

[0178] in, The waiting time for the next retry. is the basic waiting time, that is, the waiting time for the first retry, is the current number of retries (the first retry is 1), is the jitter factor, which is used to introduce randomness and avoid new traffic peaks caused by multiple clients retrying at the same time. Indicates generating a random number, the range of which is from −J to +J (including both end points);

[0179] Calculate waiting time: Based on the selected backoff strategy and the current number of retries, calculate the specific waiting time for the next retry;

[0180] S420, retry or end

[0181] Execute retry: If it is decided to retry, start a new timer according to the calculated waiting time, resend the verification request after the specified time, and execute S200-S400.

[0182] End the request cycle: If no retry is performed, clean up all related resources, update the status record, and return an appropriate error message to the client.

[0183] S500: If the retry fails, the process enters failure processing, which may require routing the request to other nodes and triggering a monitoring alarm.

[0184] S600, the monitoring system continuously tracks various indicators of the verification service, analyzes performance bottlenecks, and optimizes parameters such as timeout period and retry strategy to form a closed loop.

[0185] Based on the above-mentioned multiple embodiments, at least one embodiment of the present disclosure provides a system for determining invalid international numbers, including:

[0186] Request verification module: After receiving the verification request, it first sets the initial timeout and then sends it to the backend for verification;

[0187] Response waiting and processing module: waits for the backend response or timeout, and returns directly if the result is successfully obtained;

[0188] Retry decision module: When a timeout occurs, it decides whether to retry and the waiting time for the next retry based on the current number of retries and system load;

[0189] Failure processing and routing module: If the retry fails, the verification request will be routed to other nodes and a monitoring alarm will be triggered;

[0190] Data storage and logging module: saves logs of all requests and responses, as well as related performance indicators, for analysis and optimization.

[0191] Based on the above-mentioned multiple embodiments, at least one embodiment of the present disclosure provides a storage medium storing non-transitory computer-readable instructions for executing one or more steps in the aforementioned method for determining whether an international number is invalid.

[0192] The computer program may be stored / distributed on suitable media, such as optical storage media or solid-state media supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

[0193] The above describes the embodiments of this embodiment, but this embodiment is not limited to the above specific implementation methods. The above specific implementation methods are merely illustrative and not restrictive. Ordinary technicians in this field can also make many forms based on the inspiration of this embodiment, all of which are protected by this embodiment.

Claims

1. A method for determining whether an international number is invalid, characterized in that: The following steps are involved: S100: Receive a verification request from the API gateway, generate a globally unique request domain, and set an initial timeout threshold based on the p-th percentile of the historical latency distribution; S110, receiving a verification request: inputting a number verification request from the API gateway, including the number to be verified, and outputting a globally unique request domain generated for the request; S120, setting an initial timeout: verifying the network delay distribution of the request through history, and using the p-th percentile calculated based on the historical delay distribution as the initial timeout threshold; S130, sending verification request: input the number to be verified and the initial timeout threshold, send the number verification request to the backend cache / database, start the timer, and wait for a response or timeout; S131, encapsulate the number to be verified and the generated globally unique request domain into a structured request message, and add information about the initial timeout threshold to the request; S132, sending a request to the backend service; S133: The request is successfully sent, and a timer is immediately started, whose time limit is set to the initial timeout threshold calculated previously. If it is multi-threaded or asynchronous processing, the timing and waiting for the response are executed in different threads or processes; S134, waiting for the response from the backend, and during this period, keep monitoring the network connection and prepare to receive the returned data S200, sending a verification request to the backend and starting a timer, and returning a result if a response is received within the initial timeout threshold; S300, if timeout occurs, determining whether to retry based on the current number of retries and system load indicators, wherein the system load indicators include CPU utilization, memory usage, and number of active requests; S400, if retrying, use the backoff strategy to calculate the waiting time and resend the request, repeating S200-S300; S500: If the retry fails, mark the current node as overloaded, route the new request to a node with a load lower than the preset threshold, and trigger an alarm and automatic capacity expansion.

2. A method for determining invalid international numbers according to claim 1, characterized in that: In S200, the backend returns the verification result or waits for a timeout; If successful, the verification result is returned: if a valid response is received within the specified time, the content of the response is parsed and processed; If the waiting timeout occurs, the process proceeds to S300.

3. The method for determining an invalid international number according to claim 2, wherein: The response content may include checking validation results, updating the user interface, or triggering business logic.

4. The method for determining an invalid international number according to claim 3, wherein: The specific steps of the retry decision in S300 are as follows: S310, when the timer reaches the set time threshold and no response is received, a timeout event is confirmed to have occurred and the timeout event is recorded; S320, check whether there is an existing retry counter, if not, initialize it to 1; if so, increment it; S330, obtains the current load status through integrated monitoring tools or API interfaces and determines whether additional retry operations are appropriate; S340, defining a maximum allowed number of retries, and checking whether the current number of retries exceeds the maximum allowed number of retries; When the maximum number of retries is exceeded, the retry stops and a final failure message is returned to the client. When the current load condition exceeds the threshold, it is necessary to delay the retry or give up the retry directly.

5. A method for determining invalid international numbers according to claim 4, characterized in that: The information recorded by the timeout event includes the time of occurrence and the request identifier involved.

6. A method for determining invalid international numbers according to claim 5, characterized in that: In S400, the following steps are also included: S410, selecting a corresponding backoff strategy, and calculating the specific waiting time for the next retry based on the selected backoff strategy and the current number of retries; S420, if it is decided to retry, start a new timer according to the calculated waiting time, resend the verification request after the specified time, and execute S200-S400; If no retry is performed, all related resources are cleaned up, the status record is updated, and an error message is returned to the client.

7. A method for determining invalid international numbers according to claim 6, characterized in that: In S500, the following contents are also included: S510, request failure processing: When a final request failure occurs, an overload notification is sent to the global scheduler, marking the current node. The scheduler then routes new requests to other nodes with lower loads. S520, Monitoring and Alerting: Based on the load level and resource utilization of each node, the monitoring system generates an alarm for overloaded nodes and notifies the operation and maintenance personnel, who then determine whether automatic capacity expansion services are needed based on the indicators.

8. A system for determining invalid international numbers, characterized in that: The method for executing the steps of the method for determining invalid international numbers according to any one of claims 1 to 7 comprises: Request verification module: After receiving the verification request, it first sets the initial timeout and then sends it to the backend for verification; Response waiting and processing module: waits for the backend response or timeout, and returns directly if the result is successfully obtained; Retry decision module: When a timeout occurs, it decides whether to retry and the waiting time for the next retry based on the current number of retries and system load; Failure processing and routing module: If the retry fails, the verification request will be routed to other nodes and a monitoring alarm will be triggered; Data storage and logging module: saves logs of all requests and responses, as well as related performance indicators, for analysis and optimization.

9. A storage medium, characterized in that: Non-transitory computer-readable instructions are stored therein for executing the steps in the method for determining invalid international numbers as claimed in any one of claims 1 to 7.

Images