Asynchronous matching and intelligent callback method based on multi-channel status reply of short message gateway

Abstract

The application relates to an asynchronous matching and intelligent callback method based on a short message gateway multi-channel state reply, and belongs to the technical fields of communication and computer software. The method comprises the following steps: generating a platform message number for each short message and establishing a mapping relationship with a channel message number; asynchronously receiving a state reply to generate a unified reply object; taking the channel message number as a first matching key to query the mapping relationship, and selecting the optimal one according to a time deviation when multiple ones are hit; not hitting the mapping relationship, and setting as a to-be-matched one and dynamically calculating a waiting time length; listening to mapping updates in the waiting period, and completing the matching when the matching is successful; not matching when the period is expired, and querying again according to a mobile phone number combined with a channel identifier; after the matching is successful, calling a protocol adapter according to an access type to asynchronously push a result, performing ladder type retry when the pushing fails, and pausing the automatic pushing of the account and prolonging the waiting time length of subsequent replies when the continuous failure reaches a threshold. The application improves the multi-channel reply matching accuracy and the system throughput capacity.

Description

Technical Field

[0001] This invention belongs to the fields of communication technology and computer software technology, specifically relating to an asynchronous matching and intelligent callback method based on multi-channel status receipts of SMS gateways. Background Technology

[0002] With the rapid development of mobile internet services, SMS remains a widely used basic communication method for scenarios such as verification codes, notifications, and marketing pushes. As the core hub connecting the service provider and the operator's network, the SMS gateway needs to support various access methods, including HTTP API, CMPP long connections, background batch import, and scheduled tasks. Different access methods differ significantly in protocol models, connection states, submission frequencies, and receipt return mechanisms, but ultimately all must complete the operator's submission through a unified SMS sending link and receive status receipts from various channels to achieve a closed-loop business process.

[0003] In the actual operation of multi-channel SMS gateways, the processing of status receipts faces numerous technical challenges. On one hand, status receipts from different operator channels or third-party channels exhibit channel differences in communication protocols, data formats, and return timing: some channels use synchronous submission responses to immediately return preliminary statuses, while others use asynchronous status reports to delay the return of final results. Furthermore, the receipt latency of the same channel fluctuates under different load conditions. On the other hand, the message numbers assigned by the channel side and the message numbers generated internally by the gateway belong to different numbering systems. Submission responses and status reports often originate from different points in time and different protocol interfaces. Without an effective mapping and association mechanism, it is highly susceptible to receipt mismatches, omissions, or duplicate callbacks.

[0004] In existing technologies, SMS gateways typically employ a single-key matching strategy after a fixed waiting period, using the channel message number as the unique matching key to query local records. This approach has significant limitations: when channel message numbers are reused or receipts arrive out of order, single-key matching may match multiple records or fail to match any, and the system lacks an effective fault tolerance and disambiguation mechanism; the fixed waiting period cannot adapt to the different receipt delay characteristics of various channels, with too short a duration leading to a higher matching failure rate, and too long a duration causing increased receipt processing delays and inefficient use of system resources; furthermore, receipt matching, status storage, and business callbacks are usually executed sequentially, and if any link is blocked, it can easily affect the overall throughput of the sending chain.

[0005] In the business callback phase, existing solutions mostly employ simple failure retry strategies, lacking mechanisms for circuit breaking and degradation based on account dimensions. When a callback address for a certain business is unreachable or responds abnormally, the system's continuous retries not only waste resources but may also affect the delivery of receipts to other normal business entities due to excessive callback thread usage. Furthermore, the lack of effective resource isolation and asynchronous decoupling between receipt processing and the main sending link means that peak receipt surges can easily overwhelm the sending side's computing resources.

[0006] Therefore, there is an urgent need for a status receipt processing method suitable for multi-channel SMS gateways, which can form a complete technical solution in terms of heterogeneous receipt aggregation, mapping relationship construction, hierarchical fault-tolerant matching, dynamic waiting adaptation and failure circuit breaking degradation, so as to improve the receipt matching accuracy, reduce the risk of mismatch and omission, and ensure the stable operation of the receipt processing and sending main link. Summary of the Invention

