Message notification method and device, equipment and storage medium

Abstract

The invention discloses a message notification method, device and equipment and a storage medium, and the method comprises the steps: receiving a notification request from an upstream system, verifying the notification request, and obtaining a verification result; if the verification result is that the verification is passed, generating a corresponding notification task based on the notification request, and generating a corresponding task identifier for the notification task; processing the notification task based on the notification mode identifier to generate executable notification data; and scheduling the executable notification data to a corresponding execution unit based on a preset load scheduling strategy to perform notification issuing, and updating state information corresponding to the task identifier according to execution feedback of the execution unit. The notification task is processed based on the notification mode identifier, then the executable notification data is scheduled to the corresponding execution unit based on the preset load scheduling strategy to perform notification issuing, and finally the state information is updated according to the execution feedback, so that the flexibility, the timeliness and the reliability of the message notification system are improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a message notification method, apparatus, device, and storage medium. Background Technology

[0002] In modern software systems, especially in critical business areas such as operations and maintenance monitoring, financial transactions, and emergency alarms, efficiently, accurately, and reliably delivering notification messages to target users is a core aspect of ensuring business continuity and system stability. A complete message notification system typically needs to support multiple notification methods, such as telephone, SMS, and in-app messages, to meet the requirements for reach and timeliness in different scenarios.

[0003] Currently, common message notification systems are custom-developed for specific notification methods (such as SMS only or email only), with each channel operating independently, forming a "siloed" architecture. When a business needs to integrate a new notification method, a large amount of repetitive development and system integration work is required. This tightly coupled design leads to poor system scalability, increases system complexity and maintenance costs, and fails to achieve the convenient experience of "one-time integration, multiple methods coexisting." Secondly, in scenarios with peak traffic or sudden alarms, massive notification requests surge in instantly. Traditional simple polling or random task allocation scheduling strategies are difficult to achieve load balancing, easily leading to overload of some processing nodes, resulting in message backlog, processing delays, and even system collapse. The lack of an intelligent, system load-aware dynamic scheduling mechanism makes the system unable to effectively cope with large traffic surges, making it difficult to guarantee the timely delivery of critical messages. In addition, network fluctuations and downstream service jitter may cause notification sending failures, but the status feedback after the notification is sent (such as whether the user has answered or read it) is often not effectively captured and recorded, making it impossible for the entire notification process to form a closed loop, thus compromising the success rate of notifications and affecting system reliability.

[0004] Therefore, there is an urgent need for a message notification method that can improve the flexibility, timeliness, and reliability of message notification systems. Summary of the Invention

[0005] The main objective of this invention is to provide a message notification method, apparatus, device, and storage medium, which aims to solve the technical problems of poor flexibility, timeliness, and reliability of existing message notification systems.

[0006] To achieve the above objectives, the present invention provides a message notification method, the method comprising the following steps: Receive a notification request from the upstream system, verify the notification request, and obtain a verification result. The notification request includes notification content, notification method identifier, and target user identifier. If the verification result is successful, a corresponding notification task is generated based on the notification request, and a corresponding task identifier is generated for the notification task. The notification task is processed based on the notification method identifier to generate executable notification data; Based on a preset load scheduling strategy, the executable notification data is scheduled to the corresponding execution unit for notification delivery, and the status information corresponding to the task identifier is updated according to the execution feedback of the execution unit.

[0007] Optionally, the step of processing the notification task based on the notification method identifier to generate executable notification data includes: Based on the notification method identifier, the corresponding target processing module is invoked to adapt the notification content and generate intermediate notification data; The intermediate notification data is associated with the task identifier and stored in the task database; Based on the task scheduling rules, the intermediate notification data that is in an executable state is loaded from the task database to generate executable notification data.

[0008] Optionally, the step of calling the corresponding target processing module to adapt the notification content and generate intermediate notification data according to the notification method identifier includes: When the notification method identifier corresponds to a voice notification, the speech synthesis module is used as the target processing module. The speech synthesis module is invoked to generate a speech file based on the notification content; The audio file is uploaded to the file server, and a flow control file is generated. The flow control file is used as intermediate notification data. The flow control file includes the access address and playback control logic of the audio file. Accordingly, the step of calling the corresponding target processing module to adapt the notification content and generate intermediate notification data based on the notification method identifier further includes: When the notification method identifier corresponds to a text notification, the content formatting module is used as the target processing module. The content formatting module is invoked to process the notification content according to the template and protocol specifications corresponding to the notification method identifier, thereby generating a standardized message body; The standardized message body is used as intermediate notification data.

[0009] Optionally, the step of scheduling the executable notification data to the corresponding execution unit for notification delivery based on a preset load scheduling strategy includes: Based on the task attributes of the notification task, the executable notification data is distributed to the corresponding secondary scheduler through the global scheduler. The task attributes include priority. The real-time operating metrics of multiple task execution instances managed by the secondary scheduler are obtained, and the target execution instance is determined from the multiple task execution instances by combining the candidate instance list generated based on historical data analysis. The executable notification data is scheduled to the target execution instance, which then calls an external communication interface to perform the notification delivery operation.

[0010] Optionally, the step of distributing the executable notification data to the corresponding secondary scheduler through the global scheduler based on the task attributes of the notification task includes: The priority of the notification task is determined based on its task attributes, and the current resource load status of the system is determined by the global scheduler. If the resource load status is a resource shortage state, the executable notification data is distributed to the secondary scheduler whose scheduling level label matches the priority according to the strong consistency scheduling policy; If the resource load status is sufficient, the executable notification data is distributed to a secondary scheduler with a scheduling level label not lower than the priority, according to the non-strong consistency scheduling policy.

