Functional short message sending platform

Abstract

The invention discloses a functional short message sending platform, which relates to the technical field of computer application, and comprises a service request receiving module used for receiving a short message sending request which is sent by a service party and comprises a target mobile phone number and a short message template ID and generating a unique request ID; the filtering module is used for executing unsubscribing filtering and overclocking filtering on the target mobile phone number; and the service provider selection module is used for loading associated available service providers based on the short message template ID, and filtering degraded service providers and service providers which do not reach the target mobile phone number for a long time. According to the functional short message sending platform provided by the invention, the efficiency and the reliability of short message sending are remarkably improved by integrating a multi-link technology cooperation mechanism, an intelligent filtering system can effectively avoid sending information to unsubscribing and overclocking users, the user experience is protected, invalid sending is reduced, the continuity and the stability of short message service are ensured, and the user experience is improved. And an efficient, reliable and economical short message sending solution is provided.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, specifically to a functional SMS sending platform. Background Technology

[0002] In sectors like express delivery and e-commerce, functional SMS messages such as login verification codes and pickup codes are crucial links for information exchange between businesses and users. Their delivery efficiency and stability directly impact business process progress and user experience. Sending these SMS messages requires multi-stage technological collaboration, encompassing request filtering, service provider selection, delivery status tracking, and cost strategy adaptation, to achieve efficient SMS delivery while reasonably controlling operational costs for businesses.

[0003] However, existing functional SMS sending technologies have many limitations in practical applications. On the one hand, SMS delivery rates fluctuate significantly due to the real-time status of service providers, and the delivery data provided by service providers is difficult to accurately reflect the actual delivery situation due to downstream transmission and other factors. On the other hand, enterprise SMS sending accounts are prone to sending failures due to insufficient balance or exceeding the daily sending limit, and there is a lack of effective anomaly handling mechanisms. In addition, enterprises lack dynamic strategies for controlling service provider costs, making it difficult to flexibly adjust based on actual usage scenarios and delivery effects, and it is difficult to balance delivery reliability and sending costs. Furthermore, the lack of end-to-end data tracking and analysis also makes it difficult to support technology optimization with data. To address these issues, we propose a functional SMS sending platform. Summary of the Invention

[0004] To address the aforementioned technical issues, a functional SMS sending platform is provided. This technical solution resolves the problems of: high reach rates fluctuating significantly due to the real-time status of service providers; service provider reach data failing to reflect the actual situation due to downstream transmission issues; enterprise accounts frequently failing due to insufficient balance or exceeding sending limits, with a lack of effective anomaly handling; lack of dynamic cost control strategies, making it difficult to balance reach and cost; and the absence of end-to-end data tracking, resulting in a lack of support for technical optimization.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A functional SMS sending platform, comprising: The business request receiving module is used to receive SMS sending requests sent by the business party, which include the target mobile phone number and SMS template ID, and generate a unique request ID; The filtering module is used to perform unsubscribe filtering and over-frequency filtering on the target mobile number; The service provider selection module is used to load the associated available service providers based on the SMS template ID, filter downgraded service providers and service providers that have not been contacted for a long time for the target mobile number, and then determine the final service provider by combining cost strategy and weight strategy. The sending and receiving module is used to push the assembled sending parameters to the final service provider and to receive and process the sending receipts returned by the service provider. The business confirmation module is used to receive user operation information from the business side to verify the effectiveness of the outreach. The data tracking module is used to perform data tracking and reporting on all process nodes and generate data reports. The data tracking module is also associated with a monthly cost strategy update unit.

[0006] Preferably, when the filtering module performs unsubscribe filtering, it relies on the unsubscribe pool and Guava local cache. The unsubscribe pool is used to persistently store the unsubscribe information obtained from the service provider's unsubscribe callback interface. The unsubscribe information includes the unsubscribe mobile number, unsubscribe time and associated signature. Guava's local cache is synchronized with the unsubscribe pool in real time. The specific process of unsubscribing is as follows: Guava's local cache is queried to determine whether the target mobile number is in the unsubscribe pool. If it is not found, the unsubscribe pool is queried for fallback verification. If it is confirmed that the target mobile number is unsubscribed, the sending request of the mobile number is intercepted, the filtering reason is recorded as the user has unsubscribed, and the data tracking module is triggered to report the event.