[0007] To address the aforementioned problems in the existing technology, this invention provides an asynchronous matching and intelligent callback method based on multi-channel status receipts from an SMS gateway. The objective of this invention can be achieved through the following technical solutions: An asynchronous matching and intelligent callback method based on multi-channel status receipts of SMS gateways includes: Generate a platform message number for each SMS message and establish a message mapping relationship between the platform message number and the channel message number; Asynchronously receive status receipts from different channels, parse and extract the channel message number, mobile phone number and channel identifier from the status receipts, and generate a receipt object in a unified format; The message mapping relationship is queried using the channel message number in the receipt object as the first matching key. If multiple records are matched, the optimal record is selected based on the deviation between the submission timestamp and the receipt timestamp. If no match is found or the record cannot be uniquely determined, the receipt object is set to a pending matching state, and the waiting time is dynamically calculated. During the waiting time, the update event of the message mapping relationship is continuously monitored. If the match is successful after the update, the process is completed immediately. If no match is found after the waiting period, the mobile phone number combined with the channel identifier is used as the second matching key to query again. The waiting time is determined comprehensively based on the total number of receipts to be matched, the historical out-of-order probability of the channel, and the current write rate of the message mapping relationship. If the query using the second matching key still fails to find a match, it is marked as abnormal and the process is transferred to the offline verification process. After a successful match, the protocol adapter is invoked according to the access type to convert the matching result into the corresponding protocol format and push it to the business side; if the push fails, a tiered retry rule is executed, and if the consecutive failures reach the threshold, the automatic push for the business account is suspended, and subsequent receipts are set to the pending matching status and their waiting time is extended.

[0008] Specifically, the message mapping relationship is stored in a high-speed storage medium, and an expiration period is set for each mapping record; the mapping relationship is created when a submission response is received from the channel, marked as matched after a successful acknowledgment match, and automatically expires and enters the expired unmatched processing flow if no match is found after the expiration period.

[0009] Specifically, the message mapping relationship also associates the storage of SMS content hash value and submission timestamp; when multiple records are matched using the channel message number as the first matching key, the optimal record is selected based on the deviation between the submission timestamp and the receipt timestamp, and a second verification is performed using the SMS content hash value to avoid mismatches caused by the reuse of channel message numbers for different messages.

[0010] Specifically, the dynamic calculation method for the waiting time is as follows: obtain the total number of receipts in the pending matching state under the current channel, the historical out-of-order probability of receipts in the preset time window, and the write rate of the message mapping relationship at the current moment; the waiting time is positively correlated with the total number of receipts to be matched and the historical out-of-order probability, and negatively correlated with the write rate.

[0011] Specifically, during the waiting period, continuously monitor the update events of the message mapping relationship, including: registering a listener for each receipt object in the pending matching state; when the message mapping relationship is added or updated due to any SMS receiving a channel submission response, perform a trial match between the updated mapping record and the current pending matching receipt object; if the trial match is successful, immediately trigger a matching completion event and cancel the corresponding waiting timer.

[0012] Specifically, when querying again using the mobile phone number combined with the channel identifier as the second matching key, the deviation between the submission timestamp and the receipt timestamp is limited to not exceeding a preset time window; if multiple matching records are found within the time window, the one with the smallest absolute value of the deviation between the submission timestamp and the receipt timestamp is selected as the matching result.

[0013] Specifically, the process of marking an error and transferring it to an offline verification process includes: storing the error receipt in the error receipt database, aggregating it by account and channel, and performing batch comparison with the reconciliation file provided by the channel side to identify channel-level missed reports or delayed reports; if the reconciliation finds that there are batch missed reports on the channel side, the historical out-of-order probability of the channel is corrected to a higher value, and a forced secondary matching of all pending receipts for the channel is triggered.

[0014] Specifically, the tiered retry rule is as follows: multiple retry levels are set, each level corresponds to a different retry interval, and the retry interval increases with the level; after the first push fails, it enters the first level, and after each subsequent retry failure, it enters the next level; after all levels are exceeded, retry continues at the maximum interval until the preset total number of retries is reached.

[0015] Specifically, suspending automatic push notifications for a business account when consecutive failures reach a threshold includes: counting the number of consecutive push failures for the business account within a sliding time window; marking the account as paused when a preset threshold is reached, and stopping the push of new matching results to it; during the pause, subsequent receipts for the account are set to pending matching, and their waiting time is extended based on a normal calculation value, with the extension amount related to the cumulative number of failures for the account; and resuming automatic push notifications when the pause duration reaches a preset recovery threshold or a manual release instruction is received.

[0016] Specifically, the protocol adapter has pre-set protocol conversion rules for multiple access types and supports dynamic registration of new access type protocols through configuration; the protocol conversion rules include protocol format mapping, field encoding conversion, and signature generation rules.

[0017] Specifically, the method also includes collecting fault diagnosis data for the business account. The fault diagnosis data includes: historical push success rate, failure time distribution, channel response delay trend, and fault mode marking based on the above data. The fault mode marking includes time-based faults, channel-level faults, or business logic faults, and is accompanied by corresponding troubleshooting priority sorting rules.

[0018] Specifically, this also includes end-to-end adaptive optimization: collecting the receipt matching success rate, average matching time, backlog trend of pending matching status, and account-level push failure rate of each channel; when the matching success rate is lower than the preset standard or the backlog of pending matching status continues to increase, the waiting time corresponding to the channel is increased by a preset step size to calculate the benchmark value until the matching success rate recovers or reaches the upper limit of the benchmark value; when the matching success rate is higher than the preset high standard and the backlog of pending matching status continues to decrease, the benchmark value is decreased by a preset step size.

