A method and system for unified dispatching of notification messages

Abstract

The application discloses a unified dispatching sending method and system of notification messages, and relates to the technical field of computer communication. The method comprises a request access stage and a sending execution stage. The request access stage receives an external notification request, acquires notification configuration information, generates a notification record, saves the notification record, and returns a notification identifier to the backward request party to realize asynchronous decoupling. The sending execution stage scans a to-be-sent notification according to a preset period through a timing polling mechanism, judges an instant or delay type according to the notification configuration, verifies a trigger condition, assembles a message body for the notification meeting the condition, and then calls a channel to send, updates a state according to a sending result, triggers a retry mechanism when a failure occurs, and re-includes the notification in the timing polling range. The application realizes decoupling of a business system and a channel through a unified access layer, uniformly dispatches instant notification, delay notification and retry notification through timing polling, improves sending reliability through a configured retry strategy, and realizes end-to-end observability through full-link state tracking.

Description

Technical Field

[0001] This invention relates to the field of computer communication technology, and in particular to a unified scheduling and sending method and system for notification messages. Background Technology

[0002] In modern software systems, sending notification messages is a crucial channel connecting the system and users, widely used in scenarios such as order status reminders, account security alerts, and marketing outreach. Traditional notification sending methods typically involve the business system directly connecting to various notification channels (such as SMS gateways, email servers, and app push platforms), synchronously calling the channel interfaces within the business logic to complete the sending process.

[0003] The aforementioned traditional model has significant technical drawbacks: First, at the system architecture level, each business system is directly coupled with the notification channel. Adding a new business scenario or notification channel requires modifying the business system code and redeploying, resulting in high integration costs and maintenance difficulties. It also lacks a unified access layer to standardize requests and shield channels. Second, at the interface performance level, business systems typically use a synchronous blocking method to call the channel interface, waiting for the channel to return the sending result. However, the response time of the channel interface often fluctuates significantly, leading to increased business interface latency, higher client timeout rates, and a high risk of message loss due to synchronous waiting when the channel experiences an anomaly. Third, in In terms of delivery reliability, the traditional model lacks an effective retry mechanism. Once a single delivery fails (such as due to network jitter or channel throttling), the message is considered a delivery failure and cannot be automatically recovered, resulting in a decrease in notification delivery rate. Fourth, in delayed notification scenarios, the traditional model usually relies on the business system to maintain scheduled tasks or use external delayed queues, which is disconnected from the sending logic of instant notifications and lacks a unified scheduling mechanism, resulting in high system complexity and low resource utilization. Fifth, in terms of observability, the notification sending process lacks end-to-end state tracking capabilities. Businesses cannot know in real time whether the notification has been sent or whether it was successful, making it difficult to quickly locate problems.

[0004] Therefore, there is an urgent need for a notification message sending scheme that can achieve asynchronous decoupling between request access and sending execution, unified scheduling of immediate and delayed notifications, reliable retry mechanism, and end-to-end status tracking. Summary of the Invention

[0005] The technical problem this invention aims to solve is that in existing notification sending modes, the direct coupling between the business system and the notification channel leads to high integration costs, synchronous blocking calls result in poor interface performance and easy message loss, the lack of a unified scheduling mechanism leads to the separation of instant and delayed notification processing, the inability to automatically recover from sending failures results in low delivery rates, and the sending process lacks end-to-end status tracking capabilities.

[0006] To address the aforementioned technical problems, this invention provides a unified scheduling and sending method for notification messages. The method includes a request access phase and a sending execution phase. The request access phase enables asynchronous decoupling between external notification requests and message sending execution, while the sending execution phase enables batch scheduling and reliable sending based on timed polling.

[0007] During the access request phase, the system first receives an external notification request and obtains the notification configuration information corresponding to the request. This external notification request is initiated by the business system and includes key information such as the notification content, recipient identifier, and notification type identifier. After receiving the external notification request through the unified access interface, the system does not immediately call the channel interface to execute the sending. Instead, it queries a preset notification configuration library based on the notification type identifier to obtain the corresponding notification configuration information. This notification configuration information includes channel configuration, template configuration, delay policy configuration, and retry policy configuration. This configuration-based approach decouples the notification content from the sending policy, allowing the same business system to adapt to different sending scenarios by changing the configuration without modifying the code.

[0008] Subsequently, the system generates and saves a notification record based on the notification configuration information and the content of the external notification request, and returns a notification identifier to the requester. The generation of the notification record involves associating and storing the notification content, recipient identifier, notification type identifier, and notification configuration information, generating a globally unique notification identifier, and marking the initial state of the notification record as pending delivery. Through this persistence operation, even if the requester experiences a network interruption or client error after receiving the notification identifier, the notification request itself is reliably saved and will not be lost. The requester can terminate the call upon receiving the notification identifier without waiting for actual delivery completion, thus achieving asynchronous decoupling between request access and delivery execution, eliminating the impact of synchronous blocking waiting on the performance of the business interface.