[0007] Preferably, when the filtering module performs overclocking filtering, it relies on a frequency control pool built by Redis. The frequency control pool is used to count the number of times the target mobile number is sent under each signature in real time. The frequency control pool is associated with preset frequency control rules, which include the maximum number of messages that a single mobile number can send within a set time window under a single signature. The specific process of overclocking filtering is as follows: based on the signature ID and target mobile number in the request, query the number of transmissions in the current time window in the frequency control pool. If the number of transmissions is greater than or equal to the maximum number of transmissions, the transmission request of the mobile number is blocked, and the reason for filtering is recorded as exceeding the time window transmission limit, triggering the data tracking module's data entry reporting. If the limit is not reached, the number of transmissions in the frequency control pool is updated.

[0008] Preferably, when loading available service providers, the service provider selection module is associated with a MySQL database. The MySQL database stores the association between SMS templates and service providers. This association includes multiple available service providers corresponding to each SMS template and the service provider's support status for the template's business scenario. The specific process for loading available service providers is as follows: Query the MySQL database based on the SMS template ID to obtain all available service providers associated with the template and exclude those that have been permanently taken offline, forming a list of available service providers; if the query result is empty, that is, there are no associated available service providers, send an exception notification to the business party to inform them that there are no available service providers for the template, terminate the current sending process, and record the exception log.

[0009] Preferably, when filtering downgraded service providers, the service provider selection module is associated with a real-time computing component built on Flink. The real-time computing component is used to monitor the sending receipt data of the service providers under the stranded name and calculate the service provider's reach rate according to a set time window. The reach rate is the ratio of the number of successful reaches to the total number of sends. The system calculates a preset reach rate threshold in real time. When a service provider's reach rate falls below this threshold, the service provider is marked as degraded in real time and the information is synchronized to the platform, triggering an operation and maintenance alarm. When filtering downgraded service providers, service providers marked as downgraded are removed from the list of available service providers. If the list is empty after filtering, the default backup service provider is enabled. If there is no backup service provider, a notification is sent to the business party and the process is terminated.

[0010] Preferably, when filtering service providers that have not been contacted for a long time for a target mobile number, the service provider selection module is associated with a long-term inaccessible pool. The long-term inaccessible pool is used to store combinations of mobile numbers and service providers. The combination satisfies the requirement that the number of consecutive times the same mobile number has not been contacted by the same service provider reaches a set value. The data in the pool includes the first time of inaccessibility and the cumulative number of inaccessibility. Data that has not been contacted for more than a preset time period is cleaned up according to a set period. For each target mobile number, query the long-term unreachable pool, obtain the list of long-term unreachable service providers corresponding to that mobile number, and remove the service providers from the current service provider list. If no service provider is available for a target mobile number after filtering, then the mobile number is marked as having no valid service provider and recorded separately. The sending process for that mobile number is skipped so as not to affect other mobile numbers.

[0011] Preferably, when the service provider selection module determines the final service provider by combining cost strategy and weight strategy, the cost strategy is generated based on the monthly package usage data of the main account; The monthly package usage data includes: number of used services, number of remaining services, package unit price, and minimum spending requirement met. The cost strategy is used to filter out a subset of service providers that meet the cost requirements from the service provider list. The weighting strategy configures weight values ​​based on the service provider's historical reach rate, stability, and number of failures. The weight values ​​are used to sort the subset of service providers that meet the cost requirements, with service providers with higher weight values ​​having higher priority. The final service provider is determined by the one with the highest weight in the ranking. If the weights are the same, the service providers are ranked a second time according to their historical average response time, and the service provider with the faster response time is selected.

[0012] Preferably, when the sending receipt module pushes the sending parameters to the final service provider, it first assembles the sending parameters according to the API requirements of the final service provider. The sending parameters include the target mobile phone number, SMS content with variables filled according to the template, signature, platform request ID and callback address, and performs format validation on the parameters. If the validation fails, the next priority service provider is selected again. When receiving and processing the delivery receipt, the service provider pushes the receipt through the callback address. The receipt includes: request ID, mobile phone number, sending status and failure reason. The original sending request is associated with the request ID. If the receipt indicates that the sending was successful, the business confirmation module is triggered. If the sending failed, the failure reason is recorded. For retryable failure types, a preset number of retries are performed with an increasing retry interval. If a retry fails, the service provider with the next higher priority is switched.