[0019] The beneficial effects of this invention are as follows: To improve the accuracy of receipt matching and reduce the risk of mismatches and omissions, this invention employs a hierarchical matching strategy combining a first matching key and a second matching key. First, a precise query is performed using the channel message number as the first matching key. When multiple records are matched, the optimal record is selected based on the deviation between the submission timestamp and the receipt timestamp, and a secondary verification is performed using the SMS content hash value. This effectively solves the mismatch problem in scenarios where channel message numbers are reused. When the first matching key query fails to find a match or cannot uniquely determine the match, the receipt object is placed in a pending matching state. After the waiting period, a second query is performed using the mobile phone number combined with the channel identifier as the second matching key. This significantly improves the recall rate of receipt matching and reduces the risk of omissions.

[0020] The combination of dynamic adaptation and real-time monitoring enhances matching efficiency and adaptability: This invention comprehensively determines the waiting time based on three dimensions: the total number of pending matching receipts in the current channel, the historical out-of-order probability of the channel, and the message mapping relationship write rate. The waiting time is positively correlated with the total number of pending matching receipts and the historical out-of-order probability, and negatively correlated with the write rate. This allows for dynamic perception of the real-time load and historical behavior characteristics of each channel, adaptively adjusting the waiting strategy and avoiding the shortcomings of fixed waiting time schemes. Simultaneously, it continuously monitors message mapping relationship update events within the waiting time. When a mapping relationship is added or updated, a trial match is immediately performed. If the match is successful, the process is completed immediately and the waiting timer is canceled. This ensures that even when a receipt arrives before the submission response, matching can be completed immediately without waiting for the full waiting time to end, effectively shortening the receipt processing latency in normal scenarios.

[0021] Receipt processing is isolated from the main sending link to ensure system throughput: This invention uses an asynchronous queue independent of the main sending link to receive and parse status receipts, configuring an independent memory buffer and an independent thread pool, and allocating different computing resource quotas to it. Receipt parsing, status storage, and business callbacks are all executed in independent resources. Even during peak receipt periods or when a business callback is blocked, it will not crowd out the thread and CPU resources of the main sending link, effectively ensuring the overall system throughput and stability.

[0022] The invention combines tiered retries, account-level circuit breaking, and channel-level self-healing to form a complete fault-tolerant closed loop: When a callback fails, the invention employs tiered retry rules, with the retry interval increasing with the number of failures, avoiding the consumption of system resources by ineffective and intensive retries. When the same business account experiences consecutive push failures reaching a threshold, automatic push for that account is automatically paused, its subsequent receipts are placed in a pending matching state, and the waiting time is extended. Pushing resumes after the pause duration reaches the recovery threshold or is manually lifted, achieving account-level isolation of the fault and preventing a single business failure from affecting other businesses. In addition, failed matching receipts are compared in batches with channel-side reconciliation files to identify channel-level missed or delayed reporting. If batch missed reporting is found, the out-of-order probability of the channel is corrected and a forced secondary matching is triggered. At the same time, the matching success rate and queue backlog trend of each channel are collected, and the waiting time baseline value is automatically adjusted to form a closed-loop self-healing mechanism of monitoring, analysis, and adjustment. Attached Figure Description

[0023] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0024] Figure 1 This is a flowchart illustrating the overall method of the present invention; Figure 2 This is a flowchart of the dynamic waiting time calculation and monitoring process of the present invention; Figure 3This is a flowchart of the entire process of receipt matching in this invention; Figure 4 This is a flowchart of the monitoring and adaptive optimization process of the present invention. Detailed Implementation

[0025] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0026] Please see Figures 1-4 An asynchronous matching and intelligent callback method based on multi-channel status receipts from SMS gateways includes: Generate a platform message number for each SMS message and establish a message mapping relationship between the platform message number and the channel message number; Asynchronously receive status receipts from different channels, parse and extract the channel message number, mobile phone number and channel identifier from the status receipts, and generate a receipt object in a unified format; The message mapping relationship is queried using the channel message number in the receipt object as the first matching key. If multiple records are matched, the optimal record is selected based on the deviation between the submission timestamp and the receipt timestamp. If no match is found or the record cannot be uniquely determined, the receipt object is set to a pending matching state, and the waiting time is dynamically calculated. During the waiting time, the update event of the message mapping relationship is continuously monitored. If the match is successful after the update, the process is completed immediately. If no match is found after the waiting period, the mobile phone number combined with the channel identifier is used as the second matching key to query again. The waiting time is determined comprehensively based on the total number of receipts to be matched, the historical out-of-order probability of the channel, and the current write rate of the message mapping relationship. If the query using the second matching key still fails to find a match, it is marked as abnormal and the process is transferred to the offline verification process. After a successful match, the protocol adapter is invoked according to the access type to convert the matching result into the corresponding protocol format and push it to the business side; if the push fails, a tiered retry rule is executed, and if the consecutive failures reach the threshold, the automatic push for the business account is suspended, and subsequent receipts are set to the pending matching status and their waiting time is extended.