[0011] Optionally, the step of obtaining real-time operating metrics of multiple task execution instances managed by the secondary scheduler, and determining the target execution instance from the multiple task execution instances by combining them with a candidate instance list generated based on historical data analysis, includes: Obtain real-time running metrics for multiple task execution instances managed by the secondary scheduler. The real-time running metrics include at least one of the following: the number of tasks in each task execution instance, the average execution time of tasks in each task execution instance, and the average waiting time of tasks in each task execution instance. Collect load data and task execution data of the multiple task execution instances within a preset historical time period; The load data and the task execution data are input into a large language model for prediction, and a candidate instance list is selected from the multiple task execution instances based on the prediction results; The task execution instances in the candidate instance list are quantitatively scored based on the real-time operation metrics, and the target execution instance is determined from the candidate instance list based on the scoring results.

[0012] Optionally, the step of updating the status information corresponding to the task identifier based on the execution feedback of the execution unit includes: Obtain the execution result regarding the distribution of the executable notification data, as fed back by the execution unit; If the execution result indicates that the delivery failed, the notification task corresponding to the task identifier is set to the retry state, and the notification task is added to the retry queue. Retry the notification tasks in the retry queue, obtain the corresponding execution results, and accumulate the number of retry attempts. When the number of retry attempts reaches the retry threshold or the execution result indicates successful delivery, the status information corresponding to the task identifier is updated.

[0013] Furthermore, to achieve the above objectives, the present invention also proposes a message notification device, the device comprising: The request receiving module is used to receive notification requests from the upstream system, verify the notification requests, and obtain verification results. The notification request includes notification content, notification method identifier, and target user identifier. The task generation module is used to generate a corresponding notification task based on the notification request if the verification result is successful, and to generate a corresponding task identifier for the notification task. The task processing module is used to process the notification task based on the notification method identifier and generate executable notification data; The notification delivery module is used to schedule the executable notification data to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and update the status information corresponding to the task identifier according to the execution feedback of the execution unit.

[0014] Furthermore, to achieve the above objectives, the present invention also proposes a message notification device, the device comprising: a memory, a processor, and a message notification program stored in the memory and executable on the processor, the message notification program being configured to implement the steps of the message notification method as described above.

[0015] In addition, to achieve the above objectives, the present invention also proposes a storage medium storing a message notification program, which, when executed by a processor, implements the steps of the message notification method as described above.

[0016] This invention discloses a method for receiving and verifying notification requests from an upstream system, obtaining a verification result, whereby the notification request includes notification content, a notification method identifier, and a target user identifier. If the verification result is successful, a corresponding notification task is generated based on the notification request, and a corresponding task identifier is generated for the notification task. The notification task is processed based on the notification method identifier to generate executable notification data. The executable notification data is scheduled to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and the status information corresponding to the task identifier is updated based on the execution feedback from the execution unit. Because this invention processes the notification task based on the notification method identifier to generate executable notification data, then schedules the executable notification data to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and finally updates the status information based on the execution feedback, compared to existing technologies, this invention improves the flexibility, timeliness, and reliability of the message notification system. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the first embodiment of the message notification method of the present invention; Figure 2 This is a diagram of the message notification system architecture in the message notification method of the present invention; Figure 3 This is a flowchart illustrating the second embodiment of the message notification method of the present invention; Figure 4 This is a flowchart illustrating the third embodiment of the message notification method of the present invention; Figure 5 This is a schematic diagram of the multi-level scheduling mechanism in the message notification method of the present invention; Figure 6 This is a schematic diagram of the two-level scheduler mechanism in the message notification method of the present invention; Figure 7 This is a structural block diagram of the first embodiment of the message notification device of the present invention; Figure 8 This is a schematic diagram of the structure of a message notification device in the hardware operating environment involved in the embodiments of the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0020] This invention provides a message notification method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the message notification method of the present invention.

[0021] In this embodiment, the message notification method includes steps S10 to S40: Step S10: Receive a notification request from the upstream system, verify the notification request, and obtain a verification result. The notification request includes notification content, notification method identifier, and target user identifier.

[0022] It should be noted that the executing entity in this embodiment can be a computer server device with data processing, network communication, and program execution functions applied in a message notification processing scenario, such as a server, tablet computer, or personal computer, or an electronic device capable of performing the above functions (such as a message notification device). The following uses a message notification system (hereinafter referred to as the system) as an example to illustrate this embodiment and the following embodiments.