[0013] Preferably, the confirmation information received by the business confirmation module from the business party includes the mobile phone number, the verification success time, and the associated request ID. The verification success is based on the user's operation behavior on the functional SMS, that is, the user enters the pickup code or verification code and passes the verification through the business party's system. The business confirmation module has a preset timeout period. If no confirmation message is received after this time, the SMS message is marked as suspicious and the business party is notified to investigate. If a successful confirmation is received, the entire process is marked as complete. If no confirmation is received or the confirmation fails, the outreach is marked as failed. The relevant results are synchronized to the data tracking module for service provider outreach rate calculation.

[0014] Preferably, the data tracking module's point reporting covers all nodes of the entire process, including the request reception of the business request receiving module, the unsubscription filtering results and frequency control filtering results of the filtering module, the selection process of the service provider selection module, the parameter push status and receipt reception information of the sending and receipt module, and the business party confirmation results of the business confirmation module. The reported information includes the request ID, mobile phone number, signature ID, service provider ID, processing result, time, and processing time. The data from the event tracking points is stored in the log system for problem localization, and daily reports are generated based on signature and service provider dimensions, including total number of messages sent, number of successful deliveries, number of filtered messages, number of failed messages, and cost amount. The monthly cost strategy update unit is used to collect monthly usage data for each entity account every month, and adjust the monthly cost strategy based on reach rate, cost and package usage. The updated strategy will take effect the following month.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: The functional SMS sending platform proposed in this invention significantly improves the efficiency and reliability of SMS sending by integrating a multi-stage technical collaboration mechanism. Its built-in intelligent filtering system effectively avoids sending messages to unsubscribed or over-subscribed users, protecting user experience while reducing invalid sending. The service provider selection mechanism combines real-time reach rate monitoring, historical performance evaluation, and cost optimization strategies to ensure that the optimal service provider is selected for each sending, thereby improving reach success rate and controlling operating costs. The full-process data tracking and report generation functions provide operators with detailed operational insights, facilitating timely adjustments to strategies and service optimization. The platform also has the ability to handle anomalies and dynamically adjust costs, flexibly responding to various sending anomalies and ensuring the continuity and stability of SMS services, providing enterprises with an efficient, reliable, and economical SMS sending solution. Attached Figure Description

[0016] Figure 1 This is a platform framework diagram of the present invention; Figure 2 This is a business process diagram of the present invention. Detailed Implementation

[0017] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0018] Reference Figure 1 and Figure 2 As shown, a functional SMS sending platform includes: The business request receiving module receives SMS sending requests from business parties, including the target mobile phone number and SMS template ID, and generates a unique request ID. The sending requests received by the business request receiving module are in JSON format, containing fields such as an array of target mobile phone numbers, SMS template ID, signature ID, business party identifier, and variable parameters. Upon receiving a request, a verification mechanism is first executed, including verifying the integrity of the request fields to ensure the target mobile phone number format conforms to the specifications and that the SMS template ID and signature ID are not empty; verifying the legitimacy of the business party's identity by signing the request using a preset API key to prevent unauthorized access. The unique request ID is generated using the Snowflake algorithm, combined with a timestamp, platform machine identifier, business party identifier, and sequence number, ensuring global uniqueness and including time-related information for easy subsequent tracking and investigation.

