A Smart SMS Sending System and Method Based on an Invalid Number Database

Abstract

This invention relates to the field of communication technology, specifically to an intelligent SMS sending system and method based on an invalid number database. The system includes: an SMS access module for acquiring SMS sending request data; and an invalid number database management module for querying a time-sensitive invalid number database based on the target number in the SMS sending request data, and generating a number validity analysis result. This invention, through a time-sensitive invalid number database mechanism, can intercept historical invalid numbers such as those that are out of service or inactive before sending, avoiding the waste of channel resources caused by sending first and then failing in existing technologies. Simultaneously, it is combined with a six-dimensional traffic control matrix to implement differentiated traffic limiting based on SMS type, content, and region, effectively preventing malicious traffic boosting and harassment. Furthermore, the pre-deducting mechanism locks the balance before sending, completely eliminating the risk of overdraft and bad debts caused by traditional post-billing.

Description

Technical Field

[0001] This invention relates to the field of communication technology, specifically to an intelligent SMS sending system and method based on an invalid number database. Background Technology

[0002] With the rapid development of the mobile internet, SMS verification codes, marketing notifications, and logistics reminders have become key channels for interaction between enterprises and users. The throughput, delivery rate, and cost control capabilities of SMS sending systems directly affect the operational efficiency and user experience of enterprises. In the traditional SMS sending architecture, the system usually adopts a linear processing mode of "receiving requests - simple verification - calling channels - post-billing". However, with the explosive growth of SMS business volume and the increasing complexity of business scenarios, the traditional architecture has gradually exposed a series of technical bottlenecks that are difficult to overcome.

[0003] First, traditional systems typically rely on static blacklists or must wait for the operator to return a failure result before determining that a number is invalid, resulting in a serious waste of channel resources. Second, current rate limiting technologies are mostly based on general token bucket or leaky bucket algorithms, which can only achieve coarse-grained total quantity control and lack multi-dimensional management capabilities tailored to the characteristics of SMS services, making it unable to cope with complex business data fraud and harassment risks.

[0004] In addition, traditional billing often adopts the "post-call detail record" model, which means sending the call first, then billing, and then deducting the fee. This poses serious financial risks and user experience problems. Furthermore, traditional architectures often use synchronous blocking calls, with strong coupling between different parts, lacking elasticity and fault tolerance, resulting in weak ability to handle channel failures. Summary of the Invention

[0005] To achieve the above objectives, the present invention provides the following technical solution: an intelligent SMS sending system based on an invalid number database, comprising:

[0006] The SMS access module is used to obtain SMS sending request data; the SMS sending request data includes SMS type, target number, SMS content, country / region identifier, application identifier, and sending time information;

[0007] The invalid number database management module is used to query the invalid number database with time-sensitive management based on the target number in the SMS sending request data, and generate number validity analysis results; the number validity analysis results are used to indicate whether the target number is in a valid state;

[0008] The multi-dimensional flow control module is used to determine the flow restriction of SMS sending requests based on a preset six-dimensional flow control matrix when the number validity analysis results indicate that the target number is valid, and to obtain the flow control evaluation result.

[0009] The pre-deduction processing module is used to perform pre-deduction checks and balance locking operations on the sending account when the flow control assessment result indicates that the data has passed, and to obtain pre-deduction result data and sending task data containing sending task parameters by combining the SMS sending request data.

[0010] The asynchronous delivery module is used to dynamically select the optimal sending channel based on the pre-deduction result data and the current operator channel load status, and put the task data to be sent into the message queue. The asynchronous consumer thread parses the task and calls the operator interface to execute the SMS delivery.

[0011] The status management module is used to receive SMS delivery receipt data returned by the operator channel, update the actual deduction status in the pre-deduction result data according to the SMS delivery receipt data, and perform double rollback or channel switching retry for failed delivery tasks to generate target SMS delivery status data; and synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

[0012] Preferably, based on the target number in the SMS sending request data, a database of invalid numbers with time-sensitive management is queried to generate number validity analysis results, including:

[0013] Read the invalid number main table from the invalid number database, and determine whether the target number exists in the invalid number main table and whether the corresponding record is marked as not deleted;

[0014] If the target number exists in the invalid number main table, obtain the creation time of the corresponding record and calculate the time difference between the creation time and the current time;

[0015] The time difference is compared with the preset validity period of the invalid number database; the validity period of the invalid number database is set to three months.

[0016] If the time difference is less than or equal to three months, a number validity analysis result indicating that the target number is invalid will be generated;

[0017] If the time difference is greater than three months or the target number does not match the invalid number main table, a number validity analysis result indicating that the target number is valid will be generated.

[0018] Preferably, after generating the number validity analysis result indicating that the target number is invalid, the method further includes:

[0019] Construct a failure receipt object, set the error code to invalid number blocking, and write the blocking record to the record table in the invalid number database; the record table stores the message identifier, mobile phone number, country code, blocking code, and blocking information for each blocking;

[0020] Add the failure receipt object to the message queue to asynchronously notify the client of the intercepted status;

[0021] The pre-deduction processing module is invoked to perform a penalty deduction operation on the sending account, and the deduction amount is the standard fee corresponding to the SMS sending request.

[0022] Preferably, based on a preset six-dimensional flow control matrix, flow control judgment is performed on SMS sending requests to obtain flow control evaluation results, including:

[0023] Multidimensional feature parameters are extracted from SMS sending request data. These multidimensional feature parameters correspond to the dimensions of a six-dimensional traffic control matrix. The dimensions include SMS type, target mobile phone number, SMS content features, country / region identifier, application identifier, and time period.

[0024] Based on the Redis atomic counting mechanism, flow control key-value pairs are constructed corresponding to multi-dimensional feature parameters; among them, the flow control key-value pairs include daily count of CAPTCHA, daily count of marketing notification, daily count of duplicate content, daily count of country, monthly count of country, daily count of application, and monthly count of application.

[0025] Perform asynchronous batch increment operations on the send frequency of each dimension in the Redis cache; where a single batch operation includes counters for the above six dimensions.

[0026] Obtain preset traffic thresholds for each dimension; among them, verification code SMS is limited to 50 times per number per day, marketing and notification SMS is limited to 100 times per number per day, and repetitive content is limited to 5 times per number per day.

[0027] The real-time frequency obtained from the asynchronous batch increment operation is compared with the corresponding traffic threshold.

[0028] If the real-time frequency of any dimension exceeds the corresponding traffic threshold, a flow control assessment result indicating interception is generated; if the real-time frequency of all dimensions does not exceed the corresponding traffic threshold, a flow control assessment result indicating passage is generated.

[0029] Preferably, after performing pre-deduction checks and balance locking operations on the sending account and obtaining the pre-deduction result data, the process also includes:

[0030] Determine if the account has the balance check function enabled; if not, directly generate the pre-deduction result data for successful pre-deduction.

[0031] If balance check is enabled, verify whether the SMS price is valid, obtain the application's company identifier and settlement type, and construct a balance check request object;