[0023] For example, refer to Figure 2 , Figure 2This is a diagram illustrating the message notification system architecture in the message notification method of this invention. The message notification system adopts a layered architecture design. At the scenario layer, the system generates notification requests in response to business events such as system changes, anomaly alarms, message notifications, approval processes, and activity invitations. The unified gateway at the access layer is responsible for receiving and verifying notification requests from upstream scenarios. The application layer provides interactive interfaces for task assignment, result querying, audit logs, data analysis, and lightweight telephone notifications. The core processing resides in the service layer. The task module (including task creation, policy configuration, result review, and controllable retry submodules), voice module (including TTS synthesis, line management, ASR recognition, and organization management submodules), messaging module (including SMS, application, enterprise WeChat messages, and result pushback submodules), scheduling module (including task allocation and load awareness submodules), and data module (including notification logging, data aggregation, audit logs, and task execution details submodules) work together to complete the entire chain of processing from notification request to executable task. In addition, each module in the service layer can be horizontally scaled based on factors such as system operating status, system pressure, and performance bottlenecks to cope with the growth of upstream requests. The close collaboration between the service layer and external dependencies (including unified authentication, message center, and personnel query) together constitutes a complete closed loop from request verification and task execution to message delivery. The data layer provides support for task data storage, status updates, asynchronous processing, and caching through various databases (such as TDengine, Redis, ES, and COS) and message queues (such as MQ and Kafka). The communication layer, as the foundational capability layer, primarily includes voice communication capabilities and the core logic for dedicated line gateway interaction. Businesses can forward notification messages such as calls and text messages to the corresponding operator gateways or service gateways based on their own business characteristics and requirements. Simultaneously, businesses can choose voice robot combinations to synthesize voice notifications using generic or customized voice tones. Components in the communication layer, such as voice robots, FreeSwitch, external dedicated lines, and branch dedicated lines, are the specific implementations of the execution units, responsible for the final notification delivery. The algorithm layer provides capabilities for intelligent processing such as TTS, ASR, model service platforms, model training platforms, and WriteGPT, including speech synthesis, content generation, and load prediction. The overall system operation status is monitored through the core monitoring and self-healing platform on the right, and high availability is ensured through the operation and maintenance handling platform.

[0024] It should be understood that a notification request can refer to a standardized, structured call instruction or data packet initiated by an upstream system (such as an operation and maintenance monitoring system, an order system, etc.) when it needs to send a notification. It encapsulates all the metadata and information required for a notification task.

[0025] It should be noted that verifying notification requests is to ensure system security, stability, and data consistency. Notification request verification may include identity and permission checks, parameter and legality checks, and business logic verification.

[0026] Understandably, the notification content can refer to the information ultimately delivered to the user; the notification method identifier can be identifying information used to specify the notification method; and the target user identifier can be information used to uniquely identify the recipient, ensuring that the message can be accurately routed to a specific individual or device. For example, in the context of SMS, this would be receiving a mobile phone number.

[0027] Step S20: If the verification result is successful, then generate a corresponding notification task based on the notification request, and generate a corresponding task identifier for the notification task.

[0028] It should be understood that a notification task can refer to an internal, persistent unit of work created by the system based on a notification request after successful verification. The task identifier is a globally unique string or numeric sequence generated by the system for each notification task, ensuring that any notification task in the system can be uniquely identified.

[0029] Understandably, if the verification result is that the verification fails, the system will not create a notification task and will immediately interrupt the processing flow. At the same time, the notification request corresponding to the verification failure can be recorded in the system's security log or audit log for subsequent analysis and auditing.

[0030] To achieve resource isolation at the user level and fine-grained scheduling at the task level, this embodiment also provides multiple dimensions of conditions to meet the refined task scheduling requirements of business services. These are mainly divided into two dimensions: 1. User Dimension: User information (unique identifier) ​​is used to uniquely distinguish users through information such as the organization, account, and integration method to which the business service belongs. Task execution is completely isolated between different users, ensuring that task execution does not interfere with each other. 2. Task Dimension: Fine-grained scheduling capabilities are provided to users based on the parsing capabilities of notification task type, priority, and reach type.

[0031] In a specific implementation, after the step of generating the corresponding notification task based on the notification request, the process may include: parsing the notification request to obtain user-level identification information and task-level attribute information; isolating the notification task based on the user-level identification information; and determining the priority and scheduling queue of the notification task based on the task-level attribute information.

[0032] Step S30: Process the notification task based on the notification method identifier to generate executable notification data.

[0033] It should be understood that processing notification tasks based on notification method identifiers means that the system routes notification tasks to different dedicated processing pipelines according to the notification method identifiers and adapts the notification content to the format required by the specific channel.

[0034] For example, if the notification method identifier corresponds to a voice notification, the system's speech synthesis module is used to process the notification task and generate executable notification data; if the notification method identifier corresponds to a text notification, the system's content formatting module is used to process the notification task and generate executable notification data.

[0035] Furthermore, to enhance user experience, in voice call notification scenarios (i.e., notifications delivered via voice), a library of general or customized voice tones is provided based on TTS and ASR capabilities. Business scenarios can select appropriate voice tones for voice content synthesis according to their requirements, improving the human-likeness and intelligence of the broadcast content. In addition, for the auditing of voice broadcast content, a large language model can be introduced for quality inspection and screening, improving inspection efficiency and accuracy. In text-based broadcast scenarios (i.e., notifications delivered via text), businesses can specify the Prompt and input method, leveraging the capabilities of the large language model to automatically generate broadcast content, achieving customized broadcast content and helping businesses achieve a personalized experience for each user.

[0036] Step S40: Based on the preset load scheduling strategy, schedule the executable notification data to the corresponding execution unit for notification delivery, and update the status information corresponding to the task identifier according to the execution feedback of the execution unit.

[0037] It should be understood that a preset load balancing strategy refers to a predefined intelligent decision-making rule used by the system to dynamically select the most suitable execution unit from multiple available execution units to execute the current task. By using a preset load balancing strategy, the resource utilization and throughput of the entire cluster can be maximized while ensuring the timeliness of high-priority tasks. An execution unit can be an independent component or service instance in the system specifically responsible for executing the final message delivery action.