[0019] The filtering module performs unsubscribe and over-frequency filtering on target phone numbers. When performing unsubscribe filtering, the module relies on an unsubscribe pool and a Guava local cache. The unsubscribe pool persistently stores unsubscribe information obtained from service provider unsubscribe callback interfaces. This information includes the unsubscribing phone number, unsubscribe time, and associated signature. Unsubscribe information is obtained by listening to the unsubscribe callback interfaces of various service providers. When a user replies with unsubscribe keywords or unsubscribes through the service provider's platform, the service provider pushes the unsubscribe information to the platform in real time. Upon receiving this information, the platform immediately writes it to the unsubscribe pool and synchronizes it to the Guava local cache. The unsubscribe pool uses a MySQL database for persistent storage, with a composite index created by phone number and associated signature to improve query efficiency. The Guava local cache has a 10-minute expiration time and is incrementally updated every 30 seconds by a scheduled task, fetching new unsubscribe information from the unsubscribe pool to ensure data consistency between the cache and the unsubscribe pool. The specific process of unsubscribing is as follows: query the Guava local cache to determine whether the target mobile number is in the unsubscribe pool. If it is not found, query the unsubscribe pool for fallback verification. If it is confirmed that the target mobile number is in an unsubscribed state, intercept the sending request of the mobile number, record the filtering reason as the user has unsubscribed, trigger the data tracking module's event tracking report, and at the same time feed back the filtering result to the business side through an asynchronous callback.

[0020] When performing over-frequency filtering, the filtering module relies on a frequency control pool built with Redis. This pool is used to count the number of messages sent to the target phone number under each signature in real time. The pool is associated with preset frequency control rules, which include the maximum number of messages that a single phone number can send within a set time window under a single signature. These rules are set based on the business scenario type; for example, verification code SMS messages are set to a maximum of 5 messages sent within 5 minutes, and notification SMS messages are set to a maximum of 10 messages sent within 1 hour. These rules can be dynamically adjusted through the platform configuration interface. The Redis frequency control pool uses a hash structure to store data, with the key being "signature ID_target phone number" and the value containing the number of messages sent within the current time window and the window's start timestamp. Time window management is achieved by setting the expiration time of the Redis key; for example, the key expiration time for a 5-minute window is set to 300 seconds to ensure automatic window scrolling. The specific process of overclocking filtering is as follows: Generate a Redis key based on the signature ID and target mobile number in the request, query the number of transmissions in the current time window in the frequency control pool, if the number of transmissions is greater than or equal to the maximum number of transmissions, then intercept the transmission request of the mobile number, record the reason for filtering as exceeding the time window transmission limit, and trigger the data tracking module's instrumentation report; if the limit is not reached, then atomically increment the number of transmissions using the Redis INCR command to complete the count update.

[0021] The service provider selection module loads available service providers associated with the SMS template ID. It filters out downgraded service providers and those that haven't been contacted for a long time for the target mobile number, then determines the final service provider based on a cost and weighting strategy. When loading available service providers, the module is linked to a MySQL database. This database stores the association between SMS templates and service providers, including multiple available service providers for each template and the service provider's support status for that template's business scenario. The MySQL database has a `template_service` table containing fields such as template ID, service provider ID, support status (enabled or disabled), whether permanently offline, and priority weight. The "permanently offline" field indicates that the service provider can no longer provide services due to expired qualifications, termination of cooperation, or other reasons. The specific process for loading available service providers is as follows: Query the `template_service` table based on the SMS template ID, filter out service providers whose support status is enabled and whose permanent offline status is not specified, and form a list of available service providers; if the query result is empty, that is, there are no associated available service providers, then send an exception notification through a preset business notification interface such as HTTP POST. The notification content includes the request ID, template ID, and the explanation "no available service provider for the template", and terminates the current sending process. At the same time, the exception information is written to the system exception log, which includes a timestamp, request details, and processing result.

[0022] The service provider selection module, when filtering and downgrading service providers, is associated with a real-time computing component built on Flink. This real-time computing component monitors the sending and receiving data from each service provider, calculating the reach rate of each service provider within a set time window. The reach rate is the ratio of successful deliveries to the total number of sends. Flink real-time computing monitors by consuming receiving data pushed by the sending and receiving modules in Kafka. This data includes the service provider ID, whether the sending result was successful or failed, and a timestamp. The time window is set to 10 minutes, and within each window, the total number of sends and successful deliveries for each service provider are counted, and the reach rate is calculated in real time. The real-time computing component has preset reach rate thresholds, which are set according to the service provider type and business scenario. For example, the threshold is set to 95% for CAPTCHA service providers and 90% for notification service providers. These thresholds can be adjusted through the platform configuration center. When a service provider's reach rate falls below the threshold, the real-time calculation unit marks the service provider as degraded and synchronizes this information to the platform via ZooKeeper. Simultaneously, an operations and maintenance alarm is triggered, containing the service provider ID, current reach rate, threshold, and time window. This alarm is pushed to operations and maintenance personnel via email, DingTalk groups, etc. When filtering degraded service providers, those marked as degraded are removed from the list of available service providers. If the list is empty after filtering, a default backup service provider is activated. If no backup service provider is available, a notification containing the request ID and "No available service provider" is sent to the business unit, and the process is terminated.

