A short message service system with multi-dimensional flow control and invalid number filtering

Abstract

The present application relates to the technical field of short message service, in particular to a short message service system with multi-dimensional flow control and invalid number filtering, comprising: a short message access module for obtaining short message sending request data; wherein the short message sending request data comprises short message type, target number, short message content, country / region identifier, application identifier and sending time information; an invalid analysis module for performing validity analysis on the target mobile phone number according to the short message sending request data, and generating a number validity analysis result. The present application effectively reduces the invalid sending proportion by intercepting recent invalid numbers in advance and performing punitive charges on invalid requests, directly reducing channel fees and resource waste; combined with Redis atomic counting, asynchronous batch processing and multi-layer caching mechanism, the system throughput and cache hit rate are improved, the main process response time is significantly shortened, and the overall operating cost is greatly reduced.

Description

Technical Field

[0001] This invention relates to the field of SMS service technology, specifically to an SMS service system with multi-dimensional traffic control and invalid number filtering. Background Technology

[0002] A text messaging service system is a computer software system or platform based on a mobile communication network, specifically designed for handling the sending, receiving, management, and related business logic of text messages. It is a commonly used infrastructure for enterprises, application developers, or service providers, primarily used to implement scenarios such as verification code notifications, marketing promotions, system alerts, and customer service communication.

[0003] Traditional SMS sending typically uses a direct sending mode, meaning that upon receiving an SMS request, it directly calls the operator's channel to send the message without pre-verification. It also employs only a simple blacklist mechanism, blocking specific numbers by maintaining a static blacklist. Flow control strategies are relatively simplistic, merely limiting the overall sending frequency, such as a maximum of N messages per minute. Billing methods are mostly post-send, meaning fees are deducted only after the SMS is sent, with no pre-payment mechanism. Channel routing is fixed, using only one or a few operator channels, lacking dynamic switching capabilities.

[0004] Traditional solutions suffer from the following main shortcomings: First, they result in significant resource waste, as sending SMS messages to invalid numbers wastes channel resources and costs, and requires waiting for the operator to return a failure result before confirming the number's invalidity. Second, the flow control mechanism is simplistic, unable to set differentiated restrictions for different SMS types, lacking content-based duplicate detection, making it vulnerable to malicious traffic boosting attacks, and lacking country / region-based traffic control. Furthermore, billing is inaccurate, with post-event billing potentially leading to continued sending attempts even when the balance is insufficient, and failures failing to promptly roll back costs, lacking a pre-deductible mechanism. Finally, reliability is poor, with single-channel failures easily causing service unavailability, lacking retry and channel switching mechanisms, untimely status updates, and poor data consistency. Summary of the Invention

[0005] To achieve the above objectives, the present invention provides the following technical solution: a text messaging service system with multi-dimensional flow control and invalid number filtering, 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 invalidity analysis module is used to perform validity analysis on the target mobile number based on the SMS sending request data and generate a number validity analysis result; the number validity analysis result is used to indicate whether the target mobile number is an invalid number;

[0008] The flow control assessment module is used to determine the flow control assessment result by limiting the SMS sending request based on a preset multi-dimensional flow control matrix when the number validity analysis result indicates that the target mobile number is a valid number;

[0009] The billing processing module is used to perform pre-deduction operations on the sending account when the flow control assessment result indicates that it has passed, check the account balance and pre-deduct the corresponding fees, and obtain the pre-deduction result data;

[0010] The channel selection module is used to dynamically select the optimal sending channel and generate the task data to be sent based on the pre-deduction result data and the current operator channel load status.

[0011] The SMS delivery receipt module is used to 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, and obtains the SMS delivery receipt data.

[0012] The status management module is used to update the actual deduction status in the pre-deduction result data based on the SMS delivery receipt data, and to retry the channel switching for failed tasks, generating target SMS delivery status data; and to synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

[0013] Preferably, the validity of the target mobile phone number is analyzed based on the SMS sending request data, and the number validity analysis results are generated, including:

[0014] Obtain historical information of the target mobile phone number in the invalid number database;

[0015] Determine if the target mobile number exists in the invalid number database and whether the corresponding record is within a preset validity period;

[0016] If the condition is met that the target mobile phone number exists and has not exceeded the preset validity period, the target mobile phone number will be determined as an invalid number.

[0017] Preferably, when the invalidity analysis module determines that the target mobile number is invalid, it still triggers the billing processing module to perform a punitive deduction operation on the sending account to prevent malicious abuse.

[0018] Preferably, based on a preset multi-dimensional flow control matrix, flow control evaluation results are obtained by rate limiting judgment on SMS sending requests, including:

[0019] Multidimensional feature parameters are extracted from SMS sending request data. These multidimensional feature parameters correspond to the dimensions of the multidimensional flow control matrix. The dimensions include at least SMS type, target mobile phone number, SMS content features, country / region identifier, application identifier, and sending time window.

[0020] Based on the Redis atomic counting mechanism, flow control key values ​​corresponding to multi-dimensional feature parameters are constructed, and atomic accumulation operations are performed on the sending frequency of each dimension in the Redis cache;

[0021] Obtain the preset traffic thresholds for each dimension, and compare the real-time frequency obtained from the atomic accumulation operation with the corresponding traffic thresholds;

[0022] 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.

[0023] Preferably, the billing processing module checks the account balance and pre-deducts the corresponding fees. After obtaining the pre-deduction result data, it also includes:

[0024] In the event of an internal error or failure to send the SMS message, a pre-deducted fee rollback operation will be performed to refund the pre-deducted fee to the sending account, ensuring that the fee is only deducted when the SMS message is actually successfully delivered.

[0025] Preferably, based on the pre-deduction result data and the current operator channel load status, the optimal sending channel is dynamically selected and the data for the task to be sent is generated, including:

[0026] Confirm the successful prepayment status based on the prepayment result data, query the real-time load status, health status, and historical success rate of all configured operator channels, and obtain the channel availability status data;

[0027] 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.

[0028] 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.

[0029] 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 SMS delivery, obtaining SMS delivery receipt data, including:

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

[0031] 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 based on the channel identifier to execute the SMS delivery operation;

[0032] After completing the SMS delivery operation, the system receives the original delivery result information returned by the operator channel and generates standardized SMS delivery receipt data by parsing the unique task ID.

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

[0034] 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;

[0035] If the SMS delivery receipt data indicates that the SMS was sent successfully, the pre-deduction status in the pre-deduction result data will be updated to the formal deduction status, and intermediate status data indicating successful delivery will be generated.

[0036] 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 retry conditions are met, obtain the remaining number of retry attempts and the original channel identifier from the pre-deduction result data.

[0037] Based on the original channel identifier and the current channel availability status, a channel switching strategy is executed to generate a new channel identifier, and retry task data is generated by combining the remaining retries.

[0038] Rewrite the retry task data back into the SMS sending message queue to trigger a resend process;

[0039] If the SMS is successfully sent, based on the pre-deduction result data, SMS delivery receipt data, and intermediate status data, target SMS sending status data including sending result, final channel identifier, and deduction status is generated.

[0040] If the number of retries is exhausted, trigger the failure final state handling logic for the pre-deduction result data.

[0041] Preferably, the logic for triggering the final failure handling of the pre-deduction result data includes:

[0042] The billing processing module is invoked to perform a pre-deduction rollback operation, updating the deduction status in the pre-deduction result data to a rollback status, and refunding the pre-deducted fees to the corresponding sending account, thus obtaining the fee rollback result data.

[0043] Based on SMS delivery receipt data, cost rollback result data, and the final channel identifier used, generate final status data indicating SMS delivery failure;

[0044] The final status data will be used as the target SMS sending status data for subsequent business statistics, auditing, and anomaly analysis and handling.

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

[0046] Obtain the target SMS sending status data, which includes at least the task unique ID, target number, SMS sending result, final channel identifier, and deduction status;

[0047] 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.

[0048] 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.

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

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

[0051] (1) By intercepting recent invalid numbers in advance and imposing penalty charges on invalid requests, this invention effectively reduces the proportion of invalid sending, directly reducing channel costs and resource waste; combined with Redis atomic counting, asynchronous batch processing and multi-layer caching mechanism, it improves system throughput and cache hit rate, significantly shortens the main process response time and greatly reduces overall operating costs;

[0052] (2) The present invention adopts multi-channel dynamic switching, automatic retry for failure and message queue to ensure eventual consistency, ensuring that single-channel failure does not affect the overall service, and significantly improves delivery rate and data consistency, avoiding service interruption and status inconsistency problems caused by fixed channels or passive receipts in the prior art.

[0053] (3) This invention effectively prevents malicious traffic boosting and harassing SMS messages through multi-dimensional refined flow control, and the penalty deduction mechanism further curbs abuse; full-link status management and automated processing reduce manual intervention, reduce customer complaint handling and operation and maintenance costs, and at the same time, the improved audit logs and index data improve compliance and problem location efficiency. Attached Figure Description

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

[0055] Figure 2This is a timing diagram of the core process of the overall system in one embodiment of the present invention.

[0056] In the diagram: 1. SMS access module; 2. Invalidity analysis module; 3. Flow control evaluation module; 4. Billing processing module; 5. Channel selection module; 6. Receipt delivery module; 7. Status management module. Detailed Implementation