[0038] It's important to note that when updating the task execution status (i.e., updating the status information corresponding to the task identifier), in addition to updating based on the task's execution status, the system also collects the notification provider's response information to refine the status, facilitating the creation of a complete, closed-loop process for upper-layer business applications. Taking voice notification messages as an example, when a voice notification message is played on a user's phone, the user may respond with different levels of understanding, such as "aware," "ignore," or "inconvenient to handle." The system then updates the task status to multiple sub-levels based on the user's response, such as "handled," "ignored," or "not responding." When upper-layer business applications query the task status, they can determine whether to terminate the notification process or initiate a notification process for new users based on their own business logic, achieving a closed-loop notification process in key scenarios and confirming that each notification message has been responded to.

[0039] To improve the final success rate and system reliability of notification task delivery, in a specific implementation, the execution result of the executable notification data delivery fed back by the execution unit can be obtained; if the execution result indicates delivery failure, the notification task corresponding to the task identifier is set to a retry state and the notification task is added to the retry queue; the notification tasks in the retry queue are retried for delivery, the corresponding execution result is obtained, and the number of retry delivery is accumulated; when the number of retry delivery reaches the retry threshold or the execution result indicates successful delivery, the status information corresponding to the task identifier is updated.

[0040] It's worth noting that during task execution, frequent modifications to task status and other information, along with frequent database writes, slow down task processing. Therefore, a local cache can be introduced during task execution: modifications to task data are first written to the local cache, and only after the task is completed are the cached data refreshed to the database. Since reading from and writing to the cache is much faster than reading from and writing to the database, this improves task processing speed.

[0041] It should be noted that by adding the retry queue and accumulating the number of retry attempts, the "avalanche effect" caused by a sudden large-scale failure and retry is avoided, making the retry behavior controllable and orderly.

[0042] It should be understood that a retry queue can refer to a logically or physically dedicated data storage area or list for storing notification tasks waiting to be retried. The status information corresponding to the task identifier can refer to data associated with each unique task identifier, describing the current stage of the notification task.

[0043] Understandably, the current stage of a notification task can include waiting to be processed, processing, retrying, successful delivery, eventual failure, and user confirmation.

[0044] It's worth noting that, to address various retryable failure scenarios such as network fluctuations, downstream service jitter, and system overload, this embodiment incorporates retry mechanisms at multiple stages to maximize task success rates. First, during the task request phase, if a failure occurs, the upstream business system can implement a limited-retry mechanism, and the gateway will apply rate limiting to the business side to prevent a large number of retries in a short period from overwhelming the entire service. Furthermore, the task microservice performs deduplication checks when adding task requests to the processing queue, ensuring that notification messages are executed at least once. Second, during the task synthesis phase, when the task module encounters non-interruptible failure scenarios such as failed calls to dependent services, it will attempt to resynthesize the task after a period of time. If it still fails after a limited number of retries, the task is considered a failure, and its status is updated to the final state (i.e., ultimately failed). Finally, during the task execution phase, if task execution fails, the failed tasks are placed in a retry queue for a limited number of retries. When the maximum number of retries (i.e., the retry threshold) is reached, the task status is updated to the final state.

[0045] To achieve end-to-end traceability and post-event auditing capabilities, after step S40, the system may further include: collecting end-to-end flow data of the notification task from generation to status information update, wherein the end-to-end flow data includes at least the task identifier, the notification method identifier, the requester identifier, the target user identifier, the task creation time, the task start execution time, the task execution completion time, the execution result, and the notification content; and persistently storing the flow data in the audit log database.

[0046] This embodiment discloses receiving a notification request from an upstream system, verifying the notification request, and obtaining a verification result. The notification request includes notification content, a notification method identifier, and a target user identifier. If the verification result is successful, a corresponding notification task is generated based on the notification request, and a corresponding task identifier is generated for the notification task. The notification task is processed based on the notification method identifier to generate executable notification data. The executable notification data is scheduled to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and the status information corresponding to the task identifier is updated according to the execution feedback of the execution unit. Because this embodiment processes the notification task based on the notification method identifier to generate executable notification data, then schedules the executable notification data to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and finally updates the status information according to the execution feedback, compared with the prior art, this embodiment improves the flexibility, timeliness, and reliability of the message notification system.

[0047] refer to Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the message notification method of the present invention.

[0048] Based on the first embodiment described above, in this embodiment, step S30 includes steps S301 to S303: Step S301: Based on the notification method identifier, call the corresponding target processing module to adapt the notification content and generate intermediate notification data.

[0049] Step S302: Associate the intermediate notification data with the task identifier and store it in the task database.

[0050] Step S303: Based on the task scheduling rules, load the intermediate notification data that is in an executable state from the task database to generate executable notification data.