[0023] The service provider selection module, when filtering service providers that have not been contacted for a target mobile number for an extended period, uses a long-term inaccessible pool. This pool stores combinations of mobile numbers and service providers that meet the condition that the same mobile number has not been contacted by the same service provider for a set number of consecutive times. The pool contains data including the first inaccessible time and the cumulative number of inaccessible records, and cleans up data that has not been updated for a preset period of time at a set interval. The long-term inaccessible pool uses a Redis hash structure for storage, with the key being "mobile number," the field being "service provider ID," and the value being a JSON string containing the first inaccessible timestamp and the cumulative number of inaccessible records. When a mobile number has not been contacted by a service provider for 5 consecutive times (configurable), the combination is written to the long-term inaccessible pool; if the mobile number subsequently sends an SMS successfully through that service provider, the combination is removed from the pool. The cleanup mechanism is implemented through a scheduled task, which scans the pool every morning and deletes entries that have not been updated for more than 30 days, freeing up storage space. For each target phone number, query the long-term unreached pool, obtain the list of long-term unreached service providers corresponding to that phone number, and remove the service providers from the current service provider list. If no available service provider is found for a target phone number after filtering, mark that phone number as having no valid service provider and record it separately in the invalid_phone table in MySQL. Skip the sending process for that phone number to avoid affecting other phone numbers.

[0024] When determining the final service provider in the service provider selection module, the cost strategy is generated based on the monthly package usage data of the main account. Monthly package usage data includes the number of used transactions, the number of remaining transactions, the package price, and whether the minimum spending requirement has been met. The cost strategy is generated as follows: Prioritize service providers with sufficient remaining transactions to avoid excessive charges due to package exhaustion; compare the package prices of service providers, favoring those with lower prices while meeting reach requirements; if a service provider's minimum spending requirement is not met, prioritize using that service provider to achieve the minimum spending requirement and reduce cost waste; and finally, select a subset of service providers that meet the cost requirements from the service provider list based on these factors. The weight strategy assigns weights to service providers based on their historical reach rate, stability, and number of failures. The historical reach rate over the past 30 days accounts for 50%, stability is calculated using the service availability rate over the past 30 days (30%), and the number of failures over the past 30 days (20%). These weights are used to rank the subset of service providers that meet the cost requirements, with higher weights indicating higher priority. The final service provider is determined by the one with the highest weight in the ranking. If the weights are the same, the average response time of each service provider over the past 7 days is used for a second ranking, and the service provider with the faster response time is selected.

[0025] The sending and receipt module is used to push the assembled sending parameters to the final service provider and receive and process the sending receipts returned by the service provider. When pushing sending parameters to the final service provider, the sending receipt module first assembles the sending parameters according to the final service provider's API requirements. The sending parameters include the target mobile number, SMS content with variables filled according to the template, signature, platform request ID, callback address, timestamp, and authentication information required by the service provider, such as API key and AppID. After parameter assembly, format validation is performed. Validation rules include: the target mobile number must conform to international or domestic number format standards; the SMS content length must not exceed the maximum number of characters specified by the service provider; variables must be completely filled without missing or incorrect placeholders; the timestamp must be within a valid range, such as within 5 minutes; and the signature must match the template. If validation fails, the next-priority service provider is selected from the service provider list to reassemble the parameters and validate them again, until success or the service provider list is exhausted.