[0057] 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.

[0058] Example 1, please refer to Figure 1 and Figure 2 This invention provides a technical solution: a text messaging service system with multi-dimensional traffic control and invalid number filtering, comprising:

[0059] 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;

[0060] Invalidity analysis module 2 is used to perform validity analysis on the target mobile number based on SMS sending request data and generate number validity analysis results; wherein, the number validity analysis results are used to indicate whether the target mobile number is an invalid number;

[0061] The flow control assessment module 3 is used to determine the flow control assessment result by limiting the SMS sending request based on a preset multi-dimensional flow control matrix when the number validity analysis result indicates that the target mobile phone number is a valid number;

[0062] Billing processing module 4 is used to perform pre-deduction operation on the sending account when the flow control assessment result indicates that it has passed, check the account balance and pre-deduct the corresponding fee, and obtain the pre-deduction result data;

[0063] Channel selection module 5 is used to dynamically select the optimal sending channel and generate task data to be sent based on the pre-deduction result data and the current operator channel load status;

[0064] The delivery receipt module 6 is used to 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 and obtain the SMS delivery receipt data.

[0065] The status management module 7 is used to update the actual deduction status in the pre-deduction result data based on the SMS delivery receipt data, and to retry the channel switching for failed delivery tasks, generating target SMS delivery status data; and to synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

[0066] It should be noted that SMS access module 1 is the system's entry gateway, typically using HTTP / HTTPS interfaces or TCP long-connection protocols to receive requests submitted by external business systems. To cope with high concurrency, the access layer uses Nginx+Lua for traffic cleaning and distributes traffic to the backend cluster through load balancing (such as Round-Robin or Weighted-Random). SMS types differentiate business priorities, such as verification code SMS (high priority), notification SMS (medium priority), and marketing SMS (low priority), which determines the subsequent flow control and channel selection strategies. Invalidity analysis module 2 is located before flow control, using caching technology to quickly identify "black hole numbers" and reduce the impact of invalid traffic on subsequent modules.

[0067] The flow control assessment module 3 utilizes the high-speed read and write capabilities of the in-memory database to achieve millisecond-level frequency verification in high-concurrency scenarios; the billing processing module 4's "pre-deduction" mechanism is similar to the pre-authorization of a bank card, freezing funds first to ensure sufficient account balance and avoid sending due to arrears; the channel selection module 5 is equivalent to intelligent scheduling in a logistics system, selecting the optimal route based on road conditions (channel load); the status management module 7 is the control center of the entire link, responsible for maintaining data consistency and recovering from anomalies.

[0068] For example, suppose an e-commerce platform sends an order confirmation SMS via API during a major promotional period; SMS access module 1 parses the request and finds the number "138xxxx" and the content "order confirmed"; invalidity analysis module 2 confirms that the number is normal; flow control assessment module 3 confirms that the user's sending limit per minute is not exceeded; billing processing module 4 freezes 0.05 yuan; channel selection module 5 finds that "mobile channel A" is congested and "mobile channel B" is free, so it selects channel B; after the delivery receipt module 6 executes the asynchronous delivery via MQ, the status management module 7 receives the success receipt, deducts the frozen 0.05 yuan, and writes it to the database for querying.

[0069] In an optional embodiment, the validity analysis of the target mobile phone number is performed based on the SMS sending request data to generate a number validity analysis result, including:

[0070] Obtain historical information of the target mobile phone number in the invalid number database;

[0071] Determine if the target mobile number exists in the invalid number database and whether the corresponding record is within a preset validity period;

[0072] If the condition is met that the target mobile phone number exists and has not exceeded the preset validity period, the target mobile phone number will be determined as an invalid number.

[0073] It should be noted that the invalid number database is a dynamically maintained Redis Cluster cluster specifically storing mobile phone numbers that recently failed to send due to reasons such as "empty number," "out of service," or "number does not exist." The system adopts a two-layer architecture of "Bloom filter + KV storage." The Bloom filter is used to quickly block numbers that absolutely do not exist, reducing the pressure on the backend cache. These records are not permanently stored but have a time limit, because out of service may be reinstated, and deactivated numbers may be reactivated by operators. The preset validity period is a time window set based on business experience, such as 3 days, 7 days, or 30 days, balancing the interception accuracy and false positive rate.