[0009] During the sending execution phase, the system scans the notification database at preset intervals using a timed polling mechanism to obtain notification records to be sent within the current period. The timed polling mechanism starts a scheduled task at preset intervals to scan the notification database for notification records in the "pending sending" state whose next trigger time is less than or equal to the current time, and obtains records that meet the conditions in batches. To avoid duplicate message sending caused by concurrent scanning by multiple nodes in a distributed environment, the system temporarily locks the notification records within each batch when obtaining them in batches, ensuring that records within the same batch are only obtained by one processing node within the same period. Through the batch scheduling method of timed polling, the system can process a large number of notifications to be sent uniformly at a lower frequency, avoiding the pressure on the database caused by high-frequency real-time polling, while improving sending throughput through batch acquisition and locking mechanisms.

[0010] For each acquired notification record to be sent, the system determines its notification type as either an immediate or delayed notification based on the notification configuration information, and verifies whether the current time meets the preset triggering condition for the delayed notification. If no delay policy is configured in the notification configuration information, it is determined to be an immediate notification, and message assembly and sending are performed directly. If a delay policy is configured, it is determined to be a delayed notification, and subsequent sending operations are only performed when the current system time reaches the preset triggering time configured by the delay policy. By using a unified timed polling mechanism to schedule both immediate and delayed notifications, there is no need to maintain a separate delay queue or scheduled task for delayed scenarios, simplifying the system architecture and improving the reuse rate of scheduling resources.

[0011] For notification records that meet the triggering conditions, the system assembles the message body according to the notification type and channel configuration in the notification configuration information, and calls the corresponding sending channel to execute message sending. The message assembly process includes matching the corresponding message template from the template library according to the notification type identifier, determining the target sending channel according to the channel configuration, and filling the notification content into the preset placeholders in the message template to generate a message body that conforms to the protocol requirements of the target sending channel. Through the message assembly mechanism that combines template-based and channel-configurable methods, the system can support heterogeneous protocol adaptation for various notification channels (such as SMS, email, APP push, etc.), and when adding a new channel or template, only the configuration needs to be extended without modifying the core sending logic.

[0012] After transmission is complete, the system updates the status of the notification record based on the transmission result. If transmission is successful, the notification record is marked as successfully transmitted; if transmission fails, a retry mechanism is triggered. The retry mechanism reads the retry policy configuration from the notification configuration information, obtains the maximum number of retry attempts and the retry interval policy, and determines whether the current number of retries has reached the maximum number of retries. If not, the status of the notification record is updated to retrying, the next trigger time is calculated and updated according to the retry interval policy, and the notification record is reinstated into the scanning range of the timed polling mechanism, waiting for the next cycle to attempt transmission again; if the maximum number of retries has been reached, the notification record is marked as a failed transmission, an alarm is triggered, and the notification record is retained for manual intervention. By deeply coupling the retry mechanism with the timed polling mechanism, retry notifications do not need to enter a separate retry queue, but instead reuse the same scheduling channel as instant and delayed notifications, and are uniformly scanned and triggered by timed polling, simplifying the retry scheduling logic and avoiding the complexity of maintaining multiple queues.

[0013] Furthermore, the method also includes end-to-end state tracking. During the request access phase, the system generates and records a tracking identifier, binding the tracking identifier to the notification identifier. During the delivery execution phase, each processing node records a state change log, which includes the tracking identifier, current state, timestamp, and node information. Based on the tracking identifier, a notification status query interface is provided, allowing the requester to query the end-to-end processing status of the notification in real time. By using the tracking identifier throughout both the request access and delivery execution phases, end-to-end observability is achieved from the business system initiating the request to the final delivery via the channel.

[0014] The beneficial effects of this invention include: Asynchronous decoupling improves interface performance: Through the persistence and immediate return notification mechanism in the request access phase, the business system does not need to synchronously wait for the channel to send the result, eliminating the impact of synchronous blocking on the performance of the business interface and reducing the client timeout rate; Unified scheduling reduces architectural complexity: The timed polling mechanism unifies the scheduling of instant notifications, delayed notifications, and retry notifications, eliminating the need to maintain multiple independent scheduling systems or delay queues, simplifying the system architecture and improving the reusability of scheduling resources. Reliable retries improve delivery rate: Through configurable retry strategies and timed polling reuse mechanisms, the system automatically retryes according to the strategy when a transmission fails, and retains failure records and triggers alarms after reaching the maximum number of retries, which greatly improves the delivery rate and transmission reliability of notification messages. End-to-end traceability: By tracking identifiers throughout the entire process of request access and execution, real-time query of notification status and rapid problem location are achieved, improving the maintainability of the system.