[0026] When receiving and processing delivery receipts, the platform receives receipts pushed by service providers via a callback address. This callback address is an HTTP interface deployed on the platform, which supports the POST method and uses HTTPS to ensure secure data transmission. The interface path includes a unique identifier to distinguish different business scenarios. The receipt data pushed by the service provider is in JSON format, containing information such as request ID, mobile phone number, success or failure status, failure reason (e.g., invalid number, outage, sensitive content), and receipt time. Upon receiving the receipt, the platform first verifies the validity of the request ID, then parses the receipt data and associates it with the original delivery request using the request ID. If the receipt indicates successful delivery, the business confirmation module is triggered, awaiting feedback from the business party regarding user operation information. If the delivery fails, the reason for failure is recorded. For retryable failure types such as network timeout or temporary service provider failure, a preset number of retries are performed, with retry intervals increasing in increments of 1 second, 3 seconds, and 5 seconds, up to a maximum of 3 retries. If a retry fails, the platform switches to the next higher-weight service provider from the service provider list and repeats the delivery process until successful or all service providers have completed their attempts.

[0027] The business confirmation module receives user operation information from the business party to verify the reach effect. This module receives confirmation information from the business party via a pre-defined HTTP interface. This interface supports proactive push from the business party or periodic retrieval by the platform. Confirmation information includes the mobile phone number, verification success time, associated request ID, and user operation type, such as entering a pickup code or verification code. Successful verification is based on the user's action on the functional SMS message; that is, the user enters a pickup code or verification code and passes the verification through the business party's system. Upon successful verification, the business party pushes a confirmation success message to the platform in real time. The business confirmation module has a preset timeout period, which is set according to the business scenario. For example, the timeout period for verification code SMS messages is 10 minutes, and the timeout period for pickup code SMS messages is 24 hours. The timeout period can be adjusted through platform configuration. If no confirmation is received within this time, the SMS delivery is marked as questionable, and the business side is notified through the interface to investigate. The investigation includes whether the user received the SMS and whether the operation timed out. If a successful confirmation is received, the entire process is marked as complete. If no confirmation is received or the confirmation fails, the delivery is marked as failed. The relevant results are synchronized to the data tracking module for the service provider to calculate the delivery rate.

[0028] The data tracking module is used to perform event tracking and reporting across all nodes in the entire process and generate data reports. It is also associated with a monthly cost strategy update unit. The data tracking module's event tracking and reporting cover all nodes in the entire process, including request reception from the business request receiving module, unsubscription and frequency control filtering results from the filtering module, the service provider selection process from the service provider selection module, parameter push status and receipt information from the sending and receipt module, and business confirmation results from the business confirmation module. The reported content uniformly includes core fields such as request ID, mobile number, signature ID, service provider ID, processing result, time, and time consumption, ensuring full traceability. Event tracking data is asynchronously written to Kafka and then synchronized to the Elasticsearch log system by Logstash for real-time retrieval and problem localization. Simultaneously, Spark Streaming periodically consumes the event tracking data from Kafka, statistically analyzing total sent volume, successful reach, filtering volume, failure volume, and cost amount by signature and service provider. A daily report for the previous day is generated every morning at midnight and displayed through the platform's visual interface, supporting filtering and export by time, signature, and service provider. The monthly cost strategy update unit is used to compile monthly usage data for each entity account. Data sources include full-month event tracking data stored in the data tracking module and package information from the business system. Statistics include each service provider's actual reach rate, average cost, number of used packages, remaining packages, and minimum spending achievement status. Strategy adjustments are based on: prioritizing service providers with reach rates higher than the industry average; selecting service providers with lower costs when reach rates are similar; and adjusting the allocation ratio for the following month based on the remaining packages to avoid waste due to excessive remaining packages. The updated strategy takes effect at 00:00 on the 1st of the following month.

[0029] The platform ensures high availability, scalability, and error recovery capabilities through multi-dimensional design. For high availability, all modules are deployed in a cluster, distributing requests through load balancing to avoid single points of failure. At the data storage level, MySQL uses a master-slave replication architecture, Redis uses a cluster mode, and Kafka is configured with multiple replicas to ensure no data loss. Key processes are equipped with timeout retry mechanisms; for example, if a service provider does not respond when sending an SMS, it automatically switches to a backup service provider. For scalability, modules are decoupled through the Kafka message queue. When adding new business scenarios or service providers, only the association between the template and the service provider and the corresponding parameter rules need to be configured, without modifying the core code. Frequency control rules, reach rate thresholds, and other configurations are managed through a distributed configuration center, supporting dynamic adjustments without requiring service restarts. For error recovery, all failed tasks, such as sending failures and confirmation timeouts, are recorded in a dead-letter queue, supporting manual retry. The system performs regular data backups, including scheduled snapshots of MySQL and index backups of Elasticsearch, enabling rapid data recovery in case of failure. Performance optimization measures include: using Guava local caching to reduce the number of database queries to the unsubscribe pool; using Pipeline to batch execute Redis frequency control pool operations to reduce network overhead; dynamically adjusting the Flink computation window size based on the data volume to balance real-time performance and resource consumption; and using asynchronous batch writing for logs to reduce the performance impact on the main process.