[0027] Specifically, the message mapping relationship is stored in a high-speed storage medium, and an expiration period is set for each mapping record; the mapping relationship is created when a submission response is received from the channel, marked as matched after a successful acknowledgment match, and automatically expires and enters the expired unmatched processing flow if no match is found after the expiration period.

[0028] Specifically, the message mapping relationship also associates the storage of SMS content hash value and submission timestamp; when multiple records are matched using the channel message number as the first matching key, the optimal record is selected based on the deviation between the submission timestamp and the receipt timestamp, and a second verification is performed using the SMS content hash value to avoid mismatches caused by the reuse of channel message numbers for different messages.

[0029] Specifically, the dynamic calculation method for the waiting time is as follows: obtain the total number of receipts in the pending matching state under the current channel, the historical out-of-order probability of receipts in the preset time window, and the write rate of the message mapping relationship at the current moment; the waiting time is positively correlated with the total number of receipts to be matched and the historical out-of-order probability, and negatively correlated with the write rate.

[0030] Specifically, during the waiting period, continuously monitor the update events of the message mapping relationship, including: registering a listener for each receipt object in the pending matching state; when the message mapping relationship is added or updated due to any SMS receiving a channel submission response, perform a trial match between the updated mapping record and the current pending matching receipt object; if the trial match is successful, immediately trigger a matching completion event and cancel the corresponding waiting timer.

[0031] Specifically, when querying again using the mobile phone number combined with the channel identifier as the second matching key, the deviation between the submission timestamp and the receipt timestamp is limited to not exceeding a preset time window; if multiple matching records are found within the time window, the one with the smallest absolute value of the deviation between the submission timestamp and the receipt timestamp is selected as the matching result.

[0032] Specifically, the process of marking an error and transferring it to an offline verification process includes: storing the error receipt in the error receipt database, aggregating it by account and channel, and performing batch comparison with the reconciliation file provided by the channel side to identify channel-level missed reports or delayed reports; if the reconciliation finds that there are batch missed reports on the channel side, the historical out-of-order probability of the channel is corrected to a higher value, and a forced secondary matching of all pending receipts for the channel is triggered.

[0033] Specifically, the tiered retry rule is as follows: multiple retry levels are set, each level corresponds to a different retry interval, and the retry interval increases with the level; after the first push fails, it enters the first level, and after each subsequent retry failure, it enters the next level; after all levels are exceeded, retry continues at the maximum interval until the preset total number of retries is reached.

[0034] Specifically, suspending automatic push notifications for a business account when consecutive failures reach a threshold includes: counting the number of consecutive push failures for the business account within a sliding time window; marking the account as paused when a preset threshold is reached, and stopping the push of new matching results to it; during the pause, subsequent receipts for the account are set to pending matching, and their waiting time is extended based on a normal calculation value, with the extension amount related to the cumulative number of failures for the account; and resuming automatic push notifications when the pause duration reaches a preset recovery threshold or a manual release instruction is received.

[0035] Specifically, the protocol adapter has pre-set protocol conversion rules for multiple access types and supports dynamic registration of new access type protocols through configuration; the protocol conversion rules include protocol format mapping, field encoding conversion, and signature generation rules.

[0036] Specifically, the method also includes collecting fault diagnosis data for the business account. The fault diagnosis data includes: historical push success rate, failure time distribution, channel response delay trend, and fault mode marking based on the above data. The fault mode marking includes time-based faults, channel-level faults, or business logic faults, and is accompanied by corresponding troubleshooting priority sorting rules.

[0037] Specifically, this also includes end-to-end adaptive optimization: collecting the receipt matching success rate, average matching time, backlog trend of pending matching status, and account-level push failure rate of each channel; when the matching success rate is lower than the preset standard or the backlog of pending matching status continues to increase, the waiting time corresponding to the channel is increased by a preset step size to calculate the benchmark value until the matching success rate recovers or reaches the upper limit of the benchmark value; when the matching success rate is higher than the preset high standard and the backlog of pending matching status continues to decrease, the benchmark value is decreased by a preset step size.

[0038] Example 1: Receipt Matching and Callback in E-commerce Platform SMS Verification Code Sending Scenarios This embodiment uses the example of an e-commerce platform sending a registration verification code to a user via an SMS gateway to illustrate the complete execution flow of the method of the present invention.

[0039] Scene setting: The e-commerce platform sends approximately 5 million SMS messages daily, using HTTP API (for verification codes and notification SMS) and CMPP long connections (for bulk submission of marketing SMS). The SMS gateway connects to three major telecom operators (China Mobile, China Unicom, and China Telecom) and one third-party SMS channel. The latency characteristics of the delivery receipts vary significantly among the channels: the average latency for the China Mobile channel is 200ms, for the China Unicom channel it is 800ms, and the third-party channel occasionally experiences out-of-order delivery (approximately 5% of receipts arrive before the submission response).