[0015] This invention also provides a unified scheduling and sending system for notification messages, including a unified access module, a timed scheduling module, a message assembly module, a channel sending module, a status management module, and a configuration management module. The unified access module is used to execute the aforementioned request access phase; the timed scheduling module is used to execute the aforementioned timed polling and batch locking; the message assembly module is used to execute the aforementioned template matching and placeholder filling; the channel sending module is used to call each sending channel to execute message sending; the status management module is used to execute the aforementioned status update and retry mechanism; and the configuration management module is used to store and manage the aforementioned notification configuration information.

[0016] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the unified scheduling and sending method for notification messages as described above. Attached Figure Description

[0017] Figure 1The system swimlane flowchart of the unified scheduling and sending method for notification messages in this embodiment of the invention shows the interaction flow between external clients, external interface platforms and unified notification services in the request access phase, as well as the interaction flow between timers and services in the sending execution phase.

[0018] Figure 2 This is a system architecture diagram of an embodiment of the present invention, illustrating the interaction relationships between the business call layer, the notification center core layer, the message queue layer, the channel adaptation layer, and the data storage layer.

[0019] Figure 3 The notification record state machine flow diagram of this embodiment of the invention shows the complete state transition path of a notification record from creation to successful transmission, transmission failure, or retry.

[0020] Figure 4 This is a channel adaptation class diagram for an embodiment of the present invention, illustrating the class relationships between the unified access interface, various channel adapters, and message templates.

[0021] Figure 5 This is a flowchart of the timed scheduling and retry mechanism in an embodiment of the present invention, showing the complete execution flow of timed polling, message sending, failure retry, and status update. Detailed Implementation

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

[0023] I. System Overall Architecture like Figure 1 and Figure 2 As shown, the unified scheduling and sending system for notification messages in this embodiment involves multiple interactive entities and a layered architecture. External clients, as the initiators of the business system, initiate notification requests by calling the unified access interface provided by the external interface platform. The external interface platform, as the unified access layer, is responsible for receiving requests, obtaining configurations, and encapsulating responses. The unified notification service, as the core processing layer, is responsible for the persistence of notification records, state management, and subsequent sending scheduling. The sending execution phase is driven by a timer, which works in conjunction with the business modules. The timer is responsible for scanning notifications to be sent according to a preset period, while the business modules are responsible for the specific message assembly, channel sending, and status updates.

[0024] II. Access Request Phase Step S101: Receive external notification request.

[0025] External clients (business systems) send notification requests to the external interface platform through a unified access interface. The notification request includes at least the notification content, the recipient identifier, and the notification type identifier. For example, in an order status change notification scenario, the notification content is "Your order #12345 has been shipped," the recipient identifier is the user's mobile phone number or user ID, and the notification type identifier is "ORDER_SHIP".

[0026] After receiving a notification request, the external interface platform queries the preset notification configuration library in the configuration management module according to the notification type identifier to obtain the corresponding notification configuration information. The notification configuration information includes at least channel configuration (such as SMS channel, email channel), template configuration (such as template ID), delay policy configuration (such as whether to delay and the delay time), and retry policy configuration (such as maximum number of retries and retry interval).

[0027] The unified access interface is implemented using RESTful API and Spring Cloud Feign, with the protocol being HTTP / HTTPSPOST, and the interface path being / notify / send. The complete list of request parameters is as follows: The `notify` parameter is a required array type, representing the list of notification requests; `serialNumber` is a required string type, representing the business serial number; `notifyMethod` is a required enumeration type, representing the notification method, where enumeration value 1 corresponds to HTTP callback, 2 to SMS, 3 to email, 4 to WeChat, and 5 to DingTalk; `notifyExecuteType` is a required enumeration type, representing the execution method, where enumeration value 1 corresponds to real-time sending and 2 to delayed sending; `notifyRetry` is a required enumeration type, representing whether to retry, where enumeration value 1 corresponds to retry and 2 to no retry; `notifyTime` is a required date and time type, representing the execution time; `retryStrategyType` is a required enumeration type, representing the retry strategy type, where enumeration value 1... The default strategy is 1, and the custom strategy is 2. `retryStrategy` is an optional array type representing a custom retry strategy, for example, it can be configured as [3,5,9,14]. `http` is an optional object type representing HTTP channel parameters, including `url`, `mediaType`, and `param`. `sms` is an optional object type representing SMS channel parameters, including `phone`, `templateCode`, and `param`. `email` is an optional object type representing email channel parameters, including `recipient` and `context`. `weChat` is an optional object type representing WeChat channel parameters, including `openId`, `templateId`, `url`, `data`, and `miniProgram`. `config` is an optional JSON type representing channel configuration, for example, it can be configured as `{"1": "{WeChat configuration JSON}"}`. `notifyReceive` is a required enumeration type representing the receiving business channel, where enumeration values ​​1 correspond to factoring, 2 to bills, 3 to Shaanxi Construction, 4 to installation, 5 to Zhuxin, and 9 to others.