[0051] It should be understood that different notification methods (such as voice calls, SMS, in-app push notifications, and emails) have fundamental differences in their technical implementation (for example, semantic notifications require synthesized voice files; SMS messages need to conform to the carrier's format).

[0052] It's important to note that the purpose of adaptation processing is to transform the notification content into executable instructions and data specific to a particular notification channel. Without adaptation processing, upstream business systems would need to understand and handle the complex details of all downstream channels, resulting in extremely high system coupling and making the system difficult to expand and maintain.

[0053] It should be explained that intermediate notification data can refer to task data that has completed channel-specific adaptation processing but has not yet been scheduled for execution. Executable notification data can refer to task data instances loaded from the task database that have been allocated specific execution resources (such as a worker thread) by the scheduler and are about to be or are currently being processed.

[0054] For example, when the notification method identifier corresponds to a voice notification, the speech synthesis module is used as the target processing module; the speech synthesis module is invoked to generate a voice file based on the notification content; the voice file is uploaded to a file server and a flow control file is generated, which is used as intermediate notification data. The flow control file includes the access address and playback control logic of the voice file.

[0055] For example, when the notification method identifier corresponds to a text notification, the content formatting module is used as the target processing module; the content formatting module is called to process the notification content according to the template and protocol specification corresponding to the notification method identifier, and a standardized message body is generated; the standardized message body is used as intermediate notification data.

[0056] Understandably, task scheduling rules can refer to the set of strategies and logic that the scheduler (or scheduling module) uses to make decisions. Its goal is to optimize resource utilization, ensure system SLAs (Service Level Agreements), and meet various business requirements in complex environments with multiple tasks and execution resources.

[0057] It should be understood that this embodiment associates intermediate notification data with task identifiers for storage, ensuring that task status is traceable and recoverable. Regularized scheduling makes task allocation controllable and predictable, facilitating system monitoring and problem localization, and improving system reliability and maintainability. Furthermore, this embodiment decouples content adaptation from task execution, generating and persistently storing intermediate notification data, enabling asynchronous execution of content conversion (such as speech synthesis) and avoiding blocking of request links. Simultaneously, rule-based scheduling of executable notification data facilitates batch loading and concurrent execution, increasing overall system throughput and thus improving system data processing efficiency.

[0058] This embodiment discloses a method for adapting notification content by calling the corresponding target processing module based on the notification method identifier, generating intermediate notification data; associating the intermediate notification data with the task identifier and storing it in a task database; and loading the intermediate notification data in an executable state from the task database based on task scheduling rules to generate executable notification data. Because this embodiment adapts the notification content by calling the corresponding target processing module based on the notification method identifier, associates the generated intermediate notification data with the task identifier and stores it in the task database, and then loads the intermediate notification data in an executable state from the task database based on task scheduling rules to generate executable notification data, compared to existing technologies, this embodiment improves system reliability and data processing efficiency.

[0059] refer to Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the message notification method of the present invention.

[0060] Based on the above embodiments, in this embodiment, step S40 includes steps S401 to S403: Step S401: Based on the task attributes of the notification task, the executable notification data is distributed to the corresponding secondary scheduler through the global scheduler. The task attributes include priority.

[0061] Step S402: Obtain the real-time operating metrics of multiple task execution instances managed by the secondary scheduler, and determine the target execution instance from the multiple task execution instances by combining the candidate instance list generated based on historical data analysis.

[0062] Step S403: The executable notification data is scheduled to the target execution instance, and the target execution instance calls the external communication interface to perform the notification delivery operation.

[0063] It's important to clarify that the global scheduler can refer to the primary scheduling hub in the system, responsible for receiving all pending executable notification data and making the initial routing decision. The secondary scheduler is a local scheduler belonging to a specific scheduling pool or resource group. There are multiple secondary schedulers in the system, each managing a specific cluster of task execution instances. A secondary scheduler can receive tasks assigned by the global scheduler and select the optimal task execution instance from its managed cluster for execution.

[0064] It should be noted that the task load is distributed across multiple secondary schedulers through the macro-distribution of the global scheduler; then, the micro-optimization of the secondary schedulers selects the most suitable execution instance for each task. This collaborative work avoids overload or idle resources on a single node, thereby maximizing the processing capacity of the entire cluster and improving system throughput and resource utilization.

[0065] In addition, this embodiment obtains the real-time operating metrics of multiple task execution instances managed by the secondary scheduler, and combines them with a candidate instance list generated based on historical data analysis to determine the target execution instance from multiple task execution instances, thereby achieving adaptive load balancing and improving the overall stability of the system.

[0066] It should be understood that a task execution instance, or execution unit, can refer to an independent, runnable software service unit that is responsible for the specific execution of the atomic operation of issuing a notification (such as making a phone call or sending a text message). It is the smallest granular object for the system to perform load allocation and management.

[0067] In a specific implementation, the priority of the notification task can be determined based on its task attributes, and the current resource load status of the system can be determined through a global scheduler. If the resource load status is resource-scarce, the executable notification data is distributed to a secondary scheduler whose scheduling level label matches the priority according to a strong consistency scheduling policy. If the resource load status is resource-sufficient, the executable notification data is distributed to a secondary scheduler whose scheduling level label is not lower than the priority according to a non-strong consistency scheduling policy.

[0068] For example, refer to Figure 5 , Figure 5This diagram illustrates the multi-level scheduling mechanism in the message notification method of this invention. As shown, the entire system has a global scheduler (singleton), which is responsible for accepting registrations from secondary schedulers and distributing global tasks. To ensure efficiency, global task distribution only supports two strategies: balanced distribution and proportional distribution. All secondary schedulers are bound to a priority tag (i.e., a scheduling level tag) upon registration. When resource contention or bottlenecks occur, strong consistency logic (i.e., a strong consistency scheduling strategy) can be enabled, and tasks of a relevant priority level will only be scheduled to the corresponding secondary scheduler. When resources are not limited, non-strong consistency logic (i.e., a non-strong consistency scheduling strategy) can be used, and tasks of a relevant priority level can be scheduled to secondary schedulers of the same or higher priority. For example, low-priority tasks can be scheduled to high, medium, and low-priority secondary task schedulers. Medium-priority tasks can be scheduled to high and medium-priority secondary schedulers. (Note: In actual system deployment, resources are tilted towards high-priority tasks; for example, the deployment ratio can be high:medium:low = 5:3:2). Therefore, when system resources are sufficient, a non-strongly consistent scheduling strategy can be used to maximize cluster resource utilization. When system resources are scarce, a strongly consistent scheduling strategy is used to ensure the priority execution of high-priority tasks. Furthermore, the global scheduler provides contingency plans for failures. If a secondary scheduler fails or becomes unavailable, it can be isolated to prevent impact on subsequent tasks.

[0069] It should be explained that real-time performance metrics refer to the status data reflecting the load and performance of a task execution instance at the current moment or within the most recent short period of time. These metrics are dynamically changing and collected instantaneously. Historical data refers to the load data and task execution data generated by a task execution instance within a preset historical time period (such as 15 minutes).

[0070] It should be understood that the candidate instance list can refer to a recommended list generated by the secondary scheduler through analysis of historical data (typically using machine learning or large language models for prediction). This recommended list includes task execution instances within its jurisdiction that are predicted to have better overall performance in the near future.

[0071] In a specific implementation, real-time operating metrics of multiple task execution instances managed by the secondary scheduler can be obtained. These real-time operating metrics include at least one of the following: the number of tasks in each task execution instance, the average execution time of tasks in each task execution instance, and the average waiting time of tasks in each task execution instance. Load data and task execution data of the multiple task execution instances are collected within a preset historical time period. The load data and task execution data are input into a large language model for prediction, and a candidate instance list is selected from the multiple task execution instances based on the prediction results. Each task execution instance in the candidate instance list is quantitatively scored according to the real-time operating metrics, and a target execution instance is determined from the candidate instance list based on the scoring results.

[0072] For example, refer to Figure 6 , Figure 6 This diagram illustrates the secondary scheduler mechanism in the message notification method of this invention. As shown, the secondary scheduler (i.e., the task scheduler in the figure) employs a Large Language Model (LLM) + real-time rule matching approach. Each secondary scheduler is responsible for scheduling tasks in n task groups. Each task group contains n task execution instances responsible for executing specific tasks. Each task group maintains a set of metadata on the scheduler side for real-time decision-making regarding the load status of each task execution instance. Simultaneously, the task execution status and machine load metrics of each instance within each task group are collected, cleaned, and input into the LLM, which provides a list of candidate task groups (i.e., candidate instances) within a specified historical time period. The secondary scheduler combines the candidate task groups provided by the LLM with the real-time meta-information (i.e., real-time performance metrics) of the current task group to determine the appropriate task instance (i.e., the target execution instance) for task scheduling and allocation. Through offline analysis of the LLM and selection based on real-time meta-information, it attempts to find the optimal balance between local and global optima.

[0073] It should be explained that real-time meta information, i.e. real-time operational metrics, may include the number of instances (the number of executable task instances contained in the current task group), the number of tasks in each instance (the number of tasks currently backlogged in each instance, i.e., the number of tasks in each task execution instance), the total duration of voice tasks in each instance (the total duration of all voice tasks currently pending execution in each instance), the voice duration of a single task in each instance (total voice duration or number of voice tasks), the average execution time of tasks in each instance (the average execution time of tasks in each task execution instance, such as the time from the start of voice task retrieval to the end of task execution), and the average waiting time of tasks in each instance (the average waiting time of tasks in each task execution instance, such as the average latency from the scheduling of a voice task to its retrieval for execution).

[0074] In practical implementation, load data and task execution data of each task execution instance in a task group over a past period can be cleaned and organized into indicator data, which is then input into a large language model for offline analysis. The model predicts and filters out the top-performing task groups (i.e., a candidate instance list) for priority selection in subsequent task scheduling. This embodiment currently uses a configuration that collects indicator data from the past 15 minutes, with a collection point of 30 seconds. After cleaning the relevant indicator data, it is input into a large language model (e.g., qwen3-14b-mx) for prediction. Based on the prediction results, a candidate instance list is selected from multiple task execution instances.

[0075] It should be noted that load data, i.e., machine load information, can include: 1. Machine specifications, configuration, and runtime; 2. Number of failures; 3. CPU load; 4. Memory usage, including swap operations; 5. Disk bandwidth usage and read / write speed; 6. Network bandwidth; 7. Number of processes and handles; 8. Battery, CPU, and other hardware temperatures. Task execution data refers to metrics on the process efficiency and result quality of the specific business tasks (i.e., notification tasks) processed by the task execution instance. This can include the number of task retries, task success rate, and task execution time.

[0076] It's important to note that the secondary scheduler considers both the candidate task group (i.e., the candidate instance list) and real-time meta data (i.e., real-time performance metrics) when making scheduling decisions, ultimately determining the target execution instance. Therefore, in actual deployment, the real-time data analysis timeframe needs to be coordinated with the offline large language model analysis timeframe to select the most suitable parameter configuration group for the business scenario. If the offline analysis duration is too long, it can lead to untimely data updates and overheating of local task group instances; conversely, if the offline analysis duration is too short, it can result in excessive computation, impacting scheduling performance.

[0077] Additionally, when the offline analysis link for the large language model fails or data is abnormal, the secondary scheduler degrades to a real-time data scheduler, meaning it only uses the real-time meta data of the task group for task decision-making and scheduling. When the real-time meta data update is abnormal, the secondary scheduler degenerates into a load balancer, meaning it dispatches tasks to all task execution instances with normal heartbeats in turn.

[0078] This embodiment discloses a method for distributing executable notification data to corresponding secondary schedulers via a global scheduler based on the task attributes of the notification task. The task attributes include priority. Real-time operating metrics of multiple task execution instances managed by the secondary scheduler are obtained, and a target execution instance is determined from the multiple task execution instances by combining this with a candidate instance list generated based on historical data analysis. The executable notification data is then scheduled to the target execution instance, which calls an external communication interface to perform the notification delivery operation. Because this embodiment distributes executable notification data to corresponding secondary schedulers via a global scheduler based on the task attributes of the notification task, determines the target execution instance from multiple task execution instances, and then schedules the executable notification data to the target execution instance, which then calls an external communication interface to perform the notification delivery operation, compared to existing technologies, this embodiment achieves dynamic load balancing, improving system stability and resource utilization.

[0079] Furthermore, embodiments of the present invention also propose a storage medium storing a message notification program, wherein the message notification program, when executed by a processor, implements the steps of the message notification method as described above.

[0080] Reference Figure 7 , Figure 7 This is a structural block diagram of the first embodiment of the message notification device of the present invention.

[0081] like Figure 7 As shown, the message notification device proposed in this embodiment of the invention includes: a request receiving module 701, a task generation module 702, a task processing module 703, and a notification sending module 704.

[0082] The request receiving module 701 is used to receive a notification request from the upstream system, verify the notification request, and obtain a verification result. The notification request includes notification content, notification method identifier, and target user identifier.

[0083] The task generation module 702 is used to generate a corresponding notification task based on the notification request if the verification result is successful, and to generate a corresponding task identifier for the notification task.

[0084] The task processing module 703 is used to process the notification task based on the notification method identifier and generate executable notification data.

[0085] The notification delivery module 704 is used to schedule the executable notification data to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and update the status information corresponding to the task identifier according to the execution feedback of the execution unit.

[0086] The notification delivery module 704 is further configured to obtain the execution result of the executable notification data delivery fed back by the execution unit; if the execution result indicates that the delivery failed, the notification task corresponding to the task identifier is set to a retry state and the notification task is added to the retry queue; the notification tasks in the retry queue are retried and the corresponding execution result is obtained and the number of retry delivery is accumulated; when the number of retry delivery reaches the retry threshold or the execution result indicates that the delivery was successful, the status information corresponding to the task identifier is updated.

[0087] This device embodiment discloses receiving a notification request from an upstream system, verifying the notification request, and obtaining a verification result. The notification request includes notification content, a notification method identifier, and a target user identifier. If the verification result is successful, a corresponding notification task is generated based on the notification request, and a corresponding task identifier is generated for the notification task. The notification task is processed based on the notification method identifier to generate executable notification data. The executable notification data is scheduled to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and the status information corresponding to the task identifier is updated according to the execution feedback of the execution unit. Because this device embodiment processes the notification task based on the notification method identifier to generate executable notification data, then schedules the executable notification data to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and finally updates the status information according to the execution feedback, compared with the prior art, this device embodiment improves the flexibility, timeliness, and reliability of the message notification system.

[0088] Based on the first embodiment of the message notification device of the present invention described above, a second embodiment of the message notification device of the present invention is proposed.

[0089] In this embodiment, the task processing module 703 is further configured to: call the corresponding target processing module to adapt the notification content according to the notification method identifier, generate intermediate notification data; associate the intermediate notification data with the task identifier and store it in the task database; and load the intermediate notification data in an executable state from the task database based on the task scheduling rules to generate executable notification data.

[0090] The task processing module 703 is further configured to, when the notification method corresponding to the notification method identifier is a voice notification, use the speech synthesis module as the target processing module; call the speech synthesis module to generate a voice file based on the notification content; upload the voice file to the file server and generate a flow control file, and use the flow control file as intermediate notification data, wherein the flow control file includes the access address and playback control logic of the voice file; The task processing module 703 is further configured to, when the notification method corresponding to the notification method identifier is a text notification, use the content formatting module as the target processing module; call the content formatting module to process the notification content according to the template and protocol specification corresponding to the notification method identifier, generate a standardized message body; and use the standardized message body as intermediate notification data.

[0091] Other embodiments or specific implementations of the message notification device of the present invention can be found in the above-described method embodiments, and will not be repeated here.

[0092] This application provides a message notification device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the message notification method in Embodiment 1 above.

[0093] The following is for reference. Figure 8 The diagram illustrates a structural schematic of a message notification device suitable for implementing embodiments of this application. The message notification device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The message notification device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0094] like Figure 8As shown, the message notification device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the message notification device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the message notification device to communicate wirelessly or wiredly with other devices to exchange data. Although message notification devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0095] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0096] The message notification device provided in this application, employing the message notification method described in the above embodiments, can solve the technical problems of poor flexibility, timeliness, and reliability of existing message notification systems. Compared with the prior art, the beneficial effects of the message notification device provided in this application are the same as those of the message notification method provided in the above embodiments, and other technical features of this message notification device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0097] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0098] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0099] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0100] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0101] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0102] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A message notification method, characterized in that, The method includes: Receive a notification request from the upstream system, verify the notification request, and obtain a verification result. The notification request includes notification content, notification method identifier, and target user identifier. If the verification result is successful, a corresponding notification task is generated based on the notification request, and a corresponding task identifier is generated for the notification task. The notification task is processed based on the notification method identifier to generate executable notification data; Based on a preset load scheduling strategy, the executable notification data is scheduled to the corresponding execution unit for notification delivery, and the status information corresponding to the task identifier is updated according to the execution feedback of the execution unit.