[0032] The billing service sends a pre-deduction request to the billing service, which checks whether the account balance is sufficient and locks the corresponding amount in advance.

[0033] If the balance is insufficient, an insufficient balance error receipt is generated and sent to the client via a message queue, and the current sending request is rejected;

[0034] If the balance is sufficient, pre-deduction result data will be generated, including the locked amount, number of transactions, service type, and application identifier.

[0035] Preferably, based on pre-deducted payment results data and the current operator channel load status, the optimal transmission channel is dynamically selected, including:

[0036] Confirm the successful prepayment status based on the prepayment result data, and invoke the independent channel routing service;

[0037] The channel routing service queries the real-time load status, health status, and historical success rate of all configured carrier channels to obtain channel availability status data;

[0038] Based on the channel availability status data, each channel is weighted and sorted according to the preset routing strategy to select the current best operator channel and obtain the optimal channel selection data.

[0039] Based on the optimal channel selection data and combined with the SMS sending request information in the pre-deducted billing result data, generate task data to be sent that includes the target number, SMS content, channel identifier, unique task ID, and maximum number of retries.

[0040] Preferably, the task data to be sent is placed in a message queue, and an asynchronous consumer thread parses the task and calls the operator's interface to execute the SMS delivery, including:

[0041] Write the data of the task to be sent to the preset SMS sending message queue;

[0042] An asynchronous consumer thread retrieves the data of the task to be sent from the SMS sending message queue, and calls the corresponding operator channel interface to execute the SMS delivery operation based on the channel identifier in the data of the task to be sent.

[0043] After completing the SMS delivery operation, the system receives the original delivery result information returned by the operator channel and parses it together with the unique task ID in the task data to be sent to generate standardized SMS delivery receipt data.

[0044] The SMS delivery receipt data is added to the delivery receipt queue to trigger subsequent status updates and billing processing.

[0045] Preferably, the actual deduction status in the pre-deduction result data is updated based on the SMS delivery receipt data, and a double rollback or channel switching retry is performed on failed delivery tasks to generate target SMS delivery status data, including:

[0046] Based on the unique task ID in the SMS delivery receipt data, locate the corresponding pre-deduction result data, and parse the sending result status and failure reason information in the SMS delivery receipt data;

[0047] When the SMS delivery receipt data indicates that the SMS was sent successfully, the pre-deduction status in the pre-deduction result data is updated to the formal deduction status, a bill success message is generated and put into the bill success queue, and the target SMS sending status data is generated based on the task unique ID, sending success status, final channel identifier and formal deduction status.

[0048] If the SMS delivery receipt data indicates that the SMS sending failed, determine whether the preset retry conditions are met based on the failure reason information.

[0049] If the failure is due to an internal system error, the pre-deduction rollback strategy will be executed: the pre-deduction rollback interface will be called to return the pre-deducted amount in full to the account balance, the deduction status will be updated to the rollback status, and target SMS sending status data will be generated based on the task's unique ID, sending failure status, failure reason, and rollback status.

[0050] If the failure is due to an error by an external operator, the formal deduction rollback strategy will be implemented: first, the pre-deducted fee will be converted into actual consumption, then a bill rollback message will be generated and put into the bill rollback queue. The full or partial refund will be determined according to the business rules, and the target SMS sending status data will be generated based on the task's unique ID, sending failure status, failure reason, and partial / full refund status.

[0051] If the conditions for retry are met and the problem is a channel failure, then based on the original channel identifier and the current channel availability status, the channel switching strategy is executed to generate a new channel identifier. The retry task data is generated by combining the remaining retry count and rewritten into the SMS sending message queue. At this time, intermediate status data containing the retry status and the new channel identifier is generated as the target SMS sending status data.

[0052] By summarizing the above status data, the final target SMS sending status data is obtained; the final target SMS sending status data includes at least the task unique ID, target number, SMS sending result, final channel identifier, billing status, failure reason and retry count.

[0053] Preferably, the target SMS sending status data is synchronized to the business database to perform full-process management of SMS sending, including:

[0054] Based on the unique task ID, the target SMS sending status data is written into the SMS sending status table, and the billing record table and channel usage record table corresponding to the unique task ID are updated.

[0055] Start a distributed timed compensation task to periodically scan SMS records that are in the accepted state for more than a preset time or were sent 72 to 74 hours ago but have not received a delivery receipt.

[0056] For records where no delivery receipt has been received, an overdue receipt is automatically generated and sent to the receipt queue, triggering a status update and customer callback process.

[0057] After the database write is successful, status index data for business query, bill reconciliation and operation analysis is generated based on the target SMS sending status data.

[0058] By using the status index data in the business database, the entire process of SMS sending requests can be traced and managed, from access, invalid database interception, flow control, billing, delivery, receipt to the final status.

[0059] A method for sending intelligent text messages based on an invalid number database, applicable to the aforementioned intelligent text message sending system based on an invalid number database, includes:

[0060] Obtain SMS sending request data; the SMS sending request data includes SMS type, target number, SMS content, country / region identifier, application identifier, and sending time information;

[0061] Based on the target number in the SMS sending request data, query the invalid number database with time-sensitive management to generate number validity analysis results; the number validity analysis results are used to indicate whether the target number is in a valid state;

[0062] If the number validity analysis results indicate that the target number is valid, the SMS sending request is rate-limited based on the preset six-dimensional flow control matrix to obtain the flow control evaluation result.

[0063] If the flow control assessment result indicates that the task has passed, perform a pre-deduction check and balance lock operation on the sending account, and combine the SMS sending request data to obtain the pre-deduction result data and the data of the task to be sent containing the sending task parameters;

[0064] Based on the pre-deduction result data and the current operator channel load status, the optimal sending channel is dynamically selected, and the data of the task to be sent is put into the message queue. The asynchronous consumer thread parses the task and calls the operator interface to execute the SMS delivery.

[0065] Receive SMS delivery receipt data returned from the operator channel, update the actual deduction status in the pre-deduction result data according to the SMS delivery receipt data, and perform double rollback or channel switching retry for failed delivery tasks to generate target SMS delivery status data; synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

[0066] Compared with the prior art, the beneficial effects of the present invention are:

[0067] (1) This invention uses a time-sensitive invalid number database mechanism to intercept historical invalid numbers such as those that are out of service or inactive before sending, avoiding the waste of channel resources caused by sending first and then failing in the prior art. At the same time, it is combined with a six-dimensional traffic control matrix to implement differentiated traffic limiting based on SMS type, content, region and other dimensions, effectively preventing malicious traffic boosting and harassment. In addition, the pre-deduction mechanism locks the balance before sending, completely eliminating the risk of balance overdraft and bad debt caused by traditional post-billing.

[0068] (2) By adopting an asynchronous decoupling architecture based on message queues, this invention makes time-consuming operations such as SMS delivery, status receipt, and billing processing asynchronous, thereby reducing the main process response time and improving system throughput. At the same time, the multi-dimensional flow control module adopts Redis asynchronous batch counting technology to complete the frequency statistics of six dimensions in a single operation, effectively compressing the flow control overhead and realizing low-latency processing in high-concurrency scenarios.