[0028] Taking the table `t_open_org_additional_config` as an example, the data structure of the notification configuration library contains the following fields: `id` is a BIGINT type with a length of 20, serving as the primary key; `org_id` is a BIGINT type with a length of 20, representing the organization ID; `config_type_cd` is a VARCHAR type with a length of 32, representing the configuration type, for example, the enumeration value 1 corresponds to WeChat configuration; `config` is a TEXT type, storing the configuration JSON, which may contain information such as `appId` and encryption key. An example of the JSON content of the `config` field is as follows: `appId` value is `wx1234567890abcdef`; `appSecret` value is the AES-encrypted key; and `key` value is the hexadecimal string of the encryption key.

[0029] Step S102: Generate and save the notification record, and return the notification identifier.

[0030] The unified notification service generates notification records based on notification configuration information and the content of external notification requests. The data structure of the notification record includes at least: a notification identifier, which is globally unique; a tracking identifier; a notification type; a recipient identifier; notification content; notification configuration information; current status; number of retries; next trigger time; and creation time.

[0031] The system persistently saves the notification record to the notification database and marks the initial state of the notification record as "pending send," corresponding to status code 0 and the enumeration value STATUS_0, meaning initialization—that is, just created and not yet executed. The system initializes the number of retries to zero and sets the next trigger time to the current time (for immediate notifications) or the current time plus a delay (for delayed notifications). After saving, the system returns a notification identifier to the requester.

[0032] The notification identifier generation algorithm is implemented using the MySQL auto-incrementing primary key IDENTITY, specifically through the annotation @GeneratedValue(strategy = GenerationType.IDENTITY, generator = "SELECT LAST_INSERT_ID()"). This method relies on MySQL's AUTO_INCREMENT mechanism to guarantee global uniqueness, sortability, and high performance.

[0033] The database table for the main notification record is named t_notify. This table contains the following fields: id (BIGINT type, representing the primary key ID, using an auto-incrementing strategy); notify_method_cd (VARCHAR type, representing the notification method code); notify_execute_type_cd (VARCHAR type, representing the execution method code); execute_time (DATETIME type, representing the execution time); next_notify_time (DATETIME type, representing the next execution time); notify_retry_cd (VARCHAR type, indicating whether to retry); retry_strategy_cd (VARCHAR type, representing the retry strategy code); times (INT type, representing the number of notifications, i.e., the number of retries); notify_status_cd (VARCHAR type, representing the notification status); serial_number (VARCHAR type, representing the business serial number); and config (TEXT type, representing dynamic configuration, stored in JSON format).

[0034] The index design includes the following three items: the primary key index PRIMARY KEY operates on the id field; the index idx_notify_status_time operates on the combination of the notify_status_cd and execute_time fields to support scheduled polling queries; and the index idx_serial_number operates on the serial_number field to support business serial number queries.

[0035] The associated sub-tables include the following seven: `t_notify_http` stores HTTP channel details, with key fields including `notify_url`, `media_type`, and `notify_param`; `t_notify_sms` stores SMS channel details, with key fields including `phone`, `template_code`, and `param`; `t_notify_email` stores email channel details, with key fields including `recipient`, `title`, and `context`; `t_notify_wx` stores WeChat channel details, with key fields including `open_id`, `template_id`, `url`, `param`, and `mini_program`; `t_notify_retry_strategy` stores retry strategy configurations, with key fields including `default_cd` and `retry_strategy`; `t_notify_receive_channel` stores business channel associations, with key field including `notify_receive_cd`; and `t_notify_statement` stores sending records, with key field including `notify_times`.

[0036] Currently, no table or database sharding strategy is being used because the business volume is within the capacity of a single database and table, reaching millions of records. Furthermore, query performance can be optimized using the composite index `idx_notify_status_time`. If the data volume grows in the future, horizontal table sharding based on the `notify_status_cd` field or vertical table sharding based on time ranges can be implemented.

[0037] Once the requesting party receives the notification identifier, it can confirm that the notification request has been received and persisted by the system without waiting for the actual sending to complete, thus ending the call. Through this asynchronous decoupling mechanism, the interface response time of the business system is no longer affected by the performance fluctuations of the channel interface.

[0038] III. Sending and Execution Phase like Figure 5 As shown, the execution flow of the timed scheduling and retry mechanism is as follows.

[0039] Step S201: Periodically poll to obtain notifications to be sent.