[0074] The system also includes a background task for reactivation detection. For expired invalid numbers, they are not allowed to pass directly, but a small-volume gray-scale strategy is adopted, such as sampling 1% of requests to try sending. If they are sent successfully 3 times in a row, they are removed from the invalid number database in advance. The write triggering mechanism for the invalid number database is handled by the asynchronous receipt listening service in the status management module 7. Specifically, when the system receives the final status report pushed by the operator and the return code clearly indicates "empty number (Error 9005)", "out of service (Error 9006)", "number does not exist (Error 9007)" or "blacklist blocked (Error 9008)", the write operation is triggered. For "submission failure" returned during the synchronous submission phase, it is only marked as a temporary exception and is not directly written to the invalid number database. It needs to wait for the asynchronous final receipt confirmation.

[0075] The invalid number record data structure uses Redis Hash for storage. The key is InvalidNum:Phone:138xxxx, and the value contains the following fields: phone_number (phone number), failure_reason (failure reason code), first_fail_time (first failure timestamp), last_check_time (last reactivation probe timestamp), failure_count (number of consecutive failures), channel_id (channel ID of the last attempt), and operator_id (operator identifier). The synchronization mechanism between the Bloom filter and the KV storage is as follows: before writing to the Redis Hash, the number summary is first written to the Bloom filter. To prevent accidental deletion, a "lazy loading + periodic full synchronization" strategy is adopted, that is, every day at midnight, a background task compares the Bloom filter with the full Redis keys to fix possible inconsistencies.

[0076] For example, the system is set to have a preset validity period of 7 days. If the number "13900001111" is recorded in the database on October 1, 2023, because it is an "invalid number", and a request to send data to that number is made again on October 21, 2023, the system will find that the number is in the database and only 20 days have passed since it was recorded (not exceeding 30 days), and will directly determine it as an invalid number and block it. If a request is made again on November 4, 2023, the system will allow the request to be sent because the validity period has expired, in order to check whether the number has been restored to validity.

[0077] In an optional embodiment, when the invalidity analysis module 2 determines that the target mobile phone number is invalid, it still triggers the billing processing module 4 to perform a punitive deduction operation on the sending account to prevent malicious abuse.

[0078] It's important to note that punitive charging is an economic risk control measure. In traditional systems, blocking invalid requests is usually free, allowing malicious users like SMS bombers and malicious number detection platforms to exploit the system's free feedback to cleanse number data. By implementing punitive charging, even if the SMS isn't actually sent to the operator, the system will deduct a fee from the sending account, increasing the cost of malicious activity. The punitive charging amount is dynamically configured, adjusted based on the customer's credit rating and historical behavior. For example, high-credit customers pay 0.01 yuan per message, while low-credit customers pay 0.05 yuan per message (equivalent to the normal sending fee). The charging record will be separately marked as "FINE" and trigger a risk control alarm. For example, the normal cost of sending one SMS is 0.05 yuan. If a customer uploads a list of 10,000 numbers, of which 9,000 are known invalid numbers, the system will identify and block these invalid numbers, preventing them from being sent to the operator, but still charging a punitive fee of 0.01 yuan per message. This protects channel resources and warns customers to clean their data or stop malicious attacks.

[0079] In an optional embodiment, based on a preset multi-dimensional flow control matrix, a flow control evaluation result is obtained by performing flow limiting determination on SMS sending requests, including:

[0080] Multidimensional feature parameters are extracted from SMS sending request data. These multidimensional feature parameters correspond to the dimensions of the multidimensional flow control matrix. The dimensions include at least SMS type, target mobile phone number, SMS content features, country / region identifier, application identifier, and sending time window.

[0081] Based on the Redis atomic counting mechanism, flow control key values ​​corresponding to multi-dimensional feature parameters are constructed, and atomic accumulation operations are performed on the sending frequency of each dimension in the Redis cache;

[0082] Obtain the preset traffic thresholds for each dimension, and compare the real-time frequency obtained from the atomic accumulation operation with the corresponding traffic thresholds;

[0083] 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.

[0084] It should be noted that the multidimensional flow control matrix is ​​a complex set of rules, similar to the ACL policy table of a firewall; multidimensional feature parameter extraction "flattens" the requests into key indicators that can be used for matching; to solve the single-point performance bottleneck of Redis, a two-level counting mode of "local cache + Redis" is adopted: first, coarse-grained rate limiting is performed locally in the JVM using Guava RateLimiter, and then atomic counting is performed through Redis Lua scripts to ensure data consistency under high concurrency;

[0085] Redis's atomic counting mechanism utilizes the Redis INCR or INCRBY commands, combined with the EXPIRE command to set a sliding window (e.g., 1 minute), and uses Lua scripts to ensure the atomicity of "GET + INCR + EXPIRE". Flow control keys are typically composed of a dimension prefix and a specific value, with an expiration time (TTL) corresponding to the sending time window. For hot keys (e.g., the same mobile number in a flash sale), the system uses a sharding counting strategy (e.g., adding a random suffix 1-100 to the key), and finally sums the results. The "SMS content features" dimension in the multi-dimensional flow control matrix uses a three-layer extraction strategy of "signature + template ID + SimHash fingerprint".