[0040] Step 1: SMS Submission and Mapping Relationship Establishment User A registers on an e-commerce platform. The platform calls the SMS gateway HTTP API to submit a verification code SMS. The request parameters include: mobile phone number (13912345678), SMS content ("Your verification code is 123456"), template number (SMS-001), and callback address (https: / / api.shop.com / callback).

[0041] After receiving the HTTP request, the SMS gateway access layer completes parameter parsing and account authentication. The message normalization layer generates a standard SMS message object, and the business verification layer performs verifications on the blacklist, template, and balance before the message enters the queue distribution layer. The scheduling and sending layer pulls the message from the queue and submits it via the selected mobile channel through the channel adaptation layer.

[0042] During this process, the following operations are performed: A globally unique platform message number is generated for each SMS message to be submitted, such as "PLT-20260115-00123456". This message content is included when submitting the SMS to the mobile channel. The mobile channel returns a submission response, which includes the channel message number, such as "CMCC-MSG-88776655". Upon receiving the submission response from the channel, the SMS gateway immediately establishes a message mapping relationship between the platform message number and the channel message number, and stores this mapping relationship in a Redis cache. It also associates the stored mobile phone number (13912345678), channel identifier (CMCC), submission timestamp (2026-01-15 10:23:45.123), SMS content hash value (e.g., the hash value calculated using the MD5 algorithm), and access type (HTTP-API). This mapping record is set to expire after 30 seconds.

[0043] Step 2: Asynchronously receive status receipts Approximately 250ms later, the mobile channel returns the final status report (Deliver message) for the SMS message asynchronously. This status report includes: channel message number (CMCC-MSG-88776655), mobile phone number (13912345678), status code (DELIVRD, indicating successful delivery), and receipt timestamp (2026-01-15 10:23:45.356).

[0044] The SMS gateway receives the status receipt through an asynchronous queue independent of the main sending link. A consumer thread in an independent thread pool parses and extracts the channel message number, phone number, and channel identifier to generate a receipt object in a unified format. Receipt parsing and status storage are all performed in independent resources, without consuming threads or CPU resources of the main sending link.

[0045] Step 3: First matching key query Using the channel message number (CMCC-MSG-88776655) in the receipt object as the first matching key, query the message mapping relationship in Redis. This query found a unique record (platform message number PLT-20260115-00123456), and the match was successful.

[0046] In scenarios involving reused channel message numbers (e.g., a third-party channel reuses message numbers every 24 hours), multiple records may be matched when using the channel message number as the first matching key. In this case, the optimal record is selected based on the deviation between the submission timestamp and the receipt timestamp—the difference between the submission timestamp and the current receipt timestamp of each candidate record is calculated, and the record with the smallest absolute deviation is selected. Simultaneously, a secondary verification is performed using the SMS content hash value. The hash of the SMS content carried in the receipt (if returned by the channel) or the content hash inferred from the context is compared with the hash value in the candidate record to further confirm the matching accuracy and avoid mismatches caused by the reuse of channel message numbers for different messages.

[0047] Step 4: Callback after successful matching Upon successful matching, the corresponding protocol adapter is invoked based on the access type (HTTP-API). The protocol adapter encapsulates the matching result (status code DELIVRD, completion time, etc.) into JSON format and asynchronously sends it back to the callback address configured by the business (https: / / api.shop.com / callback) via an HTTP POST request.

[0048] If the callback is successful, the business side will update the user's verification code sending status after receiving the status notification.

[0049] If a callback fails (e.g., the business server is temporarily unavailable), a tiered retry rule is followed: after the first failure, wait 1 second before retrying; after the second failure, wait 2 seconds before retrying; after the third failure, wait 4 seconds before retrying, and so on. The retry interval increases with the number of failures to avoid unnecessary and intensive retries consuming system resources. If the number of consecutive push failures for a business account (shop-app) reaches a preset threshold (e.g., 5 times), automatic push notifications for that account will be automatically suspended, and subsequent receipts will be set to a pending matching status with an extended waiting time. Automatic push notifications for that account will resume once the suspension duration reaches a preset recovery threshold (e.g., 60 seconds) or is manually lifted by operations personnel, preventing a single business interface failure from affecting the normal callbacks of other business accounts.

[0050] Example 2: Out-of-order scenario where the acknowledgment arrives before the submission response This embodiment illustrates how the present invention addresses the problem of out-of-order channel retrieval.

[0051] Scene setting: A third-party channel exhibits out-of-order delivery of receipts; in approximately 5% of scenarios, the status report is returned to the SMS gateway before the submission response.

[0052] Standard procedure: User B submitted a notification SMS via HTTP API. The platform message number is "PLT-20260115-00234567". The submission was made through a third-party channel selected by the channel adaptation layer.