2. The message notification method as described in claim 1, characterized in that, The step of processing the notification task based on the notification method identifier to generate executable notification data includes: Based on the notification method identifier, the corresponding target processing module is invoked to adapt the notification content and generate intermediate notification data; The intermediate notification data is associated with the task identifier and stored in the task database; Based on the task scheduling rules, the intermediate notification data that is in an executable state is loaded from the task database to generate executable notification data.

3. The message notification method as described in claim 2, characterized in that, The step of calling the corresponding target processing module to adapt the notification content and generate intermediate notification data according to the notification method identifier includes: When the notification method identifier corresponds to a voice notification, the speech synthesis module is used as the target processing module. The speech synthesis module is invoked to generate a speech file based on the notification content; The audio file is uploaded to the file server, and a flow control file is generated. The flow control file is used as intermediate notification data. The flow control file includes the access address and playback control logic of the audio file. Accordingly, the step of calling the corresponding target processing module to adapt the notification content and generate intermediate notification data based on the notification method identifier further includes: When the notification method identifier corresponds to a text notification, the content formatting module is used as the target processing module. The content formatting module is invoked to process the notification content according to the template and protocol specifications corresponding to the notification method identifier, thereby generating a standardized message body; The standardized message body is used as intermediate notification data.

4. The message notification method as described in claim 1, characterized in that, The step of scheduling the executable notification data to the corresponding execution unit for notification delivery based on a preset load scheduling strategy includes: Based on the task attributes of the notification task, the executable notification data is distributed to the corresponding secondary scheduler through the global scheduler. The task attributes include priority. The real-time operating metrics of multiple task execution instances managed by the secondary scheduler are obtained, and the target execution instance is determined from the multiple task execution instances by combining the candidate instance list generated based on historical data analysis. The executable notification data is scheduled to the target execution instance, which then calls an external communication interface to perform the notification delivery operation.