[0086] 1. Template matching layer: If the request carries the official template ID, then the TemplateID is used directly as the feature key;

[0087] 2. Hash Mapping Layer: If it is a non-template SMS, extract the SMS signature and the first 500 characters of the text body to calculate the MD5 value;

[0088] 3. Semantic similarity layer: The SimHash algorithm is introduced to calculate a 64-bit fingerprint, and a Hamming distance threshold is set (HammingDistance <= 3).

[0089] The specific pseudocode logic is as follows: content_feature = (template_id != null) ?template_id : MD5(signature + substring(body, 0, 500)); simhash_key = SimHash(body); During flow control checks, the frequency of both content_feature and simhash_key needs to be verified simultaneously.

[0090] For example, for a rule that "limits the same mobile number to send only one verification code within one minute", when a request arrives, the system constructs a key with RateLimit:Phone:138xxxx:Type:Verify and an expiration time of 60 seconds; Redis performs an INCR operation to return the current count value; if the return value is 1, which is less than or equal to the threshold of 1, it passes; if the return value is 2, which exceeds the threshold, it is blocked; at the same time, the system may also have a rule that "limits the same IP to send a maximum of 100 verification codes within one hour", and all dimensions of checks must pass for the flow control to pass.

[0091] In an optional embodiment, the billing processing module 4 checks the account balance and pre-deducts the corresponding fees. After obtaining the pre-deduction result data, it further includes:

[0092] In the event of an internal error or failure to send the SMS message, a pre-deducted fee rollback operation will be performed to refund the pre-deducted fee to the sending account, ensuring that the fee is only deducted when the SMS message is actually successfully delivered.

[0093] It should be noted that pre-deduction operations at the database level typically involve initiating a local transaction, deducting the "available balance" from the account table, and simultaneously incrementing the "frozen amount" field, or generating a deduction record with a "PENDING" status and recording it in the undo_log for rollback. Pre-deduction rollback is the reverse of this process, occurring when it is known that SMS sending has failed (e.g., channel failure, operator failure receipt) or the task has timed out. To ensure distributed transaction consistency, "TCC" or "local message table + timed task" is used. The "Service" solution: If the pre-deduction is successful but the task delivery to MQ fails, the scheduled task scans the transaction records in the PENDING state and executes a rollback. This mechanism follows the "eventual consistency" principle to ensure the safety of user funds. For example, if the account balance is 100 yuan, a request is sent to generate a pre-deduction of 0.05 yuan. At this time, the balance shows 99.95 yuan, and 0.05 yuan is frozen. If, during the channel selection phase, the system finds that all channels are unavailable, the task is declared to have failed. At this time, a rollback is triggered, the frozen 0.05 yuan is released back to the balance, the account is restored to 100 yuan, and a "reverse" transaction record is recorded.

[0094] In an optional embodiment, based on pre-deduction result data and the current operator channel load status, the optimal transmission channel is dynamically selected and data for tasks to be transmitted is generated, including:

[0095] Confirm the successful prepayment status based on the prepayment result data, query the real-time load status, health status, and historical success rate of all configured operator channels, and obtain the channel availability status data;

[0096] 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.

[0097] 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.

[0098] It should be noted that the carrier channel is the bridge connecting the system to the telecommunications network, and the quality of different channels varies greatly at different times; real-time load status refers to the number of messages currently queued on the channel (obtained by monitoring the thread pool queue length or the number of unacknowledged messages on the channel); health status refers to whether the channel is under circuit breaker or maintenance (detected through heartbeat; if three consecutive heartbeat timeouts occur, it is marked as DOWN); historical success rate is the delivery ratio based on a sliding window statistical analysis of a recent period (e.g., 5 minutes); the core of the routing algorithm lies in integrating multiple indicators into a comprehensive score, using a weighted scoring formula: ,in The remaining parameters are defined as follows:

[0099] To normalize the load and reflect the channel congestion level, a piecewise linear function is used to normalize the absolute queue length. Mapped to 0-1 fractions (let) For the maximum tolerance length, if but ,like but intermediate state (Calculation), to avoid drastic score fluctuations caused by slight increases in load; To normalize the success rate and reflect channel stability, the successful transmission rate within the recent 5-minute sliding window is divided by 100 and mapped to the 0-1 range (e.g., 99% corresponds to 0.99), ensuring that high-quality channels are prioritized. As a penalty for delay, and as a negative deduction indicator, let the current average response delay be... The system reference delay is (e.g., 200ms), adjustment coefficient is (e.g., 0.5), according to the formula Calculate (if) (Then it will be 0), the higher the delay, the more points will be deducted;