[0040] The timer starts a scheduled task at a preset period, such as once per minute, to scan the notification database. The scanning conditions are: the status is equal to the pending status (status code 0) and the next trigger time is less than or equal to the current system time. The system retrieves notification records that meet the conditions in a preset batch size, such as 100 records at a time.

[0041] To prevent the same notification from being sent repeatedly due to concurrent scanning by multiple service nodes in a distributed deployment environment, the system performs a locking operation when retrieving batch records. For example, it can use a database row-level lock, i.e., a SELECT statement with a FOR UPDATE clause, to lock the batch of records retrieved in this session, or it can use a distributed lock, such as the SETNX command based on Redis, to lock the batch of records retrieved in this session, ensuring that the same record is processed by only one node during the locking period.

[0042] The scheduled tasks are implemented using a combination of Spring Scheduler and RocketMQ message queues. Spring Scheduler tasks are implemented by NotifyCenterJobServiceImpl, which scans the database every minute. The scan criteria are that the `execute_time` field value is between 0 and 59 seconds of the current time, and the `notify_status_cd` field value is 0. The system encapsulates the scanned notification ID into a `MessageEntity` and sends it to the RocketMQ `notify_topic`. The RocketMQ consumer `NotifyCenterConsumer` receives the message and calls the `resendMsg` method to actually send it.

[0043] The mechanism to prevent concurrent duplicate sending includes the following four layers: At the database level, optimistic locking is used through the status field notify_status_cd to verify the status before sending; at the RocketMQ level, the CLUSTERING cluster message mode is adopted to ensure that the same message is consumed by only one consumer instance; the consumer is configured with the ConsumeMessageBatchMaxSize parameter set to 1 to ensure that messages are processed one by one; the lock timeout handling adopts the default RocketMQ message timeout of 15 minutes, and if no acknowledgment is made after the timeout, the message will be automatically resent.

[0044] The single-round polling batch retrieval strategy is as follows: Currently, it retrieves notification records that meet the preset batch size, such as 100 records. The number of notification records is optimized for query performance using a database index, specifically a combined index of the `notify_status_cd` and `execute_time` fields. If the single-round polling results are too large, RocketMQ will automatically perform traffic smoothing, and the messages will be queued to await consumption.

[0045] If no notification to be sent is obtained in this round of scanning, the timer ends the current round and waits for the next cycle to scan again.

[0046] Step S202: Determine the notification type and verify the triggering conditions.

[0047] For each acquired notification record to be sent, the system determines whether the notification type is an immediate notification or a delayed notification based on the notification configuration information, and verifies whether the current time meets the preset triggering conditions of the delayed notification.

[0048] If no delay policy is configured in the notification configuration information, it is determined to be an immediate notification, and message assembly and sending are performed directly; if a delay policy is configured, it is determined to be a delayed notification, and the current system time is checked to see if the preset trigger time configured by the delay policy has been reached. Subsequent sending operations are only performed when the preset trigger time has been reached.

[0049] The absolute delay mode uses the `notifyTime` field to specify the precise trigger time, in ISO8601 format, such as 2025-06-04T16:30:00. For immediate notifications, the `notifyExecuteType` value is 1, and `notifyTime` is set to the current time; for delayed notifications, the `notifyExecuteType` value is 2, and `notifyTime` is set to a future time. The relative delay mode, such as sending after X minutes, can also be implemented using the same mechanism, with the business system calculating the target time and then passing it in.

[0050] Delayed and immediate notifications are stored in the same table, t_notify, sharing the same index—a composite index consisting of the notify_status_cd and execute_time fields—to support efficient scheduled polling queries. Currently, database partitioning is not used; sub-second query response times are achieved through index optimization.

[0051] The message sending phase utilizes RocketMQ delayed messages to trigger delays. Specifically, this includes: calculating the next retry time when sending fails; obtaining the corresponding RocketMQ delay level based on the number of retries, with eighteen levels from LEVEL_1 to LEVEL_18; the corresponding times for each level are as follows: LEVEL_0 to LEVEL_3 correspond to 0 seconds, 1 second, 5 seconds, and 10 seconds respectively; LEVEL_4 to LEVEL_7 correspond to 30 seconds, 1 minute, 2 minutes, and 3 minutes respectively; LEVEL_8 to LEVEL_11 correspond to 4 minutes, 5 minutes, 6 minutes, and 7 minutes respectively; LEVEL_12 to LEVEL_14 correspond to 8 minutes, 9 minutes, and 10 minutes respectively; and LEVEL_15 to LEVEL_18 correspond to 20 minutes, 30 minutes, 1 hour, and 2 minutes respectively. Messages are automatically delivered upon expiration, triggering a resend.

[0052] Step S203: Assemble the message body.