5. The message notification method as described in claim 4, characterized in that, The step of distributing the executable notification data to the corresponding secondary scheduler through the global scheduler based on the task attributes of the notification task includes: The priority of the notification task is determined based on its task attributes, and the current resource load status of the system is determined by the global scheduler. If the resource load status is a resource shortage state, the executable notification data is distributed to the secondary scheduler whose scheduling level label matches the priority according to the strong consistency scheduling policy; If the resource load status is sufficient, the executable notification data is distributed to a secondary scheduler with a scheduling level label not lower than the priority, according to the non-strong consistency scheduling policy.

6. The message notification method as described in claim 4, characterized in that, The step of obtaining real-time operating metrics of multiple task execution instances managed by the secondary scheduler, and determining the target execution instance from the multiple task execution instances by combining them with a candidate instance list generated based on historical data analysis, includes: Obtain real-time running metrics for multiple task execution instances managed by the secondary scheduler. The real-time running metrics include at least one of the following: the number of tasks in each task execution instance, the average execution time of tasks in each task execution instance, and the average waiting time of tasks in each task execution instance. Collect load data and task execution data of the multiple task execution instances within a preset historical time period; The load data and the task execution data are input into a large language model for prediction, and a candidate instance list is selected from the multiple task execution instances based on the prediction results; The task execution instances in the candidate instance list are quantitatively scored based on the real-time operation metrics, and the target execution instance is determined from the candidate instance list based on the scoring results.