[0069] (3) This invention solves the billing inaccuracy problem caused by traditional one-size-fits-all refunds by implementing differentiated refund strategies based on the cause of failure through pre-deduction and dual rollback mechanisms, thereby improving the reconciliation accuracy. At the same time, by using multi-channel dynamic routing to select the optimal operator channel in real time, and combining it with distributed timed compensation for automatic retry or resending of receipts, the service availability is improved from single-channel to multi-channel, realizing the closed-loop management of the entire process of SMS sending-billing-recovery. Attached Figure Description

[0070] Figure 1 This is a schematic diagram of the overall system architecture in one embodiment of the present invention;

[0071] Figure 2 This is a schematic flowchart of the overall method in one embodiment of the present invention.

[0072] In the diagram: 1. SMS access module; 2. Invalid number database management module; 3. Multi-dimensional traffic control module; 4. Pre-deduction processing module; 5. Asynchronous delivery module; 6. Status management module. Detailed Implementation

[0073] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0074] Example 1, please refer to Figure 1This invention provides a technical solution: an intelligent SMS sending system based on an invalid number database, comprising:

[0075] SMS access module 1 is used to obtain SMS sending request data; wherein, SMS sending request data includes SMS type, target number, SMS content, country / region identifier, application identifier and sending time information;

[0076] The invalid number database management module 2 is used to query the invalid number database with time-sensitive management based on the target number in the SMS sending request data, and generate number validity analysis results; wherein, the number validity analysis results are used to indicate whether the target number is in a valid state;

[0077] The multi-dimensional flow control module 3 is used to determine the flow restriction of SMS sending requests based on a preset six-dimensional flow control matrix when the number validity analysis result indicates that the target number is valid, and to obtain the flow control evaluation result.

[0078] The pre-deduction processing module 4 is used to perform pre-deduction checks and balance locking operations on the sending account when the flow control assessment result indicates that the data has passed, and to obtain pre-deduction result data and sending task data containing sending task parameters by combining the SMS sending request data.

[0079] The asynchronous delivery module 5 is used to dynamically select the optimal sending channel based on the pre-deduction result data and the current operator channel load status, and put the task data to be sent into the message queue. The asynchronous consumer thread parses the task and calls the operator interface to execute the SMS delivery.

[0080] The status management module 6 is used to receive SMS delivery receipt data returned by the operator channel, update the actual deduction status in the pre-deduction result data according to the SMS delivery receipt data, and perform double rollback or channel switching retry for failed delivery tasks to generate target SMS delivery status data; and synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

[0081] It should be noted that SMS access module 1 is the system's entry point, used to receive SMS sending request data from business parties. This data includes SMS type (such as verification code, marketing, notification), target number, SMS content, country / region identifier, application identifier, and sending time information, providing the raw data foundation for subsequent intelligent processing. Invalid number database management module 2 queries the invalid number database with time-sensitive management based on the target number in the request. This database adopts a dual-table structure with a main table storing basic information of invalid numbers and a record table storing interception history. By determining whether the target number is in the main table and has not been deleted, and calculating whether the time difference between the creation time and the current time is less than or equal to three months, the database generates a number validity analysis result. For example, if a number is entered into the database due to being out of service, and if it requests to send again within three months, it will be directly determined as invalid and intercepted, and a penalty charge will be executed to prevent malicious attempts.

[0082] When the number is valid, the multi-dimensional traffic control module 3 limits the flow based on a preset six-dimensional traffic control matrix (covering SMS type, target mobile number, SMS content characteristics, country / region identifier, application identifier, and time period). It constructs flow control key-value pairs through the Redis atomic counting mechanism and performs asynchronous batch increment operations in the cache. For example, it limits the number of times a single number can be sent to a verification code type to 50 times a day and the number of times a duplicate content can be sent to 5 times a day. If the real-time frequency exceeds the threshold, the request is blocked. After the flow control passes, the pre-deduction processing module 4 performs pre-deduction checks and balance locking operations on the sending account. For example, it sends a request to the billing service to lock the corresponding amount. If the balance is insufficient, the sending is rejected. If the balance is sufficient, it generates pre-deduction result data and task data to be sent, which include information such as the locked amount and the unique task ID. The asynchronous delivery module 5 dynamically selects the optimal channel by calling an independent channel routing service based on the pre-deduction result and the operator channel load status. For example, it selects the best channel based on the channel real-time success rate and load weight score. The task data to be sent is put into a message queue, and the asynchronous consumer thread parses the channel identifier in the task and calls the operator interface to send it.

[0083] The status management module 6 receives SMS delivery receipt data returned by the operator. Based on the sending result status and failure reason in the receipt, it updates the pre-deduction status. For example, if the sending is successful, the pre-deduction is converted into formal deduction and a billing success message is generated. If the failure is due to an internal system error, the pre-deduction is rolled back in full. If the failure is due to an operator error, it is first converted into actual consumption and then refunded according to the rules. If the retry conditions are met, the channel is switched to generate retry task data. Finally, the target SMS sending status data containing information such as the unique task ID, sending result, and deduction status is generated and synchronized to the business database.

[0084] In an optional embodiment, based on the target number in the SMS sending request data, a database of invalid numbers with time-sensitive management is queried to generate a number validity analysis result, including:

[0085] Read the invalid number main table from the invalid number database, and determine whether the target number exists in the invalid number main table and whether the corresponding record is marked as not deleted;

[0086] If the target number exists in the invalid number main table, obtain the creation time of the corresponding record and calculate the time difference between the creation time and the current time;

[0087] The time difference is compared with the preset validity period of the invalid number database; the validity period of the invalid number database is set to three months.

[0088] If the time difference is less than or equal to three months, a number validity analysis result indicating that the target number is invalid will be generated;

[0089] If the time difference is greater than three months or the target number does not match the invalid number main table, a number validity analysis result indicating that the target number is valid will be generated.

[0090] It should be noted that this embodiment implements a dynamic number validity judgment logic based on a time window, aiming to solve the false positive problem caused by the traditional blacklist's "permanent blacklist" and the resource waste caused by "unpredictable sending". Specifically, the invalid number database management module 2 first accesses the invalid number main table, which stores the core information of mobile phone numbers that have been judged as invalid in the past (such as suspended, empty numbers, complaints), including the number itself, creation timestamp, and deletion flag (logical deletion bit). The system queries whether the target number exists by precise matching and verifies whether its deletion flag is in the "not deleted" state to ensure that only currently effective invalid records are processed. If the query is successful, the system will extract the creation time of the record and calculate the time difference between it and the current system time. This step introduces the concept of "timeliness", that is, it is believed that the invalid status of the number is not permanent, but has a certain life cycle. The system compares this time difference with the preset invalid number database validity period (specifically set to three months in this embodiment).