[0100] The dynamic weight adjustment strategy is as follows: Verification code SMS configuration (Success rate) weight 0.6 (Load) 0.4 to ensure reliability, marketing SMS configuration (Load) Weight 0.7 (Success rate) 0.3 to utilize idle resources and reduce costs; at the same time, a circuit breaker strategy is introduced, if the channel error rate exceeds 30%, it will be forced offline for 1 minute; for example: channel A has 1000 queues ( ), 99% success rate ( ), 0 queues in lane B ( ), success rate 98% ),according to , Calculate the score for channel A. Channel B score Therefore, the system selects channel B and marks channel_id="CMPP_B", generating a globally unique task_id for end-to-end tracing.

[0101] 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 SMS delivery, obtaining SMS delivery receipt data, including:

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

[0103] 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 based on the channel identifier to execute the SMS delivery operation;

[0104] After completing the SMS delivery operation, the system receives the original delivery result information returned by the operator channel and generates standardized SMS delivery receipt data by parsing the unique task ID.

[0105] It's important to note that message queues (MQ) such as RocketMQ or Kafka play a role in "peak shaving" and "decoupling" here. They are configured as persistent queues and transactional messaging mechanisms are enabled. In high-concurrency scenarios, directly calling the operator's HTTP interface can cause I / O blocking. Through MQ buffering, consumer threads can pull tasks at a uniform rate according to the channel's processing capacity. To prevent message loss, an ACK mechanism is configured: an ACK confirmation is only sent when the consumer successfully processes the business logic, i.e., receives a receipt from the operator or the message is successfully inserted into the database. If a consumer crashes, the MQ will redeliver the message to other consumer group nodes. Asynchronous consumer threads are typically deployed on multiple nodes to form consumer groups, achieving load balancing.

[0106] To address the issue of duplicate message consumption, the consumer side implements idempotency using a Redis distributed lock (SETNX task_id) or a unique index in the database. The original delivery result information is a response packet (such as XML or JSON) synchronously returned by the operator's interface, which usually only indicates "successful submission" and not "delivered to the mobile phone." For example, the web server instantly writes 1000 mass-send tasks to the MQ in just a few milliseconds. Fifty consumer threads are started in the background to continuously pull messages from the MQ. Thread 1 receives the task, identifies it as an HTTP channel, and initiates a POST request. The operator's server responds with {result:0, desc:"Submit Success",msgid: 123456}. Thread 1 encapsulates this into a standard internal format {taskId: "SN001", status: "SUBMITTED", vendorMsgId: "123456"} for subsequent modules to process.

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

[0108] 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;

[0109] If the SMS delivery receipt data indicates that the SMS was sent successfully, the pre-deduction status in the pre-deduction result data will be updated to the formal deduction status, and intermediate status data indicating successful delivery will be generated.

[0110] 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 retry conditions are met, obtain the remaining number of retry attempts and the original channel identifier from the pre-deduction result data.

[0111] Based on the original channel identifier and the current channel availability status, a channel switching strategy is executed to generate a new channel identifier, and retry task data is generated by combining the remaining retries.

[0112] Rewrite the retry task data back into the SMS sending message queue to trigger a resend process;

[0113] If the SMS is successfully sent, based on the pre-deduction result data, SMS delivery receipt data, and intermediate status data, target SMS sending status data including sending result, final channel identifier, and deduction status is generated.

[0114] If the number of retries is exhausted, trigger the failure final state handling logic for the pre-deduction result data.

[0115] It should be noted that the receipts processed here include two types: one is the synchronous response submitted to the operator, i.e., the submission receipt; the other is the status report subsequently pushed asynchronously by the operator, i.e., the delivery receipt. The system establishes an "asynchronous receipt listening service" to specifically receive MO / MT status reports from the operator and notify the status management module 7 through the internal bus. Retryability is key to intelligent scheduling. The system maintains an "error code-retry strategy mapping table": the error codes returned by the operator are divided into three categories: the first category: retryable temporary errors, such as network timeout 9001, system busy 9003, triggering exponential backoff retries; the second category: non-retryable permanent errors, such as invalid number 9005, blacklist 9012, directly marked as failed; the third category: business errors requiring special handling, such as insufficient balance 8001, content too long 8002, directly rolled back without retrying; the mapping table can be dynamically distributed through the configuration center; retries adopt an "exponential backoff" strategy, that is, the retry interval doubles each time (1s, 2s, ...). (4s); For example, a task is sent through channel A and receives an error code 9001: Gateway Timeout from the operator; the system determines that this is a network problem and meets the retry conditions; there are currently 2 retries remaining; the system looks up the routing table to find the backup channel B; the channel_id in the task data is modified to B, the retry count is decremented by 1, and the task is resubmitted to MQ; if the task is successfully sent through channel B next time (receiving the DELIVRD status), the pre-deduction record in the database is updated to "actual deduction", and channel B is recorded as the final channel used.