7. The message notification method as described in claim 1, characterized in that, The step of updating the status information corresponding to the task identifier based on the execution feedback of the execution unit includes: Obtain the execution result regarding the distribution of the executable notification data, as fed back by the execution unit; If the execution result indicates that the delivery failed, the notification task corresponding to the task identifier is set to the retry state, and the notification task is added to the retry queue. Retry the notification tasks in the retry queue, obtain the corresponding execution results, and accumulate the number of retry attempts. When the number of retry attempts reaches the retry threshold or the execution result indicates successful delivery, the status information corresponding to the task identifier is updated.

8. A message notification device, characterized in that, The device includes: The request receiving module is used to receive notification requests from the upstream system, verify the notification requests, and obtain verification results. The notification request includes notification content, notification method identifier, and target user identifier. The task generation module is used to generate a corresponding notification task based on the notification request if the verification result is successful, and to generate a corresponding task identifier for the notification task. The task processing module is used to process the notification task based on the notification method identifier and generate executable notification data; The notification delivery module is used to schedule the executable notification data to the corresponding execution unit for notification delivery based on a preset load scheduling strategy, and update the status information corresponding to the task identifier according to the execution feedback of the execution unit.

9. A message notification device, characterized in that, The device includes: a memory, a processor, and a message notification program stored in the memory and executable on the processor, the message notification program being configured to implement the steps of the message notification method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a message notification program, which, when executed by a processor, implements the steps of the message notification method as described in any one of claims 1 to 7.

Images