[0053] Out-of-order occurrence: The third-party channel returned a status report (channel message number "THIRD-MSG-99887766", status code DELIVRD) after 120ms, but the commit response had not yet been returned. Therefore, the message mapping relationship had not yet been established (because the mapping relationship is only created when the channel commit response is received). At this time, the receipt object queried the message mapping relationship in Redis using the channel message number THIRD-MSG-99887766 as the first matching key, but the query failed.

[0054] Handling method: Set the receipt object to a pending matching state and dynamically calculate the waiting time. The calculation process is as follows: Get the total number of receipts Q that are currently in the matching state under this channel (THIRD) (currently 3); Obtain the historical out-of-order probability P of the channel within a preset time window (e.g., the most recent 5 minutes) (currently 5%). Get the current message mapping relationship write rate V (currently approximately 200 messages / second); The waiting time T is determined by combining the above three dimensions: T is positively correlated with the total number of pending matching receipts Q and the historical out-of-order probability P (the larger Q and the higher P are, the longer the waiting time), and negatively correlated with the write speed V (the higher V is, the faster the submission response is returned, and the waiting time can be shortened accordingly).

[0055] Assume the calculated waiting time is 800ms.

[0056] During the waiting period, continuously listen for message mapping updates. Specifically, register a listener for each receipt object currently in the pending matching state. After approximately 150ms, the third-party channel returns a commit response, containing the channel message number THIRD-MSG-99887766. Upon receiving the commit response, the SMS gateway immediately creates the message mapping and writes it to Redis. At this point, the listener detects the addition of a new mapping and immediately performs a trial match between the updated mapping record and the pending receipt object. If the channel message number matches successfully, a matching completion event is immediately triggered, and the corresponding waiting timer is canceled.

[0057] The entire matching process is completed within milliseconds after the submitted response is returned, without having to wait for the full 800ms wait time to end, effectively shortening the receipt processing delay in normal scenarios.

[0058] Example 3: Second matching key lookup when the first matching key cannot be uniquely determined This embodiment illustrates how the present invention completes the matching using a second matching key when the first matching key query cannot uniquely determine the match.

[0059] Scene setting: Due to an internal mechanism issue, a certain channel assigned the same channel message number to two different SMS messages in an extreme case (channel message number reuse), and the submission timestamps and receipt timestamps of the two SMS messages were close in deviation, making it difficult to uniquely determine the message based solely on the time deviation.

[0060] Processing flow: Using the channel message number "CMCC-MSG-11223344" as the first matching key, a message mapping query was performed, and two records were found: Record A: Platform message number PLT-20260115-00345678, mobile phone number 13912345678, submission timestamp 10:25:30.100; Record B: Platform message number PLT-20260115-00345679, mobile phone number 13987654321, submission timestamp 10:25:30.200.

[0061] Based on the deviation between the submission timestamp and the receipt timestamp (10:25:30.350), record A has a deviation of 250ms and record B has a deviation of 150ms, making it impossible to uniquely determine the optimal record (both deviations are small, and the reuse of channel message numbers makes it impossible to distinguish them accurately).

[0062] Set the receipt object to a pending matching state and dynamically calculate the waiting time (assumed to be 500ms). During the waiting time, continuously listen for updates to the mapping relationship, but no new mapping is added to match the current receipt.

[0063] If no match is found after the waiting period, the message mapping relationship will be queried again using the mobile phone number (13912345678) combined with the channel identifier (CMCC) as the second matching key. During the query, the deviation between the submission timestamp and the receipt timestamp is further limited to a preset time window (e.g., ±5 seconds). If only record A is matched within this time window, the match is successful.

[0064] If multiple matching records are found within the time window, the record with the smallest absolute difference between the submission timestamp and the receipt timestamp will be selected as the matching result.

[0065] Example 4: Channel-level verification and parameter self-correction of abnormal receipts This embodiment illustrates how the present invention handles exceptions for failed matching receipts and corrects the matching strategy based on the verification results.

[0066] Scene setting: During a certain period, the success rate of receipt matching in the China Unicom channel suddenly dropped from 99.5% to 85%. A large number of receipts could not be matched after querying the first and second matching keys and were marked as abnormal.

[0067] Handling method: The abnormal receipts are stored in the abnormal receipt database, aggregated by account and channel (aggregated by China Unicom channel in this embodiment), alarm logs are generated, and alarm notifications are pushed to the operation and maintenance end.

[0068] Simultaneously, an offline verification process is initiated: the anomaly receipts are compared in batches with the daily reconciliation files provided by the China Unicom channel side. The reconciliation files contain the channel message number, mobile phone number, status, and timestamp of all sent SMS messages recorded by the China Unicom channel side.

