International number invalidation judgment method and system

Abstract

The invention relates to the technical field of number verification, and discloses an international number invalidation judgment method and system, and the method comprises the following steps: after receiving a verification request, firstly setting an initial timeout time, and then sending the initial timeout time to a rear end for verification; the specific process of verification is as follows: a number verification request including a number to be verified from the API gateway is input, a globally unique request domain generated for the request is output, and the number verification request from the API gateway further comprises request header information, a request body, a timestamp and a callback URL (Uniform Resource Locator). According to the method, the fault tolerance and toughness of the number verification service are improved from different levels through various mechanisms such as self-adaptive timeout, exponential backoff retry, dynamic load balancing and real-time monitoring alarm, the complex and changeable network environment in the real world is effectively dealt with, and vicious circle caused by request timeout failure is avoided.

Description

Technical Field

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

[0002] With the booming development of e-commerce and the continuous expansion of user scale, e-commerce platforms need to handle a large number of user number verification and query requests. Efficient and accurate number verification is not only related to the convenience of user registration and login, but also affects the security and credibility of the platform.

[0003] Traditional centralized number verification systems face problems such as low verification efficiency, high latency, and poor scalability. If distributed system components communicate through the network, the actual network is often unstable, with large latency jitter and high packet loss rate, which may cause the verification request to time out and fail. Retries increase the system load, forming a vicious cycle, which still results in unclear number determination 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 time, 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 an 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 time: using the network delay distribution of the historical verification request, and calculating the p quantiles according to the historical delay distribution as the initial timeout threshold;

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

[0012] S200, waiting for the backend response or timeout, and returning directly if the result is successfully obtained;

[0013] S300, if the 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] Further, the steps of sending a verification request are as follows:

[0017] S131, encapsulating the number to be verified and the generated globally unique request domain into a structured request message, and adding 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 maintaining a monitoring state for the network connection, ready to receive returned data.

[0021] Further, 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 content of the response includes checking the verification result, updating the user interface, or triggering the 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, confirming that a timeout event has occurred, and recording the timeout event;

[0027] S320, checking whether there is an existing retry counter, if not, initializing it to 1; if so, incrementing it;

[0028] S330, obtain the current load status through an integrated monitoring tool or an API interface to determine whether additional retry operations are appropriate;

[0029] The current load status includes CPU utilization, memory usage, and 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 condition 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 time that should be waited for the next retry according to 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 the final request fails, an overload notification is sent to the global scheduler, the current node is marked, and the scheduler routes the new request to other nodes with lower load;

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

[0041] The present invention also provides a system for determining an invalid international number, which is used to execute 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-temporary 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] The present invention improves the fault tolerance and resilience of the number verification service from different levels through various mechanisms such as adaptive timeout, exponential backoff retry, dynamic load balancing, and real-time monitoring and alarm, effectively copes with the complex and changeable network environment in the real world, and avoids the vicious cycle caused by request timeout failure.