[0030] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A functional SMS sending platform, characterized in that, include: The business request receiving module is used to receive SMS sending requests sent by the business party, which include the target mobile phone number and SMS template ID, and generate a unique request ID; The filtering module is used to perform unsubscribe filtering and over-frequency filtering on the target mobile number; The service provider selection module is used to load the associated available service providers based on the SMS template ID, filter downgraded service providers and service providers that have not been contacted for a long time for the target mobile number, and then determine the final service provider by combining cost strategy and weight strategy. The sending and receiving module is used to push the assembled sending parameters to the final service provider and to receive and process the sending receipts returned by the service provider. The business confirmation module is used to receive user operation information from the business side to verify the effectiveness of the outreach. The data tracking module is used to perform data tracking and reporting on all process nodes and generate data reports. The data tracking module is also associated with a monthly cost strategy update unit.

2. The functional SMS sending platform according to claim 1, characterized in that, When performing unsubscribe filtering, the filtering module relies on the unsubscribe pool and Guava local cache. The unsubscribe pool is used to persistently store the unsubscribe information obtained from the service provider's unsubscribe callback interface. The unsubscribe information includes the unsubscribe phone number, unsubscribe time, and associated signature. Guava's local cache is synchronized with the unsubscribe pool in real time. The specific process of unsubscribing is as follows: Guava's local cache is queried to determine whether the target mobile number is in the unsubscribe pool. If it is not found, the unsubscribe pool is queried for fallback verification. If it is confirmed that the target mobile number is unsubscribed, the sending request of the mobile number is intercepted, the filtering reason is recorded as the user has unsubscribed, and the data tracking module is triggered to report the event.

3. The functional SMS sending platform according to claim 1, characterized in that, When performing overclocking filtering, the filtering module relies on a frequency control pool built by Redis. The frequency control pool is used to count the number of times the target mobile number is sent under each signature in real time. The frequency control pool is associated with preset frequency control rules, which include the maximum number of messages that a single mobile number can send within a set time window under a single signature. The specific process of overclocking filtering is as follows: based on the signature ID and target mobile number in the request, query the number of transmissions in the current time window in the frequency control pool. If the number of transmissions is greater than or equal to the maximum number of transmissions, then the transmission request of the mobile number is blocked, the filtering reason is recorded as exceeding the time window transmission limit, and the data tracking module's data point reporting is triggered. If the upper limit is not reached, update the transmission count in the frequency control pool.

4. A functional SMS sending platform according to claim 1, characterized in that, When loading available service providers, the service provider selection module is associated with a MySQL database. The MySQL database stores the association between SMS templates and service providers. This association includes multiple available service providers corresponding to each SMS template and the service provider's support status for the template's business scenario. The specific process of loading available service providers is as follows: query the MySQL database based on the SMS template ID, obtain all available service providers associated with the template and exclude service providers that have been permanently taken offline, and form a list of available service providers; If the query result is empty, meaning there are no associated available service providers, an exception notification is sent to the business party, informing them that there are no available service providers for the template, and the current sending process is terminated. At the same time, an exception log is recorded.

5. A functional SMS sending platform according to claim 1, characterized in that, When filtering downgraded service providers, the service provider selection module is associated with a real-time computing component built on Flink. This real-time computing component is used to monitor the sending receipt data of the service providers under the suspended name and calculate the service provider's reach rate according to a set time window. The reach rate is the ratio of the number of successful reaches to the total number of sends. The system calculates a preset reach rate threshold in real time. When a service provider's reach rate falls below this threshold, the service provider is marked as degraded in real time and the information is synchronized to the platform, triggering an operation and maintenance alarm. When filtering downgraded service providers, service providers marked as downgraded are removed from the list of available service providers. If the list is empty after filtering, the default backup service provider is enabled. If there is no backup service provider, a notification is sent to the business party and the process is terminated.