[0069] The comparison revealed that during this period, a batch of SMS messages on the Unicom channel side had their channel message number prefixes changed (from "CUCC-" to "CUCC-NEW-"), but the SMS gateway side still matched them according to the old prefix, resulting in a batch of missed reports at the channel level.

[0070] Based on the reconciliation results, the historical out-of-order probability of the channel (China Unicom) is automatically corrected to a higher value (because the numbering rules on the channel side have changed, which is regarded as a special "out-of-order" or "abnormal" event), and a forced secondary matching of all pending matching receipts of the channel is triggered - the pending matching receipts are re-compared with the mapping relationship, and the matching rules of the channel message number are relaxed (such as using fuzzy matching or prefix adaptation).

[0071] Meanwhile, by collecting indicators such as the matching success rate and the backlog trend of the waiting queue for each channel, the baseline value for calculating the waiting time is automatically adjusted: when the matching success rate is lower than the preset standard (such as 95%) or the backlog of waiting status continues to increase, the baseline value for calculating the waiting time for that channel is increased by a preset step size, giving more time to wait for the receipt to arrive; when the matching success rate recovers to the preset high standard (such as 99%) and the backlog decreases, the baseline value is decreased by a preset step size, forming a closed-loop self-healing mechanism of monitoring, analysis and adjustment.

[0072] Example 5: Configurable Extension of Protocol Adapters This embodiment illustrates how the present invention supports new access types through a configurable approach.

[0073] Scene setting: The SMS gateway originally only supported callbacks for HTTP API and CMPP access types. One day, the system needed to add integration with an international SMS channel using the AWS SNS protocol. This channel required status receipts to be pushed to a specified endpoint via an SNS topic.

[0074] Handling method: The protocol adapter has pre-defined protocol conversion rules for various access types and supports dynamic registration of new access type protocols through configuration. Operations personnel do not need to modify code or restart services; they only need to add a new protocol conversion rule configuration in the configuration center, including: Access type identifier: AWS-SNS; Protocol format mapping: Map the fields in the internal unified status result (platform message number, mobile phone number, status code, completion time, etc.) to the JSON field format required by AWS SNS; Field encoding conversion: Convert internal status codes (such as "DELIVRD") into enumeration values ​​required by the SNS protocol (such as "success"). Signature generation rules: The push content is signed according to the AWS Signature V4 algorithm.

[0075] Once configured, when the access type of the matching result is AWS-SNS, the protocol adapter automatically loads the configuration, converts the matching result to the SNS protocol format, and pushes it to the specified Endpoint. The entire scaling process requires no downtime and no redeployment.

[0076] Example 6: Fault Diagnosis and Intelligent Operation and Maintenance This embodiment illustrates how the present invention assists maintenance personnel in quickly locating problems through fault diagnosis data.

[0077] Scene setting: The operations and maintenance personnel received an alert: the success rate of push notifications for the business account "marketing-app" plummeted from 98% to 30% within 10 minutes.

[0078] Collect fault diagnosis data for this business account, including: Historical push success rate (trend over the past 1 hour, 24 hours, and 7 days). Failure time distribution (whether failures are concentrated in a specific time period); Channel response delay trend (changes in the receipt delay of each channel used by this account).

[0079] Based on the above data, fault mode labels are automatically generated: If failures are concentrated in a specific period between 20:00 and 22:00 each day, they are marked as time-limited failures, prompting operations and maintenance personnel to check whether there is a sudden increase in business volume during that period or whether there is routine maintenance during that period. If the failures are concentrated in a specific channel (such as the Unicom channel), while other channels are normal, it is marked as a channel-level failure, prompting the operations and maintenance personnel to check the connectivity of that channel or the reconciliation file; If failures are scattered across various channels without a clear time pattern, but the account's SMS content template has recently changed, then it is marked as a business logic failure, prompting operations and maintenance personnel to check the template parameters or callback address configuration.

[0080] The system also includes corresponding troubleshooting priority rules: channel-level faults have the highest priority (widest impact), followed by time-related faults, and business logic faults have a relatively lower priority. Operations personnel can use this priority to quickly locate and resolve problems.

[0081] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. An asynchronous matching and intelligent callback method based on multi-channel status feedback from an SMS gateway, characterized in that, include: Generate a platform message number for each SMS message and establish a message mapping relationship between the platform message number and the channel message number; Asynchronously receive status receipts from different channels, parse and extract the channel message number, mobile phone number and channel identifier from the status receipts, and generate a receipt object in a unified format; Use the channel message number in the receipt object as the first matching key to query the message mapping relationship; if the query matches multiple records, select the optimal record based on the deviation between the submission timestamp and the receipt timestamp. If the query fails to find a match or cannot be uniquely determined, the receipt object is set to a pending matching state, and the waiting time is dynamically calculated. During the waiting time, the update event of the message mapping relationship is continuously monitored. If the match is successful after the update, the process is completed immediately. If no match is found after the waiting period expires, the mobile phone number combined with the channel identifier is used as the second matching key for another query. The waiting time is determined based on the total number of pending matching receipts, the historical out-of-order probability of the channel, and the current write rate of the message mapping relationship. If the query using the second matching key still fails to find a match, it is marked as abnormal and the process is transferred to the offline verification process. After a successful match, the protocol adapter is invoked according to the access type to convert the matching result into the corresponding protocol format and push it to the business side; If the push fails, a tiered retry rule will be followed. If consecutive failures reach a threshold, automatic push for the account will be suspended, and subsequent receipts will be set to pending matching status with an extended waiting time.