[0091] For example, assuming the current time is October 27, 2023, if the target number "13800000000" was created on August 1, 2023, in the invalid number main table, the calculated time difference is approximately 87 days, which is less than the three-month threshold. The system determines that the number is still in an "invalid state" and generates an interception command. If the target number "13900000000" was created on June 1, 2023, the time difference is approximately 148 days, which is greater than the three-month threshold. The system then believes that the number may have been reclaimed or reactivated by the operator, and therefore generates an analysis result of "valid state," allowing it to enter the subsequent traffic control stage. If the target number is not found in the main table, or is found but has exceeded the validity period, the system defaults to generating a "valid state" result.

[0092] In an optional embodiment, after generating a number validity analysis result indicating that the target number is invalid, the method further includes:

[0093] Construct a failure receipt object, set the error code to invalid number blocking, and write the blocking record to the record table in the invalid number database; the record table stores the message identifier, mobile phone number, country code, blocking code, and blocking information for each blocking;

[0094] Add the failure receipt object to the message queue to asynchronously notify the client of the intercepted status;

[0095] The pre-deduction processing module 4 is invoked to perform a penalty deduction operation on the sending account, and the deduction amount is the standard fee corresponding to the SMS sending request.

[0096] It should be noted that this embodiment implements a dynamic blacklist filtering mechanism based on time decay. Specifically, the system maintains a main table of invalid numbers to store core blacklist data (such as mobile phone number, country code, creation timestamp, logical deletion flag), and a record table to store detailed interception logs (such as message ID, interception time, specific interception reason). When a target number is matched in the main table and the deletion mark is "not deleted", the system calculates the time difference between the current system time and the record creation time, and compares it with the preset validity period of the invalid number database (90 days / three months in this embodiment). For example, if a number is entered due to "service suspension" and requests to send again within 90 days, the system determines that it is still invalid and blocks it. If more than 90 days have passed, it is assumed that the number may have been recycled and resold by the operator, and the block is automatically lifted. After the block occurs, the system will not only construct a failure receipt containing a specific error code (such as "invalid number block") and asynchronously notify the client through a message queue, but also trigger a penalty deduction logic - that is, although no SMS is actually sent, the account balance is still deducted according to the standard tariff, so as to prevent malicious users from using the invalid number database to conduct free stress tests or probe system rules.

[0097] In an optional embodiment, based on a preset six-dimensional flow control matrix, a flow control assessment is performed on SMS sending requests to obtain flow control evaluation results, including:

[0098] Multidimensional feature parameters are extracted from SMS sending request data. These multidimensional feature parameters correspond to the dimensions of a six-dimensional traffic control matrix. The dimensions include SMS type, target mobile phone number, SMS content features, country / region identifier, application identifier, and time period.

[0099] Based on the Redis atomic counting mechanism, flow control key-value pairs are constructed corresponding to multi-dimensional feature parameters; among them, the flow control key-value pairs include daily count of CAPTCHA, daily count of marketing notification, daily count of duplicate content, daily count of country, monthly count of country, daily count of application, and monthly count of application.

[0100] Perform asynchronous batch increment operations on the send frequency of each dimension in the Redis cache; where a single batch operation includes counters for the above six dimensions.

[0101] Obtain preset traffic thresholds for each dimension; among them, verification code SMS is limited to 50 times per number per day, marketing and notification SMS is limited to 100 times per number per day, and repetitive content is limited to 5 times per number per day.

[0102] The real-time frequency obtained from the asynchronous batch increment operation is compared with the corresponding traffic threshold.

[0103] If the real-time frequency of any dimension exceeds the corresponding traffic threshold, a flow control assessment result indicating interception is generated; if the real-time frequency of all dimensions does not exceed the corresponding traffic threshold, a flow control assessment result indicating passage is generated.

[0104] It should be noted that this embodiment employs a six-dimensional matrix rate limiting algorithm based on Redis atomic counting and pipeline technology. Specifically, the system first parses the SMS sending request and extracts six core dimension feature parameters: SMS type (e.g., distinguishing between verification codes, marketing, and notifications), target mobile phone number (uniquely identifying the user), SMS content features (usually using the MD5 or Hash value of the content to identify duplicate content), country / region identifier (e.g., CN, US), application identifier (App ID or enterprise ID), and time period (distinguishing between daily and monthly dimensions). Based on these features, the system constructs corresponding flow control key-value pairs. (Pair), for example, for the "verification code" type, the key name might be designed as FC:TYPE:OTP:DAY:13800000000 (representing the verification code count for that number on that day), and the value is the current cumulative count; In the Redis cache, the system does not initiate a separate network request for each dimension, but uses a pipeline mechanism to package the incrementing operations of the six dimensions into a single network I / O batch execution. For example, a single request can execute six commands at the same time, such as "verification code daily count +1", "country daily count +1", "application daily count +1", etc., which greatly reduces network round-trip latency;

[0105] Furthermore, the system has preset fine-grained traffic thresholds: for example, verification code SMS messages are limited to 50 times per number per day due to account security and time-sensitive nature; marketing and notification SMS messages are limited to 100 times per number per day; and to prevent malicious traffic boosting or repeated sending of spam, duplicate content is limited to 5 times per day. After the count increments, the system obtains the real-time count value and compares it with the threshold, adopting a "one-vote veto system"—that is, if any dimension exceeds the limit, it will be blocked.

[0106] For example, suppose user A (number 13800000000) has sent 49 verification codes on a given day. On the 50th request, the system queries Redis and finds that the value of FC:TYPE:OTP:DAY:13800000000 is 49, increasing to 50, which does not exceed the threshold of 50, so flow control passes. If user A then sends a 51st verification code request, the value will increase to 51, exceeding the threshold, and the system will generate an "intercept" result. As another example, if marketing content is determined to be duplicate content (Hash matching), and this content has already been sent 5 times on the same day, even if the number and application dimensions do not exceed the limit, the system will still block the request because the "daily count of duplicate content" exceeds the limit. This multi-dimensional cross-verification mechanism can prevent single-number bombing, single-content spamming, and control the overall sending volume of specific countries or applications, achieving comprehensive traffic defense.

[0107] In an optional embodiment, after performing a pre-deduction check and balance lock operation on the sending account and obtaining the pre-deduction result data, the method further includes:

[0108] Determine if the account has the balance check function enabled; if not, directly generate the pre-deduction result data for successful pre-deduction.

[0109] If balance check is enabled, verify whether the SMS price is valid, obtain the application's company identifier and settlement type, and construct a balance check request object;

[0110] The billing service sends a pre-deduction request to the billing service, which checks whether the account balance is sufficient and locks the corresponding amount in advance.

[0111] If the balance is insufficient, an insufficient balance error receipt is generated and sent to the client via a message queue, and the current sending request is rejected;

[0112] If the balance is sufficient, pre-deduction result data will be generated, including the locked amount, number of transactions, service type, and application identifier.