[0053] like Figure 4As shown, the channel adaptation layer interacts with each channel adapter through a unified interface, and the message assembly process is as follows.

[0054] For notification records that meet the triggering conditions, the system assembles the message body according to the notification type and channel configuration in the notification configuration information, and calls the corresponding sending channel to execute message sending.

[0055] The message assembly process includes: matching the corresponding message template from the template library according to the notification type identifier; determining the target sending channel according to the channel configuration; filling the notification content into the preset placeholders of the message template to generate a message body that conforms to the protocol requirements of the target sending channel.

[0056] The current system uses configurable template management, with template information stored in sub-tables for each channel. SMS templates are stored in the `template_code` field of the `t_notify_sms` table, which references the Alibaba Cloud SMS platform template; WeChat templates are stored in the `template_id` field of the `t_notify_wx` table, which references the WeChat Official Account template ID. Placeholder rules use a JSON data structure. The WeChat template data format is an object containing a `key` field, which in turn contains `value` and `color` fields, for example: `{"key": {"value": "...", "color": "#173177"}}`.

[0057] Supported sending channels include the following five: The first is the HTTP callback channel, using the HTTP or HTTPS POST protocol, with key parameters including url, mediaType, and param. This channel is already implemented. The second is the SMS channel, using the Alibaba Cloud SMS SDK protocol, with key parameters including phone, templateCode, and param. This channel is already implemented. The third is the email channel, using the SMTP protocol, with key parameters including recipient, title, and context. This channel is a reserved interface. The fourth is the WeChat template message channel, using the WeChat Official Account API protocol, with key parameters including openId, templateId, url, data, and miniProgram. This channel is already implemented. The fifth is the DingTalk channel, using the DingTalk robot Webhook protocol, with key parameters including msgtype, text, and link. This channel is a reserved interface.

[0058] The message assembly is described by taking the WeChat template message as an example: the template ID is TPL_ORDER_SHIP; the template content is "Dear {{first.DATA}}, your order {{keyword1.DATA}} has been shipped, the logistics tracking number is {{keyword2.DATA}}, and it is expected to be delivered on {{keyword3.DATA}}." The input parameter data fills each placeholder in JSON format, for example, the value of the first field is Zhang San and the color value is #173177, the value of the keyword1 field is 12345 and the color value is #173177, the value of the keyword2 field is SF12345678 and the color value is #173177, the value of the keyword3 field is 2025-06-10 and the color value is #173177. The assembled message body is directly sent as the data field of the WeChat API.

[0059] Step S204: Send the message and update the status.

[0060] The system invokes the corresponding sending channel to perform message sending, and updates the status of the notification record according to the sending result. If the sending is successful, the notification record is marked as a sending success status, which corresponds to the status code 2 and the enumeration value STATUS_2, meaning that the sending is successful, and the trigger condition is that the channel returns success; if the sending fails, a retry mechanism is triggered.

[0061] As Figure 3 shown, the state machine transition of the notification record includes the following four states and transition paths: the first one is a to-be-sent state, corresponding to status code 0 and enumeration value STATUS_0, meaning initialization, that is, just created and not executed, triggered when the notification record is created; the second one is an unfinished state, corresponding to status code 1 and enumeration value STATUS_1, meaning being sent or failed to be sent and waiting for retry, triggered when a scheduled task triggers sending or a sending failure requires a retry; the third one is a completed state, corresponding to status code 2 and enumeration value STATUS_2, meaning that the sending is successful, triggered when the channel returns success; the fourth one is a failed state, corresponding to status code 3 and enumeration value STATUS_3, meaning that the number of retries is exhausted and the final failure occurs, and the trigger condition is that the number of retries is greater than or equal to the length of the retry policy array and the sending still fails.

[0062] The retry mechanism reads the retry policy configuration from the notification configuration information to obtain the maximum number of retries and the retry interval policy. It determines whether the current number of retries has reached the maximum number of retries. If not, it updates the status of the notification record to a retrying state (status code 1), calculates the next trigger time according to the retry interval policy, updates it, and reinstates the notification record to the scanning range of the timed polling mechanism. If the maximum number of retries has been reached, it marks the notification record as a failed send state (status code 3), triggers an alarm, and retains the notification record for manual intervention.

[0063] Retry supports two strategy types: the first is the default strategy, corresponding to a retry_strategy_cd value of 1, which uses a globally unified system configuration, stored in the t_notify_retry_strategy table with a default_cd value of 1; the second is a custom strategy, corresponding to a retry_strategy_cd value of 2, which uses a configuration specific to each notification, stored in the t_notify_retry_strategy table with a default_cd value of 2, and associated through the notify_id field.