[0116] In an optional embodiment, triggering the failure final state processing logic for the pre-deduction result data includes:

[0117] The billing processing module 4 is invoked to perform a pre-deduction rollback operation, update the deduction status in the pre-deduction result data to the rollback status, and refund the pre-deducted fees to the corresponding sending account, thus obtaining the fee rollback result data.

[0118] Based on SMS delivery receipt data, cost rollback result data, and the final channel identifier used, generate final status data indicating SMS delivery failure;

[0119] The final status data will be used as the target SMS sending status data for subsequent business statistics, auditing, and anomaly analysis and handling.

[0120] It's important to note that the final failure handling logic marks the end of the task's lifecycle. When all retry opportunities are exhausted, or a non-retryable error is encountered, the transaction must be terminated. This includes closing the cash flow loop (refund) and the data flow loop (recording the final failure status). The rollback operation is implemented by calling the billing service's " / refund" interface. After verifying the task status as FAILED, this interface performs a database UPDATE operation to release the frozen amount. For example, if a task continuously attempts through channel A (timeout), channel B (congestion), and channel C (connection refused), exhausting the retry count, the system executes the final failure logic: calls the billing interface to refund the pre-frozen 0.05 yuan; updates the task status to FAILED_MAX_RETRY (failed after reaching the maximum number of retry attempts); simultaneously, adds the number to the "temporary observation database," limiting the frequency of requests sent to that number for the next 5 minutes; and logs are recorded for maintenance personnel to analyze whether a large-scale failure has occurred across all channels.

[0121] 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:

[0122] Obtain the target SMS sending status data, which includes at least the task unique ID, target number, SMS sending result, final channel identifier, and deduction status;

[0123] 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.

[0124] 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.

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

[0126] It's important to note that the business database typically uses a relational database (such as MySQL) for persistent storage, employing a sharding strategy (based on time or task ID hashing) to support massive data writes. Meanwhile, the status index data is synchronized to Elasticsearch in real-time to support efficient retrieval of massive logs. The status index includes an inverted index structure, supporting queries by multiple fields such as phone number, time period, and status code. End-to-end traceability management means that the timestamps, processing results, and inputs / outputs of each step are linked together. The system uses distributed tracing (such as SkyWalking), generating a TraceID at the request entry point, which runs through all module logs.

[0127] For example, a customer complains that they "didn't receive the verification code sent at 10:00 AM." Customer service personnel enter the phone number in the management backend to query the unique ID of the task. The backend quickly locates the unique ID of the task using an Elasticsearch index. A query using this ID reveals: 10:00:01 access, 10:00:02 flow control passed, 10:00:03 submitted to channel A, 10:00:05 channel A returned a successful delivery, but at 10:00:10 a status report from the carrier showed "user's phone is off." Customer service then informs the user that the failure to receive the code was due to the phone being off, not a platform malfunction. Simultaneously, the finance department can use this data to generate accurate monthly statements. The system provides a statement generation service, summarizing successful deduction records daily and reconciling them with the carrier's successful reports to resolve inconsistencies.

[0128] 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 text messaging service system with multi-dimensional flow control and invalid number filtering, 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 invalidity analysis module is used to perform validity analysis on the target mobile number based on the SMS sending request data and generate a number validity analysis result; the number validity analysis result is used to indicate whether the target mobile number is an invalid number; The flow control assessment module is used to determine the flow control assessment result by limiting the SMS sending request based on a preset multi-dimensional flow control matrix when the number validity analysis result indicates that the target mobile number is a valid number; The billing processing module is used to perform pre-deduction operations on the sending account when the flow control assessment result indicates that the account has passed, check the account balance and pre-deduct the corresponding fees, and obtain the pre-deduction result data. The channel selection module is used to dynamically select the optimal sending channel and generate the task data to be sent based on the pre-deduction result data and the current operator channel load status. The SMS delivery receipt module is used to 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, and obtains the SMS delivery receipt data. The status management module is used to update the actual deduction status in the pre-deduction result data based on the SMS delivery receipt data, and to retry the channel switching for failed tasks, generating target SMS delivery status data; and to synchronize the target SMS delivery status data to the business database to perform full-process management of SMS delivery.