[0113] It should be noted that this embodiment implements a pre-locking and verification mechanism for funds based on switch configuration. Specifically: First, the balance check function of the application account is checked. If it is off (such as an internal test account or a high-credit enterprise), the system skips the fund verification and directly generates virtual result data of "pre-deduction successful" to improve processing efficiency. If it is on, a strict fund verification process is entered. In the strict verification process, the system first verifies the validity of the SMS price (to prevent abnormal data such as unit price of 0 or negative number), and extracts the identification of the application's company (used to distinguish the fund pools of different entities) and the settlement type (such as prepaid, postpaid, or monthly settlement), and constructs a standardized balance check request object accordingly. Subsequently, the system calls an independent billing service through RPC or HTTP request. The billing service performs transaction operations at the database level: querying the available balance of the account and comparing it with the total amount of "unit price × number of messages".

[0114] For example, suppose an application account has a balance of 100 yuan, the price of a single SMS message is 0.1 yuan, the number of messages to be sent is 500, and the total amount to be frozen is 50 yuan.

[0115] In a scenario with sufficient balance: the billing service compares the balance and finds that 100 yuan > 50 yuan, so it marks the account balance as "frozen 50 yuan" in the database (available balance is deducted, but the total funds pool remains unchanged), and returns a successful lock signal. Based on this, the system generates pre-deduction result data containing {locked amount: 50 yuan, number of transactions: 500, business type: marketing, application ID: App001}.

[0116] Insufficient balance scenario: If the account balance is only 30 yuan, and the billing service finds that 30 yuan < 50 yuan, then the "insufficient balance" error code is returned. After the system captures the error, it constructs a failure receipt object containing the specific error code, serializes it, and delivers it to the message queue. A dedicated consumer thread then asynchronously pushes it to the client SDK or callback interface, while rejecting the current sending request to prevent unnecessary consumption of system resources.

[0117] In an optional embodiment, the optimal transmission channel is dynamically selected based on pre-payment result data and the current operator channel load status, including:

[0118] Confirm the successful prepayment status based on the prepayment result data, and invoke the independent channel routing service;

[0119] The channel routing service queries the real-time load status, health status, and historical success rate of all configured carrier channels to obtain channel availability status data;

[0120] Based on the channel availability status data, each channel is weighted and sorted according to the preset routing strategy to select the current best operator channel and obtain the optimal channel selection data.

[0121] Based on the optimal channel selection data and combined with the SMS sending request information in the pre-deducted billing result data, generate task data to be sent that includes the target number, SMS content, channel identifier, unique task ID, and maximum number of retries.

[0122] It should be noted that this embodiment introduces an independent channel routing service to achieve intelligent path planning based on real-time network conditions. Specifically, after successful pre-payment, the system does not directly specify the operator interface, but instead initiates a route selection request to the channel routing service. This routing service maintains a real-time updated channel status table and collects three core indicators of each operator channel in real time through heartbeat detection and historical data statistics: real-time load status (such as current QPS, bandwidth utilization), health status (such as interface connectivity, error rate in the last 5 minutes), and historical success rate (such as SMS delivery rate in the past 24 hours). Based on the above indicators, the system calculates the comprehensive weight score of each channel according to a preset routing strategy. This strategy usually adopts a weighted scoring model, for example: Total score = Historical success rate * Weight A + (1 - Real-time load rate) * Weight B + Health status * Weight C. The system sorts all available channels in descending order and selects the channel with the highest score as the optimal operator channel.

[0123] For example, suppose the system is configured to send domestic SMS messages via "China Mobile Channel A" and "China Unicom Channel B". Currently, due to a surge in traffic during holidays, "China Mobile Channel A" has a real-time load rate of 90% and a declining health score, while "China Unicom Channel B" has a load rate of only 30% and a historical success rate of 99%. In this case, although "China Mobile Channel A" may be the default preferred choice, the routing service will find that "China Unicom Channel B" has a higher overall score. Therefore, the system will generate optimal channel selection data indicating the use of "China Unicom Channel B". Subsequently, the system encapsulates the channel identifier (e.g., UNICOM_GD_01) with the target number, SMS content, generated unique task ID (e.g., UUID) from the original request, and the set maximum number of retries (e.g., 3, to prevent infinite loops) to generate structured task data to be sent. This dynamic routing mechanism ensures that even if a channel suddenly fails or becomes congested, the SMS message can be automatically switched to other high-quality channels for sending, thereby guaranteeing the overall success rate and timeliness of delivery.

[0124] In an optional embodiment, the task data to be sent is placed into a message queue, and an asynchronous consumer thread parses the task and calls the operator interface to execute the SMS delivery, including:

[0125] Write the data of the task to be sent to the preset SMS sending message queue;

[0126] An asynchronous consumer thread retrieves the data of the task to be sent from the SMS sending message queue, and calls the corresponding operator channel interface to execute the SMS delivery operation based on the channel identifier in the data of the task to be sent.

[0127] After completing the SMS delivery operation, the system receives the original delivery result information returned by the operator channel and parses it together with the unique task ID in the task data to be sent to generate standardized SMS delivery receipt data.

[0128] The SMS delivery receipt data is added to the delivery receipt queue to trigger subsequent status updates and billing processing.

[0129] It should be noted that this embodiment adopts a producer-consumer model and a message-driven architecture. Specifically, the system serializes the task data to be sent (including the unique task ID, channel identifier, target number, SMS content, etc.) and writes it into a preset SMS sending message queue (such as a Kafka or RocketMQ Topic). This queue acts as a buffer to smooth out peaks and troughs, enabling upstream interfaces to respond quickly. The asynchronous consumer thread (Worker process) deployed in the backend continuously listens to this queue and retrieves task data using pull or push methods. After the consumer parses the channel identifier (such as CMCC_SH_01 representing the Shanghai Mobile channel), it calls the corresponding operator's API interface via HTTP / HTTPS or SMPP / SGIP protocols to execute the actual delivery. During this process, the consumer establishes a long connection or short connection pool with the operator's gateway and sends protocol messages.

[0130] After the message is sent, the carrier gateway will return the original message sending result information, which is usually a carrier-specific status code string or JSON, such as "STATUS": "DELIVRD" or "ERR": "003"). The consumer thread captures this original receipt, combines it with the unique task ID in the task data, parses it, and encapsulates it into standardized SMS message sending receipt data. Standardization usually means that it is unified into the system's internally defined JSON format, which includes fields such as: taskId (task ID), status (status: success / failure / unknown), operatorCode (carrier return code), timestamp (receipt time), and channelId (actual channel used).

[0131] Finally, the system re-serializes the standardized receipt data and puts it into a dedicated receipt queue. This action is equivalent to sending an "event notification". The downstream status management module 6, as a consumer, subscribes to this queue. Once it receives the message, it triggers subsequent database status updates, billing status changes, or failure retry logic.

[0132] For example, suppose the task ID is TASK-20231027-001 and the channel is "China Unicom Beijing Channel"; the consumer thread retrieves the task from the sending queue and calls the China Unicom API to send it; 2 seconds later, it receives the original message returned by China Unicom: {"MsgId": "202310270001", "Status": "0"} (0 represents success); the consumer parses it into standardized JSON: {"taskId": "TASK-20231027-001", "status": "SUCCESS", "operatorCode": "0", "receiveTime": 1698384000000, "channelId": "UNICOM_BJ_01"}, and puts this JSON into the receipt queue; after the status management module 6 consumes this message, it updates the status of the task in the database to "sent successfully" and executes the formal deduction.