[0064] Retry employs a tiered backoff strategy, configuring the latency level index for each retry via an integer array. A default strategy example is [3,5,9,14], corresponding to RocketMQ latency levels. The retry intervals for the example strategy [3,5,9,14] are 10 seconds, 60 seconds, 300 seconds, and 600 seconds respectively, totaling approximately 10 minutes.

[0065] The maximum number of retries is determined by the length of the `retryStrategy` array, typically ranging from 4 to 5. The example strategy [3,5,9,14] supports 4 retries, plus the initial send, for a total of 5 send opportunities.

[0066] The retry interval is calculated as follows: First, calculate the retryLevel value, which is equal to the element with index "times" in the retryStrategy array, where "times" is counted starting from 0, corresponding to the first retry; then calculate the delaySecond value, which is equal to the element with index "retryLevel" in the ROCKET_MQ_DELAY_LEVEL_SECOND array; finally, calculate the nextNotifyTime value, which is equal to the sum of the currentTime value and the delaySecond value.

[0067] The failure notification handling mechanism is as follows: The judgment condition is that the number of retries is greater than or equal to the length of the retry policy array and the transmission still fails; the status is marked by updating the `notify_status_cd` field to `STATUS_3`, i.e., status code 3; the alarm mechanism records the failure notification details in the log and reserves a DingTalk alarm interface, which is configured via `chatId`; subsequent processing involves retaining the failure notification in the `t_notify` table, supporting manual resending via the `resendMsg` interface. Currently, an independent dead-letter queue is not implemented; failure notifications can be queried and processed by business systems through the status query interface.

[0068] IV. End-to-End Status Tracking The method also includes end-to-end state tracing. During the access request phase, the system generates and records a tracing identifier, and binds the tracing identifier to the notification identifier. This binding relationship is implemented through log context (MDC) or tags in a distributed tracing system, enabling the aggregation and retrieval of end-to-end logs under the same notification identifier.

[0069] During the sending execution phase, each processing node records a status change log. Each processing node includes a timed acquisition node, a delay judgment node, a message assembly node, a channel sending node, and a status update node. The status change log includes the tracking identifier, current status, timestamp, and node information.

[0070] The state change log is stored in the t_notify_statement table and also output to a file via logback, supporting retrieval by the ELK log platform.

[0071] A notification status query interface is provided based on the tracking identifier, allowing requesters to query the end-to-end processing status of notifications in real time. The status query interface uses the HTTP GET protocol, and the response format includes a code field, a message field, and a data field. The data field contains the notifyId, serialNumber, notifyMethod, notifyStatus, notifyStatusDesc, times, lastNotifyTime, createTime, and statements fields. The statements field is an array type, with elements containing notifyTimes and createTime fields.

[0072] The trace identifier generation rules are as follows: The technology is based on the Spring Cloud Sleuth distributed tracing framework; the traceId format is a hexadecimal string, such as a0b1c2d3e4f56789; it is automatically generated when NotifyCenterConsumer consumes messages and can be obtained through the tracer.currentSpan().context().traceIdString() method.

[0073] V. Beneficial Effects The beneficial effects of this invention include: Asynchronous decoupling improves interface performance: By using persistence and immediate return notification mechanisms during the request access phase, the business system does not need to synchronously wait for the channel to send the result, eliminating the impact of synchronous blocking on the performance of the business interface. In the synchronous mode, the business interface needs to wait for the channel response, with an average response time of approximately 500 to 2000 milliseconds; in the asynchronous mode, only the database insertion operation needs to be completed, and the average response time can be reduced to approximately 50 milliseconds, a significant reduction in response time.

[0074] Unified scheduling reduces architectural complexity: A timed polling mechanism unifies the scheduling of instant notifications, delayed notifications, and retry notifications, eliminating the need to maintain multiple independent scheduling systems or delayed queues. This simplifies the system architecture and improves the reusability of scheduling resources. Compared to independent delayed queue solutions, it saves the need for separate delayed queue services such as Redis ZSet or RabbitMQ delayed queues, and eliminates the need to allocate separate database connection pools or deploy additional delayed queue service nodes.

[0075] Reliable retries improve arrival rate: Through configurable retry policies and a timed polling multiplexing mechanism, automatic retries are performed according to the policy when transmission fails. After reaching the maximum number of retries, failure records are retained and alarms are triggered. Without a retry mechanism, the arrival rate is approximately 95% to 98%, affected by network jitter; with the introduction of a retry mechanism, it can reach over 99%, and 4 retries can cover the vast majority of temporary faults, with an improvement of approximately 2 to 3 percentage points.

[0076] End-to-end traceability: By using trace identifiers throughout the entire process of request access and execution, real-time querying of notification status and rapid problem localization are achieved. Without end-to-end tracing, manual investigation of multiple system logs is required, taking an average of more than 30 minutes; with end-to-end tracing, the traceId can be used to quickly locate the problem, reducing the average time to less than 5 minutes, resulting in a significant reduction in investigation time.