[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 improved 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 It is a flow chart of a method for determining invalid international numbers proposed by the present invention;

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

[0053] The subject matter described herein will now be discussed with reference to example embodiments. It should be understood that the discussion of these embodiments is only to enable those skilled in the art to better understand and implement the subject matter described herein, and the functions and arrangements of the elements discussed may be changed without departing from the scope of protection of the contents of this specification. Each example may omit, replace or add various processes or components as needed. In addition, the features described relative to some examples may also be combined in other examples.

[0054] Embodiment 1

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

[0056] S100, after receiving the verification request, first set the initial timeout time, 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 an 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 easy tracking and logging;

[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, which is used to prevent replay attacks or calibrate clock deviations;

[0071] 5) The callback URL is used in asynchronous processing to specify the result notification address 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 usually represented as 32 hexadecimal digits, which are displayed in groups in the following format:

[0073] ;

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

[0075] S120, setting an initial timeout time: using the network delay distribution of the historical verification request, and calculating the p quantiles according to 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 of all verification requests, the network delay data includes the time difference between sending a request and receiving a response, and the delay distribution is calculated using a statistical method to obtain a concentrated range of the response time of the request;

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

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

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

[0080] S131, prepare request data packet

[0081] Construct a request: The system encapsulates the phone number to be verified and the generated globally unique request identifier (GUID) into a structured request message, which 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 suitable 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 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 response: 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, waiting for the backend response or timeout, and returning 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 occurs, enter S300;

[0093] Process normal responses: If a valid response is received within the specified time, parse and process the response content, which includes checking the verification result, updating the user interface, or triggering other business logic;

[0094] S300, if the 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: decide whether to retry 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;

[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.); is the threshold of system load, 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 through integrated monitoring tools or API interfaces, such as CPU utilization, memory usage, number of active requests, and other indicators;

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

[0108] S340, Make retry decisions

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

[0110] Compare the number of retries: Check whether the current number of retries exceeds the maximum allowed value. If it exceeds, 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 the retry or give up 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 a 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 time that should be waited 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 retries are made, 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 will enter failure processing, and the request may need to be routed to other nodes, and a monitoring alarm may be triggered;

[0123] S510, request failure processing: when the final request fails, an overload notification is sent to the global scheduler, the current node is marked, and the scheduler routes the new request to other nodes with lower load;

[0124] S520, monitoring and alarming: Based on the load level and resource utilization of each node, the monitoring system generates an alarm for the overloaded node and notifies the operation and maintenance personnel to determine whether automatic capacity expansion services are needed based on the indicators;

[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 various 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 of each request and the response time of different quantiles (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 It 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, It is the cost coefficient of the success rate. Usually, we hope that the success rate is as high as possible.

[0138] Error rate cost :

[0139] ;

[0140] in It is the failure ratio 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), , (NetworkBandwidth) represents CPU utilization, memory usage, disk I / O and network bandwidth respectively. A cost factor that represents the system load and is 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 ith retry, is the penalty factor for the i-th retry, which increases as the number of retries increases. is the cost factor for the retry count distribution, used to control the impact of retry behavior.

[0147] Through the above optimization function, the system performance can be evaluated regularly, and parameters such as timeout period and retry strategy can be dynamically adjusted according to the actual operation situation, so as to achieve 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] Embodiment 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 time, and then send it to the backend for verification;

[0156] S200, waiting for the backend response or timeout, and returning directly if the result is successfully obtained;

[0157] S300, if the 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 time that should be waited 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 retries are made, 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 will enter failure processing, and the request may need to be routed to other nodes, and a monitoring alarm may be triggered;

[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] Embodiment 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 time, and then send it to the backend for verification;

[0172] S200, waiting for the backend response or timeout, and returning directly if the result is successfully obtained;

[0173] S300, if the 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 a 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. It means to generate a random number, the range of which is from −J to +J (including the two end points);

[0179] Calculate waiting time: Based on the selected backoff strategy and the current number of retries, calculate the specific time that should be waited 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 retries are made, 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 will enter failure processing, and the request may need to be routed to other nodes, and a monitoring alarm may be triggered;

[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 above-mentioned 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 an embodiment of the present embodiment, but the present embodiment is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present embodiment, ordinary technicians in this field can also make many forms, all of which are within the protection of the present embodiment.

Claims

1. A method for determining whether an international number is invalid, characterized in that: The following steps are involved: S100, receiving a verification request from the API gateway, generating a globally unique request domain, and setting an initial timeout threshold based on the p-quantile of the historical delay distribution; 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, determine whether to retry based on the current number of retries and system load indicators, where 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 new requests to nodes with loads below a preset threshold, and trigger an alarm and automatic capacity expansion.

2. A method for determining whether an international number is invalid according to claim 1, characterized in that: The steps to send a verification request are as follows: S131, encapsulating the number to be verified and the generated globally unique request domain into a structured request message, and adding 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 a response from the backend, and during this period maintaining a monitoring state for the network connection, ready to receive returned data.

3. A method for determining whether an international number is invalid according to claim 2, characterized in that: In S200, the backend returns a 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.

4. A method for determining whether an international number is invalid according to claim 3, characterized in that: The response content may include checking validation results, updating the user interface, or triggering business logic.

5. A method for determining whether an international number is invalid according to claim 4, characterized in that: 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, confirming that a timeout event has occurred, and recording the timeout event; S320, checking whether there is an existing retry counter, if not, initializing it to 1; if so, incrementing it; S330, obtain the current load status through an integrated monitoring tool or an API interface to determine 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 allowed 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 directly give up the retry.

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

7. A method for determining whether an international number is invalid according to claim 6, characterized in that: In S400, the following steps are also included: S410, selecting a corresponding backoff strategy, and calculating the specific time that should be waited for the next retry according to 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.

8. A method for determining whether an international number is invalid according to claim 7, characterized in that: In S500, the following are also included: S510, request failure processing: when the final request fails, an overload notification is sent to the global scheduler, the current node is marked, and the scheduler routes the new request to other nodes with lower load; S520, monitoring and alarming: Based on the load level and resource utilization of each node, the monitoring system generates an alarm for the overloaded node and notifies the operation and maintenance personnel to determine whether automatic capacity expansion services are needed based on the indicators.

9. An international number invalidity determination system, characterized in that: The method for executing the steps in the method for determining an invalid international number as claimed in any one of claims 1 to 8 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.

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

Images