[0133] In an optional embodiment, the actual deduction status in the pre-deduction result data is updated based on the SMS delivery receipt data, and a double rollback or channel switching retry is performed on the failed delivery task to generate target SMS delivery status data, including:

[0134] Based on the unique task ID in the SMS delivery receipt data, locate the corresponding pre-deduction result data, and parse the sending result status and failure reason information in the SMS delivery receipt data;

[0135] When the SMS delivery receipt data indicates that the SMS was sent successfully, the pre-deduction status in the pre-deduction result data is updated to the formal deduction status, a bill success message is generated and put into the bill success queue, and the target SMS sending status data is generated based on the task unique ID, sending success status, final channel identifier and formal deduction status.

[0136] If the SMS delivery receipt data indicates that the SMS sending failed, determine whether the preset retry conditions are met based on the failure reason information.

[0137] If the failure is due to an internal system error, the pre-deduction rollback strategy will be executed: the pre-deduction rollback interface will be called to return the pre-deducted amount in full to the account balance, the deduction status will be updated to the rollback status, and target SMS sending status data will be generated based on the task's unique ID, sending failure status, failure reason, and rollback status.

[0138] If the failure is due to an error by an external operator, the formal deduction rollback strategy will be implemented: first, the pre-deducted fee will be converted into actual consumption, then a bill rollback message will be generated and put into the bill rollback queue. The full or partial refund will be determined according to the business rules, and the target SMS sending status data will be generated based on the task's unique ID, sending failure status, failure reason, and partial / full refund status.

[0139] If the conditions for retry are met and the problem is a channel failure, then based on the original channel identifier and the current channel availability status, the channel switching strategy is executed to generate a new channel identifier. The retry task data is generated by combining the remaining retry count and rewritten into the SMS sending message queue. At this time, intermediate status data containing the retry status and the new channel identifier is generated as the target SMS sending status data.

[0140] By summarizing the above status data, the final target SMS sending status data is obtained; the final target SMS sending status data includes at least the task unique ID, target number, SMS sending result, final channel identifier, billing status, failure reason and retry count.

[0141] It should be noted that this embodiment implements a fund closed-loop and fault self-healing mechanism based on a full-link state machine. Its core lies in the final disposal of funds locked in the pre-deduction stage based on the SMS delivery receipt data returned by the operator, and the execution of differentiated compensation strategies for tasks that fail to be sent. Specifically, the system first uses the unique task ID as an index to accurately locate the corresponding pre-deduction result data in the cache or database, and parses the sending result status and failure reason code in the receipt.

[0142] For different receipt results, the system executes the following three branch logics:

[0143] Successful delivery branch: If the receipt shows "Submission successful" or "Delivery successful", the system will update the pre-deduction status to the formal deduction status, which means that the frozen funds will be actually deducted; at the same time, the system generates a bill success message (including the actual deduction amount and business transaction number) and puts it into the bill success queue, triggering the final accounting of the financial system; at this time, the generated target status data is marked as "sent successfully" and the final channel identifier used is recorded;

[0144] Sending a failed branch can be categorized into three strategies:

[0145] Strategy A: Internal system error rollback. If the failure is due to a system malfunction (such as null pointer exception, database connection timeout, or thread pool rejection) and no actual carrier channel resources are consumed, the system executes the pre-deduction rollback strategy: calls the rollback interface of the pre-deduction service to fully unfreeze the previously locked amount and return it to the account balance, updates the deduction status to "rollback completed", and records the target status data as "sending failed - system error".

[0146] Strategy B: External operator error-based refund. If the failure is due to operator rejection (e.g., number blacklist, service suspension, channel congestion), although the message was not successfully sent, the system executes a formal deduction rollback strategy because channel query resources have been occupied or some link costs have been incurred. First, the pre-deduction status is changed to "formal deduction" (considered as channel costs already incurred). Then, a bill rollback message (containing a refund instruction) is generated and placed in the bill rollback queue. The financial system then executes the subsequent refund operation according to business rules (e.g., whether to refund in full, partially, or not). The target status data is marked as "Send Failure - Operator Rejection" and the corresponding refund status.

[0147] Strategy C: Channel failure retry. If the failure is due to a channel-level fault (such as a 503 error from the operator's interface or a connection timeout) and the remaining retries have not been exhausted, the system executes the channel switching retry strategy: First, it queries the channel routing service to obtain the identifier of the currently healthy new channel. Then, it repackages the original task information (target number, content) with the new channel identifier and the remaining retries into retry task data and writes it again into the SMS sending message queue for asynchronous retransmission. At this time, the generated target status data is the intermediate state "retrying" and records the new channel information, waiting for the next delivery receipt.

[0148] Finally, the system summarizes the data generated by all the branches mentioned above to generate the final target SMS sending status data. This data structure includes at least: a unique task ID (end-to-end tracking key), the target number, the SMS sending result (success / failure / retrying), the final channel identifier (the channel actually sent), the billing status (billed / rolled back / partially refunded), the reason for failure (detailed error code), and the number of retries (number of attempts).

[0149] In an optional embodiment, the target SMS sending status data is synchronized to the business database to perform full-process management of SMS sending, including:

[0150] Based on the unique task ID, the target SMS sending status data is written into the SMS sending status table, and the billing record table and channel usage record table corresponding to the unique task ID are updated.

[0151] Start a distributed timed compensation task to periodically scan SMS records that are in the received state for more than a preset time or were sent 72 to 74 hours ago but have not received a delivery receipt.

[0152] For records where no delivery receipt has been received, an overdue receipt is automatically generated and sent to the receipt queue, triggering a status update and customer callback process.

[0153] After the database write is successful, status index data for business query, bill reconciliation and operation analysis is generated based on the target SMS sending status data.

[0154] By using the status index data in the business database, the entire process of SMS sending requests can be traced and managed, from access, invalid database interception, flow control, billing, delivery, receipt to the final status.

[0155] It should be noted that this embodiment achieves closed-loop management of the SMS lifecycle through data persistence and distributed compensation mechanisms. Specifically, the system first uses the task's unique ID as the primary key to write the target SMS sending status data into the SMS sending status table of the core business database (recording the final status and timestamp). Then, through database transactions or an eventual consistency scheme, it updates the billing record table (converting pre-deducted fees into actual deducted or rolled-back amounts) and the channel usage record table (updating the channel's success / failure count and load weight) to ensure the consistency of business, financial, and operational data. This is to prevent "unfinished" tasks caused by lost operator receipts or processing timeouts. The system initiates a distributed timed compensation task, periodically performing two types of scans: first, scanning tasks that have been in the "accepted" state for more than a preset time without being processed, to determine if there is any lag; second, precisely scanning records sent 72 to 74 hours ago but still without receiving a final delivery receipt to cover the operator's longest delay window; for abnormal records detected, the system automatically constructs a timeout receipt object to simulate the unknown timeout status returned by the operator, and forcibly puts it into the delivery receipt queue, thereby triggering the callback logic of the status management module 6, which completes the status of these old tasks to "timeout failure" or "unknown", and executes the corresponding refund or alarm process;