[0077] 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. A unified scheduling and sending method for notification messages, characterized in that, It includes a request access phase and a send execution phase. The request access phase achieves asynchronous decoupling between external notification requests and message sending execution, while the send execution phase achieves batch scheduling and reliable sending based on timed polling. The access request phase includes: S1, Receive an external notification request and obtain the notification configuration information corresponding to the external notification request; S2, Generate and save a notification record based on the notification configuration information and the content of the external notification request, and return a notification identifier to the requester. The notification identifier is used for subsequent querying of the notification status. The sending execution phase includes: S3 uses a timed polling mechanism to scan the notification database at a preset period to obtain the notification records to be sent in the current period; S4. For each acquired notification record to be sent, determine whether its notification type is an instant notification or a delayed notification based on the notification configuration information, and verify whether the current time meets the preset triggering condition of the delayed notification. S5, for notification records that meet the triggering conditions, assemble the message body according to the notification type and channel configuration in the notification configuration information, and call the corresponding sending channel to execute message sending; S6. Update the status of the notification record according to the sending result. If the sending fails, trigger the retry mechanism, re-mark the notification record as pending sending and update the next trigger time; if the sending is successful, mark it as successfully sent.

2. The unified scheduling and sending method for notification messages according to claim 1, characterized in that, In step S1, receiving an external notification request includes: External notification requests are received through a unified access interface. The external notification request includes the notification content, the recipient identifier, and the notification type identifier. The notification configuration information is obtained by querying the preset notification configuration library according to the notification type identifier. The notification configuration information includes channel configuration, template configuration, delay policy configuration and retry policy configuration.

3. The unified scheduling and sending method for notification messages according to claim 1, characterized in that, In step S2, generating and saving the notification record includes: The notification content, recipient identifier, notification type identifier, and notification configuration information of the external notification request are associated and stored to generate a globally unique notification identifier; The initial state of the notification record is marked as pending delivery.

4. The unified scheduling and sending method for notification messages according to claim 1, characterized in that, In step S3, the timed polling mechanism includes: A scheduled task is started at a preset cycle to scan the notification database for notification records that are in the pending send state and whose next trigger time is less than or equal to the current time. Retrieve notification records that meet the conditions in batches, and temporarily lock the notification records in the batches to prevent concurrent duplicate sending.

5. The unified scheduling and sending method for notification messages according to claim 1, characterized in that, In step S4, determining the notification type and verifying the triggering conditions includes: If no delay policy is configured in the notification configuration information, it is determined to be an immediate notification, and step S5 is executed directly; If a delay policy is configured in the notification configuration information, it is determined to be a delayed notification. The current system time is checked to see if the preset trigger time configured by the delay policy has been reached. Step S5 is executed only if the preset trigger time has been reached.

6. The unified scheduling and sending method for notification messages according to claim 1, characterized in that, In step S5, the assembled message body includes: Match the corresponding message template from the template library based on the notification type identifier; Determine the target sending channel based on the channel configuration; The notification content is filled into the preset placeholders of the message template to generate a message body that conforms to the requirements of the target sending channel protocol.

7. The unified scheduling and sending method for notification messages according to claim 1, characterized in that, In step S6, the retry mechanism includes: If the sending fails, read the retry policy configuration in the notification configuration information to obtain the maximum number of retries and the retry interval policy; Determine whether the current number of retries has reached the maximum number of retries. If not, update the status of the notification record to the retrying state, calculate the next trigger time according to the retry interval policy and update it, and reinstate the notification record into the scanning range of the timed polling mechanism. If the maximum number of retries has been reached, the notification record is marked as a failed transmission, an alarm is triggered, and the notification record is retained for manual intervention.

8. The unified scheduling and sending method for notification messages according to claim 1, characterized in that, The method also includes end-to-end state tracking: During the access request phase, a tracking identifier is generated and recorded, and the tracking identifier is bound to the notification identifier; Each processing node in the sending execution phase records a status change log, which includes the tracking identifier, current status, timestamp, and node information. Based on the tracking identifier, a notification status query interface is provided, allowing the requester to query the end-to-end processing status of the notification in real time.

9. A unified scheduling and sending system for notification messages, characterized in that, include: A unified access module is used to perform the request access phase as described in any one of claims 1-8; The timed scheduling module is used to perform timed polling in the sending execution phase as described in any one of claims 1-8; The message assembly module is used to perform message body assembly as described in any one of claims 1-8; The channel sending module is used to call various sending channels to execute message sending; The state management module is used to execute the state update and retry mechanism as described in any one of claims 1-8; The configuration management module is used to store and manage the notification configuration information.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-8.

Images