6. A functional SMS sending platform according to claim 1, characterized in that, When filtering service providers that have not been contacted for a long time for a target mobile number, the service provider selection module is associated with a long-term inaccessible pool. The long-term inaccessible pool is used to store combinations of mobile numbers and service providers. The combination meets the requirement that the number of consecutive times the same mobile number has not been contacted by the same service provider reaches a set value. The data in the pool includes the first time of inaccessibility and the cumulative number of inaccessibility. Data that has not been contacted for more than a preset time period is cleaned up according to a set period. For each target mobile number, query the long-term unreachable pool, obtain the list of long-term unreachable service providers corresponding to that mobile number, and remove the service providers from the current service provider list. If no service provider is available for a target mobile number after filtering, then the mobile number is marked as having no valid service provider and recorded separately. The sending process for that mobile number is skipped so as not to affect other mobile numbers.

7. A functional SMS sending platform according to claim 1, characterized in that, When the service provider selection module determines the final service provider by combining cost strategy and weight strategy, the cost strategy is generated based on the monthly package usage data of the main account. The monthly package usage data includes: number of used services, number of remaining services, package unit price, and minimum spending requirement met. The cost strategy is used to filter out a subset of service providers that meet the cost requirements from the service provider list. The weighting strategy configures weight values ​​based on the service provider's historical reach rate, stability, and number of failures. The weight values ​​are used to sort the subset of service providers that meet the cost requirements, with service providers with higher weight values ​​having higher priority. The final service provider is determined by the one with the highest weight in the ranking. If the weights are the same, the service providers are ranked a second time according to their historical average response time, and the service provider with the faster response time is selected.

8. A functional SMS sending platform according to claim 1, characterized in that, When the sending receipt module pushes the sending parameters to the final service provider, it assembles the sending parameters according to the API requirements of the final service provider. The sending parameters include the target mobile phone number, SMS content with variables filled according to the template, signature, platform request ID and callback address, and performs format validation on the parameters. If the validation fails, the next priority service provider is selected again. When receiving and processing the delivery receipt, the service provider pushes the receipt through the callback address. The receipt includes: request ID, mobile phone number, sending status and failure reason. The original sending request is associated with the request ID. If the receipt indicates that the sending was successful, the business confirmation module is triggered. If the sending failed, the failure reason is recorded. For retryable failure types, a preset number of retries are performed with an increasing retry interval. If a retry fails, the service provider with the next higher priority is switched.

9. A functional SMS sending platform according to claim 1, characterized in that, The confirmation information received by the business confirmation module from the business party includes the mobile phone number, the verification success time, and the associated request ID. The verification success is based on the user's operation behavior on the functional SMS, that is, the user enters the pickup code or verification code and passes the verification through the business party's system. The business confirmation module has a preset timeout period. If no confirmation message is received after this time, the SMS message is marked as suspicious and the business party is notified to investigate. If a successful confirmation is received, the entire process is marked as complete. If no confirmation is received or the confirmation fails, the outreach is marked as failed. The relevant results are synchronized to the data tracking module for service provider outreach rate calculation.

10. A functional SMS sending platform according to claim 1, characterized in that, The data tracking module's data point reporting covers all nodes of the entire process, including the request reception of the business request receiving module, the unsubscription filtering results and frequency control filtering results of the filtering module, the selection process of the service provider selection module, the parameter push status and receipt information of the sending and receipt module, and the business party confirmation results of the business confirmation module. The reported information includes the request ID, mobile phone number, signature ID, service provider ID, processing result, time, and processing time. The data from the event tracking points is stored in the log system for problem localization, and daily reports are generated based on signature and service provider dimensions, including total number of messages sent, number of successful deliveries, number of filtered messages, number of failed messages, and cost amount. The monthly cost strategy update unit is used to collect monthly usage data for each entity account every month, and adjust the monthly cost strategy based on reach rate, cost and package usage. The updated strategy will take effect the following month.

Images