[0156] After successful data writing, the system asynchronously builds status index data, that is, it creates a multi-dimensional index for the SMS sending status table (such as partitioning by sending time, creating secondary indexes by application ID, task status, and channel ID), and may synchronize hot data to Elasticsearch or Redis to accelerate queries. This index data supports three core scenarios of upper-layer business: business query (such as a client querying the real-time status of a certain SMS message through an API), billing reconciliation (the financial system quickly pulls the successful / failed transaction records of a certain day through the index to verify the amount), and operational analysis (using aggregated indexes to statistically analyze KPI indicators such as the success rate of each channel, the distribution of sending volume of each application, and the interception rate of invalid numbers).

[0157] For example, suppose an SMS message with task ID T-20231027-005 was sent at 10:00 AM on October 27th, but no receipt was received due to a network gateway malfunction. At 10:00 AM on October 30th (72 hours later), the distributed scheduled task scanned the record and found it was still "sending," so it automatically generated a timeout receipt {taskId: T-20231027-005, status: TIMEOUT, timestamp: 1698544800} and added it to the queue. The status management module 6 consumes this message, updates the database status to "sending timeout - refunded," and updates the billing table. Simultaneously, when operations personnel query the "mobile channel success rate on October 27th" in the background, the system quickly locates and aggregates the record using the idx_date and idx_channel indexes, calculating the accurate failure rate. Finally, the system uses the task ID... T-20231027-005 allows maintenance personnel to trace back the entire link log from access, interception judgment, flow control check, pre-deduction, channel selection to final timeout, achieving accurate fault delineation.

[0158] Example 2, please refer to Figure 2 This invention provides a technical solution: a smart SMS sending method based on an invalid number database, applicable to the aforementioned smart SMS sending system based on an invalid number database, comprising:

[0159] S1. Obtain SMS sending request data; wherein, SMS sending request data includes SMS type, target number, SMS content, country / region identifier, application identifier, and sending time information;

[0160] S2. Based on the target number in the SMS sending request data, query the invalid number database with time-sensitive management and generate a number validity analysis result; wherein, the number validity analysis result is used to indicate whether the target number is in a valid state;

[0161] S3. When the number validity analysis result indicates that the target number is valid, the flow control evaluation result is obtained by limiting the SMS sending request based on the preset six-dimensional flow control matrix.

[0162] S4. If the flow control assessment result indicates that the process is successful, perform a pre-deduction check and balance lock operation on the sending account, and combine the SMS sending request data to obtain the pre-deduction result data and the data of the task to be sent containing the sending task parameters.

[0163] S5. Based on the pre-deduction result data and the current operator channel load status, dynamically select the optimal sending channel, put the task data to be sent into the message queue, and have the asynchronous consumer thread parse the task and call the operator interface to execute the SMS delivery.

[0164] S6. Receive SMS delivery receipt data returned by the operator channel, update the actual deduction status in the pre-deduction result data according to the SMS delivery receipt data, and perform double rollback or channel switching retry for failed delivery tasks to generate target SMS delivery status data; synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

[0165] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited thereto. Various changes can be made within the scope of knowledge possessed by those skilled in the art without departing from the spirit of the present invention.

Claims

1. A smart SMS sending system based on an invalid number database, characterized in that, include: The SMS access module is used to obtain SMS sending request data; the SMS sending request data includes SMS type, target number, SMS content, country / region identifier, application identifier, and sending time information; The invalid number database management module is used to query the invalid number database with time-sensitive management based on the target number in the SMS sending request data, and generate number validity analysis results; the number validity analysis results are used to indicate whether the target number is in a valid state; The multi-dimensional flow control module is used to determine the flow restriction of SMS sending requests based on a preset six-dimensional flow control matrix when the number validity analysis results indicate that the target number is valid, and to obtain the flow control evaluation result. The pre-deduction processing module is used to perform pre-deduction checks and balance locking operations on the sending account when the flow control assessment result indicates that the data has passed, and to obtain pre-deduction result data and sending task data containing sending task parameters by combining the SMS sending request data. The asynchronous delivery module is used to dynamically select the optimal sending channel based on the pre-deduction result data and the current operator channel load status, and put the task data to be sent into the message queue. The asynchronous consumer thread parses the task and calls the operator interface to execute the SMS delivery. The status management module is used to receive SMS delivery receipt data returned by the operator channel, update the actual deduction status in the pre-deduction result data according to the SMS delivery receipt data, and perform double rollback or channel switching retry for failed delivery tasks to generate target SMS delivery status data; and synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

2. The intelligent SMS sending system based on an invalid number database according to claim 1, characterized in that, Based on the target number in the SMS sending request data, query the invalid number database with time-sensitive management, and generate number validity analysis results, including: Read the invalid number main table from the invalid number database, and determine whether the target number exists in the invalid number main table and whether the corresponding record is marked as not deleted; If the target number exists in the invalid number main table, obtain the creation time of the corresponding record and calculate the time difference between the creation time and the current time; The time difference is compared with the preset validity period of the invalid number database; the validity period of the invalid number database is set to three months. If the time difference is less than or equal to three months, a number validity analysis result indicating that the target number is invalid will be generated; If the time difference is greater than three months or the target number does not match the invalid number main table, a number validity analysis result indicating that the target number is valid will be generated.

3. The intelligent SMS sending system based on an invalid number database according to claim 2, characterized in that, After generating the number validity analysis results indicating that the target number is invalid, the following is also included: Construct a failure receipt object, set the error code to invalid number blocking, and write the blocking record to the record table in the invalid number database; the record table stores the message identifier, mobile phone number, country code, blocking code, and blocking information for each blocking; Add the failure receipt object to the message queue to asynchronously notify the client of the intercepted status; The pre-deduction processing module is invoked to perform a penalty deduction operation on the sending account, and the deduction amount is the standard fee corresponding to the SMS sending request.

4. The intelligent SMS sending system based on an invalid number database according to claim 3, characterized in that, Based on a preset six-dimensional flow control matrix, flow control assessment results are obtained by determining the flow limit for SMS sending requests, including: Multidimensional feature parameters are extracted from SMS sending request data. These multidimensional feature parameters correspond to the dimensions of a six-dimensional traffic control matrix. The dimensions include SMS type, target mobile phone number, SMS content features, country / region identifier, application identifier, and time period. Based on the Redis atomic counting mechanism, flow control key-value pairs are constructed corresponding to multi-dimensional feature parameters; among them, the flow control key-value pairs include daily count of CAPTCHA, daily count of marketing notification, daily count of duplicate content, daily count of country, monthly count of country, daily count of application, and monthly count of application. Perform asynchronous batch increment operations on the send frequency of each dimension in the Redis cache; where a single batch operation includes counters for the above six dimensions. Obtain preset traffic thresholds for each dimension; among them, verification code SMS is limited to 50 times per number per day, marketing and notification SMS is limited to 100 times per number per day, and repetitive content is limited to 5 times per number per day. The real-time frequency obtained from the asynchronous batch increment operation is compared with the corresponding traffic threshold. If the real-time frequency of any dimension exceeds the corresponding traffic threshold, a flow control assessment result indicating interception is generated; if the real-time frequency of all dimensions does not exceed the corresponding traffic threshold, a flow control assessment result indicating passage is generated.