2. The method according to claim 1, characterized in that, The message mapping relationship is stored in a high-speed storage medium, and an expiration period is set for each mapping record; The mapping relationship is created when a submission response is received from the channel. It is marked as matched after a successful matching of the receipt. If it fails to match within the validity period, it automatically expires and is transferred to the expired unmatched processing flow.

3. The method according to claim 1, characterized in that, The message mapping relationship also associates the storage of SMS content hash value and submission timestamp; when multiple records are matched using the channel message number as the first matching key, the optimal record is selected based on the deviation between the submission timestamp and the receipt timestamp, and a second verification is performed using the SMS content hash value to avoid mismatches caused by the reuse of channel message numbers for different messages.

4. The method according to claim 1, characterized in that, The dynamic calculation method for the waiting time is as follows: obtain the total number of receipts in the pending matching state under the current channel, the historical out-of-order probability of receipts in the preset time window, and the write rate of the message mapping relationship at the current moment; the waiting time is positively correlated with the total number of receipts to be matched and the historical out-of-order probability, and negatively correlated with the write rate.

5. The method according to claim 1, characterized in that, During the waiting period, continuously monitor the update events of the message mapping relationship, specifically including: registering a listener for each receipt object in the pending matching state; when the message mapping relationship is added or updated due to any SMS receiving a channel submission response, perform a trial match between the updated mapping record and the current pending matching receipt object; if the trial match is successful, immediately trigger a matching completion event and cancel the corresponding waiting timer.

6. The method according to claim 1, characterized in that, When querying again using the mobile phone number combined with the channel identifier as the second matching key, the deviation between the submission timestamp and the receipt timestamp is limited to no more than a preset time window; if multiple matching records are found within the time window, the record with the smallest absolute value of the deviation between the submission timestamp and the receipt timestamp is selected as the matching result.

7. The method according to claim 1, characterized in that, The process of marking an error and transferring it to offline verification includes: storing the error receipt in the error receipt database, aggregating it by account and channel, and performing batch comparison with the reconciliation file provided by the channel side to identify channel-level missed reports or delayed reports; if the reconciliation finds that there are batch missed reports on the channel side, the historical out-of-order probability of the channel is corrected to a higher value, and a forced secondary matching of all pending receipts for the channel is triggered.

8. The method according to claim 1, characterized in that, The tiered retry rule is as follows: multiple retry levels are set, each level corresponds to a different retry interval, and the retry interval increases with the level; after the first push fails, it enters the first level, and after each subsequent retry failure, it enters the next level; after exceeding all levels, it continues to retry at the maximum interval until the preset total number of retries is reached.

9. The method according to claim 1, characterized in that, The automatic push notification for the service account is suspended when consecutive failures reach a threshold. Specifically, this includes: counting the number of consecutive push failures for the service account within the sliding time window; when the preset threshold is reached, marking the account as suspended and stopping the push of new matching results to it; during the suspension period, the subsequent receipts corresponding to the account are set to pending matching, and their waiting time is extended based on the normal calculation value, with the extension amount related to the cumulative number of failures for the account; automatic push notifications are resumed when the suspension duration reaches a preset recovery threshold or a manual release instruction is received.

10. The method according to claim 1, characterized in that, The protocol adapter has pre-defined protocol conversion rules for multiple access types and supports dynamic registration of new access type protocols through configuration. The protocol conversion rules include protocol format mapping, field encoding conversion, and signature generation rules.

11. The method according to claim 1, characterized in that, It also includes collecting fault diagnosis data for the business account. The fault diagnosis data includes: historical push success rate, failure time distribution, channel response delay trend, and fault mode marking based on the above data. The fault mode marking includes time-based faults, channel-level faults, or business logic faults, and is accompanied by corresponding troubleshooting priority sorting rules.

12. The method according to claim 1, characterized in that, It also includes end-to-end adaptive optimization: collecting the receipt matching success rate, average matching time, backlog trend of pending matching status, and account-level push failure rate of each channel; when the matching success rate is lower than the preset standard or the backlog of pending matching status continues to grow, the waiting time corresponding to the channel is increased by a preset step size to calculate the benchmark value until the matching success rate recovers or reaches the upper limit of the benchmark value. When the matching success rate is higher than the preset high standard and the backlog of unmatched states continues to decrease, the benchmark value is lowered by a preset step size.

Images