2. The SMS service system with multi-dimensional flow control and invalid number filtering according to claim 1, characterized in that, Based on the SMS sending request data, the target mobile phone number is analyzed for validity, and the number validity analysis results are generated, including: Obtain historical information of the target mobile phone number in the invalid number database; Determine if the target mobile number exists in the invalid number database and whether the corresponding record is within a preset validity period; If the target mobile number exists and has not exceeded the preset validity period, it will be determined as an invalid number.

3. A text messaging service system with multi-dimensional flow control and invalid number filtering according to claim 2, characterized in that, Even when the invalid analysis module determines that the target mobile number is invalid, it still triggers the billing processing module to perform a punitive deduction operation on the sending account to prevent malicious abuse.

4. A text message service system with multi-dimensional flow control and invalid number filtering according to claim 3, characterized in that, Based on a preset multi-dimensional flow control matrix, flow control evaluation results are obtained by rate limiting judgment on SMS sending requests, including: Multidimensional feature parameters are extracted from SMS sending request data. These multidimensional feature parameters correspond to the dimensions of the multidimensional flow control matrix. The dimensions include at least SMS type, target mobile phone number, SMS content features, country / region identifier, application identifier, and sending time window. Based on the Redis atomic counting mechanism, flow control key values ​​corresponding to multi-dimensional feature parameters are constructed, and atomic accumulation operations are performed on the sending frequency of each dimension in the Redis cache; Obtain the preset traffic thresholds for each dimension, and compare the real-time frequency obtained from the atomic accumulation operation with the corresponding traffic thresholds; 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. A text messaging service system with multi-dimensional traffic control and invalid number filtering according to claim 4, characterized in that, The billing processing module checks the account balance and deducts the corresponding fees in advance. After obtaining the pre-deduction result data, it also includes: In the event of an internal error or failure to send the SMS message, a pre-deducted fee rollback operation will be performed to refund the pre-deducted fee to the sending account, ensuring that the fee is only deducted when the SMS message is actually successfully delivered.

6. A text messaging service system with multi-dimensional flow control and invalid number filtering according to claim 5, characterized in that, Based on the pre-deduction results data and the current operator channel load status, the optimal sending channel is dynamically selected and the data for the tasks to be sent is generated, including: Confirm the successful prepayment status based on the prepayment result data, query the real-time load status, health status, and historical success rate of all configured operator channels, and obtain the 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. A text messaging service system with multi-dimensional flow control and invalid number filtering according to claim 6, characterized in that, The task data to be sent is added to the message queue. The asynchronous consumer thread parses the task and calls the operator's interface to execute the SMS delivery, obtaining SMS delivery receipt data, 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 based on the channel identifier to execute the SMS delivery operation; After completing the SMS delivery operation, the system receives the original delivery result information returned by the operator channel and generates standardized SMS delivery receipt data by parsing the unique task ID.

8. A text messaging service system with multi-dimensional flow control and invalid number filtering 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 retry the channel switching for failed delivery tasks, generating 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; If the SMS delivery receipt data indicates that the SMS was sent successfully, the pre-deduction status in the pre-deduction result data will be updated to the formal deduction status, and intermediate status data indicating successful delivery will be generated. 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 retry conditions are met, obtain the remaining number of retry attempts and the original channel identifier from the pre-deduction result data. Based on the original channel identifier and the current channel availability status, a channel switching strategy is executed to generate a new channel identifier, and retry task data is generated by combining the remaining retries. Rewrite the retry task data back into the SMS sending message queue to trigger a resend process; If the SMS is successfully sent, based on the pre-deduction result data, SMS delivery receipt data, and intermediate status data, target SMS sending status data including sending result, final channel identifier, and deduction status is generated. If the number of retries is exhausted, trigger the failure final state handling logic for the pre-deduction result data.

9. A text messaging service system with multi-dimensional flow control and invalid number filtering according to claim 8, characterized in that, Trigger the final state handling logic for the pre-deduction result data failure, including: The billing processing module is invoked to perform a pre-deduction rollback operation, updating the deduction status in the pre-deduction result data to a rollback status, and refunding the pre-deducted fees to the corresponding sending account, thus obtaining the fee rollback result data. Based on SMS delivery receipt data, cost rollback result data, and the final channel identifier used, generate final status data indicating SMS delivery failure; The final status data will be used as the target SMS sending status data for subsequent business statistics, auditing, and anomaly analysis and handling.

10. A text messaging service system with multi-dimensional flow control and invalid number filtering according to claim 9, characterized in that, Synchronize the target SMS sending status data to the business database to perform full-process management of SMS sending, including: Obtain the target SMS sending status data, which includes at least the task unique ID, target number, SMS sending result, final channel identifier, and deduction status; 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. 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, from access, flow control, billing, delivery, receipt to final status, can be traced and managed.

Images