5. The intelligent SMS sending system based on an invalid number database according to claim 4, characterized in that, After performing pre-deduction checks and balance lock operations on the sending account and obtaining the pre-deduction result data, the following also applies: Determine if the account has the balance check function enabled; if not, directly generate the pre-deduction result data for successful pre-deduction. If balance check is enabled, verify whether the SMS price is valid, obtain the application's company identifier and settlement type, and construct a balance check request object; The billing service sends a pre-deduction request to the billing service, which checks whether the account balance is sufficient and locks the corresponding amount in advance. If the balance is insufficient, an insufficient balance error receipt is generated and sent to the client via a message queue, and the current sending request is rejected; If the balance is sufficient, pre-deduction result data will be generated, including the locked amount, number of transactions, service type, and application identifier.

6. The intelligent SMS sending system based on an invalid number database according to claim 5, characterized in that, Based on pre-payment results data and the current operator channel load status, the optimal transmission channel is dynamically selected, including: Confirm the successful prepayment status based on the prepayment result data, and invoke the independent channel routing service; The channel routing service queries the real-time load status, health status, and historical success rate of all configured carrier channels to obtain channel availability status data; Based on the channel availability status data, each channel is weighted and sorted according to the preset routing strategy to select the current best operator channel and obtain the optimal channel selection data. Based on the optimal channel selection data and combined with the SMS sending request information in the pre-deducted billing result data, generate task data to be sent that includes the target number, SMS content, channel identifier, unique task ID, and maximum number of retries.

7. The intelligent SMS sending system based on an invalid number database according to claim 6, characterized in that, The task data to be sent is added to the message queue, and the asynchronous consumer thread parses the task and calls the operator's interface to execute the SMS delivery, including: Write the data of the task to be sent to the preset SMS sending message queue; An asynchronous consumer thread retrieves the data of the task to be sent from the SMS sending message queue, and calls the corresponding operator channel interface to execute the SMS delivery operation based on the channel identifier in the data of the task to be sent. After completing the SMS delivery operation, the system receives the original delivery result information returned by the operator channel and parses it together with the unique task ID in the task data to be sent to generate standardized SMS delivery receipt data. The SMS delivery receipt data is added to the delivery receipt queue to trigger subsequent status updates and billing processing.

8. The intelligent SMS sending system based on an invalid number database according to claim 7, characterized in that, Update the actual deduction status in the pre-deduction result data based on the SMS delivery receipt data, and perform double rollback or channel switching retry for failed delivery tasks to generate target SMS delivery status data, including: Based on the unique task ID in the SMS delivery receipt data, locate the corresponding pre-deduction result data, and parse the sending result status and failure reason information in the SMS delivery receipt data; When the SMS delivery receipt data indicates that the SMS was sent successfully, the pre-deduction status in the pre-deduction result data is updated to the formal deduction status, a bill success message is generated and put into the bill success queue, and the target SMS sending status data is generated based on the task unique ID, sending success status, final channel identifier and formal deduction status. If the SMS delivery receipt data indicates that the SMS sending failed, determine whether the preset retry conditions are met based on the failure reason information. If the failure is due to an internal system error, the pre-deduction rollback strategy will be executed: the pre-deduction rollback interface will be called to return the pre-deducted amount in full to the account balance, the deduction status will be updated to the rollback status, and target SMS sending status data will be generated based on the task's unique ID, sending failure status, failure reason, and rollback status. If the failure is due to an error by an external operator, the formal deduction rollback strategy will be implemented: first, the pre-deducted fee will be converted into actual consumption, then a bill rollback message will be generated and put into the bill rollback queue. The full or partial refund will be determined according to the business rules, and the target SMS sending status data will be generated based on the task's unique ID, sending failure status, failure reason, and partial / full refund status. If the conditions for retry are met and the problem is a channel failure, then based on the original channel identifier and the current channel availability status, the channel switching strategy is executed to generate a new channel identifier. The retry task data is generated by combining the remaining retry count and rewritten into the SMS sending message queue. At this time, intermediate status data containing the retry status and the new channel identifier is generated as the target SMS sending status data. By summarizing the above status data, the final target SMS sending status data is obtained; the final target SMS sending status data includes at least the task unique ID, target number, SMS sending result, final channel identifier, billing status, failure reason and retry count.

9. A smart SMS sending system based on an invalid number database according to claim 8, characterized in that, Synchronize the target SMS sending status data to the business database to perform full-process management of SMS sending, including: Based on the unique task ID, the target SMS sending status data is written into the SMS sending status table, and the billing record table and channel usage record table corresponding to the unique task ID are updated. Start a distributed timed compensation task to periodically scan SMS records that are in the accepted state for more than a preset time or were sent 72 to 74 hours ago but have not received a delivery receipt. For records where no delivery receipt has been received, an overdue receipt is automatically generated and sent to the receipt queue, triggering a status update and customer callback process. After the database write is successful, status index data for business query, bill reconciliation and operation analysis is generated based on the target SMS sending status data. By using the status index data in the business database, the entire process of SMS sending requests can be traced and managed, from access, invalid database interception, flow control, billing, delivery, receipt to the final status.

10. A method for sending intelligent text messages based on an invalid number database, applicable to the intelligent text message sending system based on an invalid number database as described in any one of claims 1-9, characterized in that, include: Obtain SMS sending request data; the SMS sending request data includes SMS type, target number, SMS content, country / region identifier, application identifier, and sending time information; Based on the target number in the SMS sending request data, query the invalid number database with time-sensitive management to generate number validity analysis results; the number validity analysis results are used to indicate whether the target number is in a valid state; If the number validity analysis results indicate that the target number is valid, the SMS sending request is rate-limited based on the preset six-dimensional flow control matrix to obtain the flow control evaluation result. If the flow control assessment result indicates that the task has passed, perform a pre-deduction check and balance lock operation on the sending account, and combine the SMS sending request data to obtain the pre-deduction result data and the data of the task to be sent containing the sending task parameters; Based on the pre-deduction result data and the current operator channel load status, the optimal sending channel is dynamically selected, and the data of the task to be sent is put into the message queue. The asynchronous consumer thread parses the task and calls the operator interface to execute the SMS delivery. Receive SMS delivery receipt data returned from the operator channel, update the actual deduction status in the pre-deduction result data according to the SMS delivery receipt data, and perform double rollback or channel switching retry for failed delivery tasks to generate target SMS delivery status data; synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

Images