Concurrent message pushing method and device based on distributed micro-service architecture and middle station

Abstract

The invention relates to the technical field of message intelligent pushing, and discloses a concurrent message pushing method and device based on a distributed micro-service architecture and a middle station, and the method comprises the steps: carrying out the task identification analysis of an asynchronous message notification, obtaining message data from a message task queue database, generating a to-be-sent message, and sending the to-be-sent message to a server; through the message adaptive pusher matched with the distributed message queue corresponding to the pushing channel identifier, the throughput of message pushing and the utilization rate of system resources can be improved, and then the to-be-sent message is concurrently pushed to the corresponding user through the message adaptive pusher, so that the concurrent pushing efficiency and accuracy of the message are improved, and the reaching rate of the message is improved; when a new message channel needs to be added, the message adapter pusher is directly added, and the channel expansion can be completed without modifying a post core code, so that the waste of development resources is reduced, and the channel expansion cost is reduced; and through the message task queue database and the distributed queue, traffic peak load shifting is realized, the task configuration efficiency is improved, and the message backlog condition is reduced.

Description

Technical Field

[0001] This invention relates to the field of intelligent message push technology, and in particular to a concurrent message push method, apparatus and middleware based on a distributed microservice architecture. Background Technology

[0002] With the continuous expansion of internet business scenarios, the demand for push notifications has grown rapidly and is now widely used in diverse scenarios such as marketing outreach, order status synchronization, risk control reminders, and customer service collaboration. Meanwhile, the rapid iteration of messaging channels and multi-terminal coverage (such as SMS, APP Push, WeChat service accounts, and in-app messages) have further increased the complexity of push systems. Against this backdrop, enterprises are placing higher demands on messaging systems in terms of reliability, throughput, maintainability, and flexibility.

[0003] Current push notification solutions generally adopt a decentralized approach, where each business module builds its own push logic as needed. For example, the marketing module independently implements SMS notifications, and the order module repeatedly develops similar capabilities, so that messages can be pushed according to their respective logics when needed. However, in practice, it has been found that while the decentralized approach offers the flexibility of rapid module development in the short term, repeatedly writing similar code for template parsing and channel calls not only wastes development resources but also leads to multiple versions of the same function existing simultaneously, resulting in a sharp increase in maintenance costs. Furthermore, when multiple modules call the same function simultaneously, they are prone to competing for channel resources (such as exceeding the limit of multiple module push requests during peak promotion periods), resulting in limited throughput and low resource utilization. In particular, it cannot meet the push notification needs of scenarios with large business scale, sudden traffic surges, and complex push notifications, such as scenarios where push channels have been added to APP push and mini-program notifications, and message types cover real-time alarms, marketing activities, service reminders, and promotional activities.

[0004] Therefore, it is particularly important to propose a new message push method that can improve message push throughput and system resource utilization, thereby improving the efficiency and accuracy of concurrent message push, while reducing development resource waste and lowering costs. Summary of the Invention

[0005] This invention provides a concurrent message push method, device, and middleware based on a distributed microservice architecture, which can improve the throughput of message push and the utilization of system resources, thereby improving the efficiency and accuracy of concurrent message push, while reducing development resource waste and lowering costs.

[0006] The first aspect of this invention discloses a concurrent message push method based on a distributed microservice architecture, the method being applied to a message middleware platform, the method comprising: When an asynchronous message push notification is detected, the message platform parses the asynchronous message push notification to obtain the task identifiers of all message push tasks that need to be pushed, and retrieves the message data of each message push task from a pre-created message task queue database based on the task identifier of each message push task. The message task queue database is used to store the message dataset that needs to be pushed and the task identifier of each message data in the message dataset. The message platform generates target messages to be sent to all target users corresponding to each message push task based on the message data of each message push task, and determines the push channel identifier of each target message corresponding to each message push task based on the message data of each message push task. The message platform controls the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier to push the corresponding target message to the target user corresponding to the target message, based on the push channel identifier corresponding to each target message.

[0007] A second aspect of this invention discloses a concurrent message push device based on a distributed microservice architecture, the device being applied to a message middleware platform, the device comprising: The parsing module is used to parse the asynchronous message push notification when it is detected, and obtain the task identifiers of all message push tasks that need to be pushed. The acquisition module is used to acquire message data of each message push task from a pre-created message task queue database according to the task identifier of each message push task. The message task queue database is used to store the message dataset to be pushed and the task identifier of each message data in the message dataset. The generation module is used to generate target messages to be sent to all target users corresponding to each message push task based on the message data of each message push task. The determining module is used to determine the push channel identifier of each target message corresponding to the message push task based on the message data of each message push task; The push module is used to control the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to the target message, based on the push channel identifier corresponding to each target message.

[0008] As an optional implementation, in a second aspect of the invention, the apparatus further includes: The storage module is used to store the target messages of each target user into the message task queue database; The push module, based on the push channel identifier corresponding to each target message, controls the message adapter pusher matching the distributed message queue corresponding to that push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to the target message. The specific method includes: Based on the push channel identifier corresponding to each target message, the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier is controlled, and the operation of pushing the corresponding target message to be sent to the corresponding target user is executed through the message task queue database. The push module, based on the push channel identifier corresponding to each target message, controls a message adapter pusher matching the distributed message queue corresponding to that push channel identifier, and executes the operation of pushing the corresponding target message to the corresponding target user through the message task queue database, including: Based on the push channel identifier corresponding to each target message, a corresponding distributed message queue is adapted, and the corresponding message identifier is sent to the corresponding message adapter pusher through the distributed message queue. Each target message has a corresponding message identifier. Based on the message adapter pusher, the target message to be sent that matches the message identifier is obtained from the message task queue database, and the message push interface that matches the message adapter pusher is called to push the corresponding target message to the target user corresponding to the target message.

[0009] As an optional implementation, in a second aspect of the invention, the generation module generates a specific method for generating target messages to be sent to all target users corresponding to each message push task based on the message data of that message push task, including: For any of the message push tasks, based on the message data of the message push task, obtain the channel template content that matches the push channel identifier in the message data of the message push task, and perform a mapping operation on the placeholder in the message data of the message push task to obtain the mapping content of the placeholder. Based on the mapping content of the placeholder and the channel template content matched by the push channel identifier, a target message to be sent corresponding to the target user is generated; The device also includes: The verification module is used to perform a validity verification operation on the message data of any message push task before the generation module generates the target message to be sent for all target users corresponding to the message push task based on the message data of each message push task, and obtain the message data verification result of the message push task. When the message data verification result of the message push task is used to indicate that the verification is passed, the generation module is triggered to perform the operation of generating the target message to be sent for all target users corresponding to the message push task based on the message data of each message push task. The legality verification operation includes one or more of the following: task identifier verification operation, task status verification operation, template verification operation corresponding to push channel identifier, channel key verification operation corresponding to push channel identifier, user legitimacy verification operation, and push time verification operation.

[0010] As an optional implementation, in a second aspect of the invention, the apparatus further includes: The first detection module is used to detect multiple message push requests; The parsing module is further configured to perform a parsing operation on each message push request to obtain the message data of the message push request. The message data of each message push request includes message data of multiple first users. The message data of each first user includes the identifier of the first user, the push channel identifier, and the message push strategy. All first users include all target users. The creation module is used to create a message push task matching the first user and a task identifier for the message push task based on the message data of each first user, and to store the message push task and the corresponding task identifier for each first user corresponding to each message push request in the message task queue database.

[0011] As an optional implementation, in a second aspect of the invention, the apparatus further includes: The monitoring module is used to monitor the push result of any target message during the message push process and obtain the push monitoring result of the target message. The update module is used to update the channel success data corresponding to the target message in a pre-determined cache database when the push monitoring result of the target message indicates that the target message has been successfully pushed to the corresponding target user. The update module is further configured to update the number of push retry times and the sending status of the target message in the cache database when the push monitoring result of the target message indicates that the target message has failed to be pushed to the corresponding target user. The push module is also used to add the target message to the message task queue database and re-execute the push operation.

[0012] As an optional implementation, in a second aspect of the invention, the apparatus further includes: The second detection module is used to monitor message processing data during the message push process. The judgment module is used to determine whether it is necessary to perform a capacity adjustment operation on the system based on the monitored message processing data; The determining module is also used to determine the matching capacity adjustment parameters based on message processing data when it is determined that a capacity adjustment operation needs to be performed on the system. The adjustment module is used to perform corresponding capacity adjustment operations on the system according to the capacity adjustment parameters; The message processing data includes system memory usage and / or the number of message processing requests per unit time. When the system memory usage is greater than or equal to a first preset usage, or when the number of message processing requests is greater than or equal to a first preset processing capacity, the capacity adjustment operation is an expansion operation. When the system memory usage is less than or equal to a second preset usage, and / or when the number of message processing requests is less than or equal to a second preset processing capacity, the capacity adjustment operation is a reduction operation. Wherein, the first preset utilization rate is greater than the second preset utilization rate, and the first preset processing volume is greater than the second preset processing volume.

[0013] As an optional implementation, in a second aspect of the invention, the determining module determines the specific method by which it determines the push channel identifier of each target message corresponding to each message push task based on the message data of each message push task, including: The message platform determines the identifier of each target user based on the message data of each message push task, and determines the channel identifier that matches the identifier of the target user from the channel profile tag set in the pre-built user profile tag library, which serves as the push channel identifier of the target message corresponding to the target user. The determining module is further configured to, before the push module controls the message adapter pusher matching the distributed message queue corresponding to the push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to the target message, from the time profile tag set in the user profile tag library, determine the push time strategy matching the identifier of each target user; when the push time strategy is used to indicate that the message needs to be pushed immediately, the push module is triggered to perform the step of controlling the message adapter pusher matching the distributed message queue corresponding to the push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to the target message. The determining module is further configured to, when the push time strategy is used to indicate that a non-real-time push message is required, determine the corresponding push time according to the push time strategy, and when the real-time time reaches the push time, trigger the push module to execute the step of controlling the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier corresponding to each target message to push the corresponding target message to the target user corresponding to the target message.

[0014] As an optional implementation, in a second aspect of the present invention, the acquisition module is further configured to acquire message reach effect data within a target time period in the past. The message reach effect data includes message reach effect data of multiple second users. Each message reach effect data of a target second user includes the identifier of the second user, the reach channel of all messages that successfully reached the second user within the target time period, the push time of each message, and various factors such as the second user's click status and conversion status for each message. The device further includes: The structured processing module is used to perform structured processing on the message reach effect data of any second user to obtain structured message reach effect data, and analyze the message reach effect data to obtain the best reach characteristics of the second user within the target time period. The generation module is further configured to generate a profile tag for the second user based on the best reach features and the corresponding channel identifier. The best reach features for the second user include the best reach channel and the best reach push time. The profile tag for the second user includes a channel profile tag and a time profile tag. The generation module is further configured to generate a user profile tag library based on the profile tags of all the second users. The user profile tag library is used to store channel profile tag sets and time profile tag sets. All the second users include all the target users.

[0015] A third aspect of the present invention discloses a message middleware platform, the message middleware platform comprising: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute some or all of the steps in the concurrent message push method based on a distributed microservice architecture as described in any of the first aspects of the present invention.

[0016] Compared with the prior art, the present invention has the following beneficial effects: In this embodiment of the invention, when an asynchronous message push notification is detected, the message middle platform parses the asynchronous message push notification to obtain the task identifiers of all message push tasks that need to be pushed. Based on the task identifier of each message push task, it retrieves the message data for each message push task from a pre-created message task queue database. The message task queue database stores the message dataset to be pushed and the task identifier of each message data in the message dataset. Based on the message data of each message push task, the message middle platform generates target messages to be sent to all target users corresponding to that message push task. Based on the message data of each message push task, it determines the push channel identifier for each target message corresponding to the message push task. Based on the push channel identifier corresponding to each target message, the message middle platform controls the message adapter pusher matching the distributed message queue corresponding to that push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to that target message. As can be seen, implementing this invention analyzes the task identifiers of the asynchronous message notifications it receives, retrieves the corresponding message data from the message task queue database, generates the corresponding message to be sent, and identifies the message adapter pusher matched with the corresponding distributed message queue through the corresponding push channel. This improves the throughput of message push and the utilization of system resources. Then, the message to be sent is pushed concurrently to the corresponding user through the corresponding message adapter pusher, improving the efficiency and accuracy of concurrent message push and thus increasing the message reach rate. Furthermore, by decoupling business and push channels through multi-adaptor interfaces, when a new message channel needs to be added, a message adapter pusher can be added directly without modifying the core code, thus completing the channel expansion, reducing development resource waste, and lowering the channel expansion cost. Moreover, by using the message task queue database and distributed queues to achieve traffic peak shaving and valley filling, the efficiency of task configuration is improved. In particular, it can handle peak requests in complex scenarios such as renewal reminders during promotional periods, reducing message backlog and making full use of message task queue database resources to continuously improve message concurrency efficiency. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a concurrent message push method based on a distributed microservice architecture disclosed in an embodiment of the present invention. Figure 2 This is a flowchart illustrating another concurrent message push method based on a distributed microservice architecture disclosed in an embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of a concurrent message push device based on a distributed microservice architecture disclosed in an embodiment of the present invention; Figure 4 This is a schematic diagram of another concurrent message push device based on a distributed microservice architecture disclosed in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a message middleware platform disclosed in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or end that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or ends.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] This invention discloses a concurrent message push method, device, and middleware based on a distributed microservice architecture. By analyzing the task identifiers of detected asynchronous message notifications, corresponding message data is retrieved from the message task queue database, and corresponding messages to be sent are generated. These messages are then matched with message adapter pushers in the corresponding distributed message queues through their respective push channel identifiers, improving message push throughput and system resource utilization. The messages to be sent are then concurrently pushed to the corresponding users through the corresponding message adapter pushers, improving the efficiency and accuracy of concurrent message pushes. Furthermore, by decoupling business logic from push channels through multiple adapter interfaces, when a new message channel needs to be added, a message adapter pusher can be added directly without modifying the core code, thus reducing development resource waste and lowering channel expansion costs. Finally, by using the message task queue database and distributed queues, traffic peak shaving and valley filling are achieved, especially effective in handling peak requests in complex scenarios such as renewal reminders during promotional periods, reducing message backlog and ensuring full utilization of message task queue database resources, thereby continuously improving message concurrency efficiency. These are described in detail below.

[0023] To better understand the concurrent message push method, device, and middleware based on a distributed microservice architecture described in this invention, the service architecture applicable to the concurrent message push method based on a distributed microservice architecture is first described. This service architecture can be understood as the basic environment and foundation for implementing this invention. It organizes and encapsulates the process of this invention through microservices (such as Golang microservices) and leverages the cloud-native capabilities of Kubernetes for service deployment and governance, thus possessing advanced characteristics such as high cohesion, low coupling, and elastic scaling. This service architecture consists of several major modules: an API gateway, a task distribution parser, a distributed message queue (also called a task distribution message queue), a task distribution processor, a message adaptation pusher, and a message task queue database (also called a persistent layer database). Specifically, the API gateway is responsible for detecting and verifying message push requests, and then forwarding the message push requests to the distribution task parser; the distribution task parser is responsible for parsing the data in the message push request and generating a message distribution task; the distributed message queue is responsible for asynchronously buffering and transmitting the execution signal of the message distribution task; the distribution task processor is responsible for dividing the push message into specific messages to be sent (such as a text message to be sent, an email to be sent, etc.) according to the push message channel (channel) identifier and target identifier, and is responsible for finding the channel-adapted message adapter pusher to execute the message push, and is also responsible for collecting push records to form push statistics reports; the channel push message adapter pusher is responsible for the specific message push operation of the corresponding channel, such as the text message push message adapter pusher pushing via mobile phone number, and the email push message adapter pusher pushing via email address; the message task queue database is responsible for data traceability and archiving of the entire implementation process of this invention.

[0024] Example 1 Please see Figure 1 , Figure 1 This is a flowchart illustrating a concurrent message push method based on a distributed microservice architecture disclosed in an embodiment of the present invention. Wherein, Figure 1 The described method is encapsulated as a microservice platform, which can decouple and adapt to any scenario requiring message push, such as marketing outreach, order status synchronization, risk control alerts, and customer service collaboration. Each scenario has a corresponding message platform. Figure 1 As shown, the method may include the following steps: 101. When an asynchronous message push notification is detected, the message middle platform parses the asynchronous message push notification to obtain the task identifiers of all message push tasks that need to be pushed, and retrieves the message data of each message push task from the pre-created message task queue database according to the task identifier of each message push task.

[0025] In this embodiment of the invention, the message middleware platform employs microservices to provide service capabilities, such as Golang microservices, to achieve high cohesion and low coupling service characteristics during concurrent message push. Optionally, the message task queue database stores the dataset of messages to be pushed and the task identifier for each message in the dataset. The message data for each push task includes a list of target user identifiers (e.g., 6000017, 6000126), template identifiers, channel identifiers, placeholder mappings, etc. The message data in the dataset originates from one or more message push requests, including but not limited to the management backend, HTTP interface calls, and gRPC interface calls. Each push request can have multiple messages to be pushed. The message task queue database can be any database capable of storing message data, such as MongoDB.

[0026] 102. The message platform generates target messages to be sent to all target users corresponding to each message push task based on the message data of each message push task.

[0027] In this embodiment of the invention, each message push task can correspond to multiple target users, that is, the target message needs to be pushed to these multiple target users.

[0028] 103. The message middle platform determines the push channel identifier for each target message corresponding to each message push task based on the message data of each message push task.

[0029] 104. The message middle platform controls the message adapter pusher that matches the distributed message queue (such as RocketMQ) corresponding to the push channel identifier of each target message to push the corresponding target message to the target user corresponding to the target message.

[0030] It is evident that implementation Figure 1The described method analyzes the task identifiers of monitored asynchronous message notifications to retrieve corresponding message data from the message task queue database, generates corresponding messages to be sent, and identifies the message adapter pusher matched with the corresponding distributed message queue through the corresponding push channel identifier. This improves message push throughput and system resource utilization. The messages to be sent are then pushed concurrently to the corresponding users through the corresponding message adapter pusher, improving the efficiency and accuracy of concurrent message push and thus increasing message reach. Furthermore, the method decouples business logic from push channels through a multi-adaptor interface. When a new message channel needs to be added, a message adapter pusher can be added directly without modifying the core code, thus reducing development resource waste and lowering channel expansion costs. Finally, the method uses the message task queue database and distributed queues to achieve traffic peak shaving and valley filling, improving task configuration efficiency. It is particularly effective in handling peak requests in complex scenarios such as renewal reminders during promotional periods, reducing message backlog and ensuring full utilization of message task queue database resources to continuously improve message concurrency efficiency.

[0031] In an optional embodiment, the message platform generates target messages to be sent to all target users corresponding to each message push task based on the message data of that task, including: For any message push task, the message middle platform obtains the channel template content that matches the push channel identifier in the message data of the message push task, and performs a mapping operation on the placeholder in the message data of the message push task to obtain the mapped content of the placeholder. The message platform generates the target message to be sent to the target user based on the mapping content of the placeholder and the channel template content matched by the push channel identifier.

[0032] In this optional embodiment, the channel template includes, but is not limited to, various types of templates such as SMS templates, email modules, APP templates, voice modules, and mini-program modules. The channel template content is read from a core business database (such as OceanBase) (where the channel template content corresponding to each push channel identifier is stored separately for each channel), and combined with the mapping content of placeholders to generate the corresponding target message. For example, an APP Push template might have the following channel template content: "Dear user, your order ${order_id} will expire on ${expire_date}. Please click the [Renew] button to process it promptly." Another example is an SMS template: "Your order ${order_id} will expire on ${expire_date}. Click the link to renew." The placeholder mapping data (order_id→202501012673, expire_date→2025-05-13) is then injected into the template to generate the final message content. The APP Push message reads: "Dear user, your order 202501012673 will expire on 2025-05-13. Please click the [Renew] button to process it promptly." The SMS message reads: "Your order 202501012673 will expire on 2025-05-13. Click the link to renew."

[0033] As can be seen, this optional embodiment achieves automatic conversion from general templates to multi-channel personalized messages through channel template matching and placeholder dynamic mapping mechanism. It also ensures core data consistency by relying on the core business database to store template structure, reduces message format disorder, and improves the accuracy of personalized message generation. It is especially suitable for efficient and personalized message generation in scenarios with tens of millions of users, thereby improving the message concurrency reach rate and further improving the message click-through rate and conversion rate.

[0034] In another optional embodiment, before the message platform generates the target messages to be sent to all target users corresponding to each message push task based on the message data of that task, the method may further include the following steps: For any message push task, the message middle platform performs a legality verification operation on the message data of the message push task to obtain the message data verification result of the message push task. When the message data verification result of the message push task is used to indicate that the verification is passed, the operation of generating the target message to be sent to all target users corresponding to the message push task is performed based on the message data of each message push task. The legitimacy verification operation includes one or more of the following: task identifier verification operation, task status verification operation, template verification operation corresponding to the push channel identifier, channel key verification operation corresponding to the push channel identifier, user legitimacy verification operation, and push time verification operation.

[0035] In this optional embodiment, when the message data verification result of the message push task is used to indicate that the verification failed, the process of this message push task is terminated and a failure mark is added to it.

[0036] In this optional embodiment, specifically, the task identifier verification operation is used to check whether the task identifier exists in the message task queue database. If it exists, the task identifier verification passes. The task status verification operation is used to check whether the task status is pending execution. If it is, the status verification passes. The template verification operation corresponding to the push channel identifier is used to check whether it exists in the core business database and whether it is enabled. If it is, the template verification passes. The channel key verification operation corresponding to the push channel identifier is used to check whether the key is configured completely. If it is, the verification passes. The user validity verification operation is used to check whether the target user's identifier format conforms to the rules (e.g., whether 6000017 is a valid tenant ID). If it does, it is valid. The push time verification operation is used to check whether it is an instant push or the push time is after the current time. If it is, the time verification passes.

[0037] As can be seen, after obtaining the message data for the push task, this optional embodiment further verifies the message data through multiple dimensions such as task identifier, status, template, channel key, user legitimacy, and push time. This effectively intercepts invalid push requests, such as missing template parameters, expired channel keys, and users who have terminated their leases. It filters out illegal push tasks in advance, significantly reducing the storage pressure on the message queue and the invalid traffic of the distributed queue. Specifically: if the renewal reminder template identifier is incorrect, template verification directly intercepts it, reducing the push of erroneous content; channel key verification reads the latest key from the core business database, reducing push failures caused by key expiration; user legitimacy verification filters users who have terminated their leases, reducing invalid pushes; status verification reduces the repetitive processing of the same task; and push time verification ensures the accurate execution of scheduled tasks, improving the overall correctness and compliance of message pushes. If the message is valid, a corresponding message to be sent is generated, improving the effectiveness and accuracy of message generation, which in turn helps to further improve the accuracy and efficiency of message concurrency, thereby further increasing the message reach rate and reducing the user complaint rate.

[0038] In yet another optional embodiment, the method may further include the following steps: The message middle platform stores the target messages for each target user in the message task queue database; Specifically, the message middle platform, based on the push channel identifier corresponding to each target message, controls the message adapter pusher matching the distributed message queue corresponding to that push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to that target message, including: The message middle platform controls the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier based on the push channel identifier of each target message. Through the message task queue database, it executes the operation of pushing the corresponding target message to be sent to the corresponding target user. Specifically, the message middle platform, based on the push channel identifier corresponding to each target message, controls the message adapter pusher matched with the distributed message queue corresponding to that push channel identifier. Through the message task queue database, it executes the operation of pushing the corresponding target message to the corresponding target user, including: The message middle platform adapts to the corresponding distributed message queue based on the push channel identifier corresponding to each target message, and sends the corresponding message identifier to the corresponding message adapter pusher through the distributed message queue. Each target message has a corresponding message identifier. The message middle platform, based on the message adapter pusher, retrieves the target message to be sent that matches the message identifier from the message task queue database, and calls the message push interface (such as SDK) that matches the message adapter pusher to push the corresponding target message to the target user corresponding to the target message.

[0039] In this optional embodiment, the message middleware generates an independent target message to be sent for each target user and stores it in the message task queue database. Each target message includes information such as a message identifier, associated task identifier, user identifier, push channel identifier, template-filled content, and status. Based on the push channel identifier, the target message's message identifier is sent to the corresponding distributed message queue. Then, the corresponding message adapter pusher is controlled to retrieve the corresponding target message from the message task queue database based on the message identifier and push it. Each message adapter pusher has a corresponding message push interface.

[0040] As can be seen, implementing this optional embodiment first stores the messages to be sent in the message task queue database, persistently storing the messages to be sent to ensure no loss. Then, according to the push channel identifier, it adapts to the corresponding distributed message queue and sends the message identifier to the message adapter pusher. The message adapter pusher retrieves the message from the message task queue database as needed and calls the corresponding message push interface to push it. This not only smooths out peaks and valleys through the distributed queue to cope with peak times during promotions, but also reduces the channel expansion cost by using the adapter pattern. Adding a new WeChat Enterprise channel only requires adding an adapter. At the same time, the retry mechanism of the distributed message queue combined with the persistence of the message task queue database decouples storage and push, improves system throughput, further improves the message reminder reach rate and trigger efficiency, and reduces redundant resource consumption. The independent scaling of each channel pusher is particularly suitable for efficient and reliable message push in scenarios with tens of millions of users.

[0041] In yet another optional embodiment, the method may further include the following steps: The message middle platform detects multiple message push requests and performs a parsing operation on each message push request to obtain the message data of the message push request. The message data of each message push request includes message data of multiple first users. The message data of each first user includes the identifier of the first user, the push channel identifier, and the message push strategy. All first users include all target users. The message platform creates a message push task matching the first user and a task identifier for the message push task based on the message data of each first user, and stores the message push task and corresponding task identifier for each first user corresponding to each message push request in the message task queue database.

[0042] In this optional embodiment, optionally, one source can initiate a message push request to the message platform, or multiple sources can simultaneously send message push requests to the message platform separately. The sources include, but are not limited to, one or more of the following: management backend, HTTP interface calls, and gRPC interface calls. The message platform parses all message push requests sent by all sources into a standard format. Each first user's identifier is any identifier that can represent their identity, such as an ID card, phone number, or order number (e.g., 6000017, 6000126). Each first user's message push strategy includes, but is not limited to, message templates (e.g., order expiration and renewal reminder templates), channel information, and push strategy information (e.g., scheduled push time nodes). Channel information includes priority push channel messages (e.g., APP Push keys, numbers, etc.) and candidate push channel messages (e.g., SMS channel identifiers). Push strategy information includes instant push strategies or scheduled push strategies. Instant push strategies indicate that when a corresponding message push request is detected, the corresponding message push operation is executed. Scheduled push strategies indicate that the message push operation is executed only when the real-time time reaches a specified time, such as a scheduled push three days before the expiration date. Furthermore, the message push strategy for each first user also includes placeholder mapping data, such as ${order_id}->202501012673.

[0043] As can be seen, implementing this optional embodiment achieves a unified message push entry point through the adapter pattern, collecting and parsing message push requests from various sources. Even if a new message push request type is added, the core process does not need to be modified, and the message push request can still be parsed into message data in a unified standard format, ensuring that subsequent processes can be processed uniformly. After parsing the message data into a unified standard format, a corresponding message push task and task identifier are created and stored in the corresponding message task queue database to support high-concurrency message reading and writing, with read and write performance reaching tens of thousands per second, thereby further improving the concurrent message push efficiency.

[0044] In yet another optional embodiment, the method may further include the following steps: For any target message, during the message push process, the message middle platform listens to the push result of the target message and obtains the push listening result of the target message. When the push monitoring result of the target message is used to indicate that the target message has been successfully pushed to the corresponding target user, the message platform updates the channel success data corresponding to the target message in the pre-determined cache database; When the push notification result of the target message indicates that the target message failed to be pushed to the corresponding target user, the message platform updates the push retry count and sending status of the target message in the cache database, and adds the target message to the message task queue database to re-execute the push operation.

[0045] In this optional embodiment, for successful cases, the channel success data of the target message includes the number of times the message template of the target message is successfully used and the number of times the channel is successfully pushed. For example, the number of successful pushes of template TPL_001 is increased, the number of successful pushes of APP Push channel is increased, and the target user 6000017 is successfully pushed.

[0046] In this optional embodiment, in the event of failure, as long as the number of push retries has not reached the preset number of retries, such as 5 times, the target message is added back to the message task queue database, and the message identifier of the target message is resent to the distributed queue for push again, until the push is successful or the number of push retries reaches the preset number of retries.

[0047] As can be seen, implementing this optional embodiment monitors the success or failure of each message push. For successful pushes, it records the number of times the message template was successfully used and the number of times the channel was successfully pushed in the cache database. This allows for adjustments to the use of different message templates and channels in subsequent message pushes, thereby improving resource utilization, concurrency efficiency, success rate, and message reach. For failed pushes, it updates the number of push retries and sending status in the cache database, ensuring traceability of message sending status, facilitating retry management, and adding the message back to the message task queue database for re-push. The distributed queue ensures message reliability, reduces message loss, contributes to successful message push, and guarantees message reach.

[0048] In yet another optional embodiment, the method may further include the following steps: During the message push process, the message platform monitors the message processing data and determines whether to adjust the system capacity based on the monitored data. When it is determined that a capacity adjustment operation needs to be performed on the system, the message middle platform determines the matching capacity adjustment parameters based on the message processing data, and performs the corresponding capacity adjustment operation on the system according to the capacity adjustment parameters. The capacity adjustment parameters include the capacity adjustment copy and the capacity adjustment time. The message processing data includes system memory usage (i.e., CPU) and / or the number of message processing requests per unit time. When the system memory usage is greater than or equal to a first preset usage rate (e.g., 80%), or when the number of message processing requests is greater than or equal to a first preset processing capacity (e.g., 1500 QPS), the capacity adjustment operation is an expansion operation. When the system memory usage is less than or equal to a second preset usage rate (e.g., 50%), and / or when the number of message processing requests is less than or equal to a second preset processing capacity (e.g., 300 QPS), the capacity adjustment operation is a reduction operation. The first preset usage rate is greater than the second preset usage rate, and the first preset processing capacity is greater than the second preset processing capacity. The system memory usage rate can be the average usage rate over a period of time or the current usage rate.

[0049] In this optional embodiment, it should be noted that the specific value of capacity expansion or capacity reduction is determined by the difference between the system's running memory usage rate and the corresponding preset usage rate, or the difference between the number of message processing requests per unit time and the preset processing volume. The larger the difference, the larger the capacity adjustment range, and vice versa. The following example illustrates capacity adjustment operations. Under normal conditions, if the system runs 2 Pod replicas, with a system utilization rate of 30% and message processing requests at 300 QPS, no capacity adjustment is needed. During the pre-sale period, with a system utilization rate of 50% and message processing requests at 500 QPS, no capacity adjustment is still needed. During the peak period, with a system utilization rate of 85% (exceeding the preset utilization rate of 80%) and message processing requests at 1500 QPS (exceeding the preset processing capacity of 1000 QPS), HPA begins to expand capacity, such as adding 2 replicas every 30 seconds, expanding to 20 replicas within 10 minutes. In the stable period, with 20 Pods processing messages, the system utilization rate drops to 50%, and message processing capacity reaches 2000 QPS. At this point, there is no message backlog, and the peak period capacity is maintained. In the off-peak period, with message processing requests dropping to 200 QPS and system utilization rate dropping to 25%, capacity is reduced, such as removing 2 replicas every 60 seconds, returning to 2 replicas within 30 minutes.

[0050] As can be seen, by implementing this optional embodiment, during message concurrency, the system monitors the memory usage and the number of message processing requests, compares them with corresponding preset values, and then flexibly configures the HPA strategy based on the comparison results. Relying on the public cloud, it can achieve adaptive capacity elastic scaling, expanding capacity during peak periods to ensure processing capacity and reduce response latency during message concurrency, and shrinking capacity during off-peak periods to reduce resource waste. This further improves throughput and resource utilization, namely the number of message processing and push tasks that the system can complete per unit time, and reduces operation and maintenance costs during peak periods without manual intervention in the scaling process.

[0051] In yet another optional embodiment, the method may further include the following steps: For cases where the interval between the current time and the time corresponding to the preset promotional period is less than or equal to the preset duration (e.g., 1 hour), the message platform collects message processing data from historical time periods matching the current time period (e.g., the same time last year), message processing data from the first time period, message processing data from the first historical time period matching the first time period, message processing data from the second time period, and message processing data from the second historical time period matching the second time period. The first time period is earlier than the current time period, which is earlier than the second time period, and both the first and second time periods are determined based on the current time period. For example, the first time period, the current time period, and the second time period are listed in sequence. The message processing data for the first historical period is defined as 18:00-20:00, 20:00-22:00, and 22:00-24:00 on June 18, 2025. Similarly, the first historical period, the second historical period, and the third historical period are defined as 18:00-20:00, 20:00-22:00, and 22:00-24:00 on June 18, 2024, respectively. The message processing data for the second historical period is predicted based on the trend between the message processing data of the current period and the message processing data of the first historical period, as well as the change range between the message processing data of the historical period and the message processing data of the second historical period, and these trends are directly proportional. The message platform determines the capacity adjustment parameters that match the second time period based on the message processing data of the second time period. The message platform obtains the message reach rate for the current time period, the message reach rate for the first time period, the message reach rate for the historical time period, the message reach rate for the first historical time period, and the message reach rate for the second historical time period. For the current time period, the message platform calculates the difference between the system's memory usage rate and the historical system memory usage rate, the difference between the number of message processing requests and the historical number of message processing requests, and the difference between the message reach rate for the current time period and the message reach rate for the historical time period. For the first time period, the calculation methods for the first usage rate difference, the first request number difference, and the first reach rate difference are the same as for the current time period, and all differences are normalized. The message processing data for the second historical time period is also normalized, and the normalization range is [-1-1]. The message platform adjusts the capacity adjustment parameters that match the second time period based on the difference in usage rate, the difference in the number of requests, and the difference in the reach rate during the current time period, and obtains the adjusted first capacity adjustment parameters. The message platform performs an adjustment operation on the capacity adjustment parameters that match the second time period based on the first usage rate difference, the first request number difference, and the first reach rate difference in the first time period, and obtains the adjusted second capacity adjustment parameters. The message platform adjusts the capacity adjustment parameters that match the second historical time period based on the normalized message processing data and message reach rate of the second historical time period, and obtains the adjusted third capacity adjustment parameters. The message platform sets corresponding capacity adjustment weights for the first capacity adjustment parameter, the second capacity adjustment parameter, and the third capacity adjustment parameter based on the changing trends between the message processing data of the first time period and the message processing data of the current time period, and the changing trends between the message processing data of the current time period and the message processing data of the second time period. For example, if the traffic growth trend is 18-20 to 20-22, which is a 60% increase, then the weights are 0.4, 0.3, and 0.3. The changing trend between the message processing data of the current time period and the message processing data of the second time period is predicted based on the changing trend between the message processing data of the first time period and the message processing data of the current time period, as well as the changing trend between the message processing data of historical time periods and the message processing data of the second historical time period, and they are directly proportional. The message middle platform calculates the product of the first capacity adjustment parameter, the second capacity adjustment parameter, the third capacity adjustment parameter, and their respective corresponding capacity adjustment weights, and then determines the final capacity adjustment parameter for the second time period by multiplying all the parameters.

[0052] As can be seen, implementing this optional embodiment, based on historical traffic trends and real-time traffic changes, predicts in advance the capacity expansion and adjustment time required for the peak promotion period, making preparations in advance. This enables precise pre-adjustment and elastic scaling of resources during peak promotion scenarios, reducing message backlog and ensuring high reach rates for message pushes even during peak periods. This effectively solves the resource waste and peak vulnerability issues of traditional static configuration. Furthermore, by normalizing and weighting the differences between memory usage, request count, and reach rate, the accuracy of capacity adjustment parameters is improved. Combining the peak-shaving and valley-filling capabilities of distributed message queues with the high-concurrency storage of distributed message task databases further improves resource utilization and message throughput, mitigating the risk of system crashes during peak promotion periods and reducing resource idleness and waste.

[0053] Example 2 Please see Figure 2 , Figure 2 This is a flowchart illustrating another concurrent message push method based on a distributed microservice architecture disclosed in an embodiment of the present invention. Wherein, Figure 2 The described method is encapsulated as a microservice platform, which can decouple and adapt to any scenario requiring message push, such as marketing outreach, order status synchronization, risk control alerts, and customer service collaboration. Each scenario has a corresponding message platform. Figure 2 As shown, the method may include the following steps: 201. When an asynchronous message push notification is detected, the message middle platform parses the asynchronous message push notification to obtain the task identifiers of all message push tasks that need to be pushed, and retrieves the message data of each message push task from the pre-created message task queue database according to the task identifier of each message push task.

[0054] In this embodiment of the invention, optionally, the message task queue database is used to store the message dataset to be pushed and the task identifier of each message data in the message dataset.

[0055] 202. The message platform generates target messages to be sent to all target users corresponding to each message push task based on the message data of each message push task.

[0056] 203. The message platform determines the identifier of each target user based on the message data of each message push task, and determines the channel identifier that matches the identifier of the target user from the channel profile tag set in the pre-built user profile tag library. This channel identifier is used as the push channel identifier of the target message corresponding to the target user. The platform also determines the push channel identifier of each target message corresponding to each message push task based on the message data of each message push task.

[0057] 204. The message platform determines the push time strategy that matches the identifier of each target user from the time profile tag set in the user profile tag library. When the push time strategy is used to indicate that the message needs to be pushed immediately, step 206 is executed; when the push time strategy is used to indicate that the message needs to be pushed non-instantly, step 205 is executed.

[0058] 205. The message platform determines the corresponding push time according to the push time strategy, and executes step 206 when the real-time time reaches the push time.

[0059] In this embodiment of the invention, the push time can be a point in time or a time window. Furthermore, the channel and time recommendation results are aggregated and returned to the message platform's server, which then responds to the task configuration interface and directly uses the recommendation results.

[0060] 206. The message middle platform controls the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier to push the corresponding target message to the target user corresponding to the target message, based on the push channel identifier corresponding to each target message.

[0061] In this embodiment of the invention, for a detailed description of steps 201, 202, and 206, please refer to the other descriptions of steps 101, 102, and 104 in Embodiment 1. These descriptions will not be repeated in this embodiment of the invention.

[0062] It is evident that implementation Figure 2The described method analyzes the task identifiers of monitored asynchronous message notifications to retrieve corresponding message data from the message task queue database, generates corresponding messages to be sent, and identifies the message adapter pusher matched with the corresponding distributed message queue through the corresponding push channel identifier. This improves message push throughput and system resource utilization. The messages to be sent are then pushed concurrently to the corresponding users through the corresponding message adapter pusher, improving the efficiency and accuracy of concurrent message push and thus increasing message reach. Furthermore, the method decouples business logic from push channels through a multi-adaptor interface. When a new message channel needs to be added, a message adapter pusher can be added directly without modifying the core code, thus reducing development resource waste and lowering channel expansion costs. Finally, the method uses the message task queue database and distributed queues to achieve traffic peak shaving and valley filling, improving task configuration efficiency. It is particularly effective in handling peak requests in complex scenarios such as renewal reminders during promotional periods, reducing message backlog and ensuring full utilization of message task queue database resources to continuously improve message concurrency efficiency. Furthermore, after receiving message data, the channel profile tags are matched from the channel profile tag set using user identifiers to determine the push channel identifier, improving the accuracy and efficiency of push channel identifier determination. Then, time profile tags are matched, that is, personalized matching of channels and time is achieved through the user profile tag library, reducing blind pushes. Based on the specific situation of the time profile tags, instant push or time monitoring is selected. When the push time is reached, the message identifier is sent to the message adaptation pusher through a distributed message queue. The message is pushed through the message adaptation pusher, which further improves the accuracy of concurrent message push, thereby further improving the accuracy and efficiency of message delivery.

[0063] In an optional embodiment, the method may further include the following steps: The message platform acquires message reach performance data over a target period (e.g., 1 month, 3 months, etc.) (which can be stored in the message task queue database or other databases). The message reach performance data includes message reach performance data for multiple second users. The message reach performance data for each second user includes the second user's identifier, the reach channels of all messages that successfully reached the second user within the target period, the push time of each message, and various factors such as the second user's click status and conversion status for each message. For any second user, the message platform performs structured processing on the message reach effect data of the second user to obtain structured message reach effect data, and analyzes the message reach effect data to obtain the best reach characteristics of the second user within the target time period, and generates profile tags for the second user based on the best reach characteristics and the corresponding channel identifier. The best reach characteristics of the second user include the best reach channel and the best reach push time, and the profile tags of the second user include channel profile tags and time profile tags. The message platform generates a user profile tag library based on the profile tags of all second users. The user profile tag library is used to store channel profile tag sets and time profile tag sets. All second users include all target users.

[0064] In this optional embodiment, the reach channels may include, but are not limited to, APP Push channels and / or SMS channels and / or email channels and / or mini-program channels and / or voice channels. Message click data indicates whether a click occurred; if so, the click time is also included. Message conversion data indicates whether a conversion occurred; if so, the conversion time is also included. The optimal reach channel represents the channel with the highest click-through rate. For example, if the click-through rate of the APP Push channel is 45% and the click-through rate of the SMS channel is 15%, then the APP Push channel is the optimal reach channel. Similarly, the optimal push time represents the time with the highest conversion rate. For example, if the conversion rate is 40% between 7 PM and 9 PM and 20% at other times, then 7 PM to 9 PM is the optimal push time. Corresponding profile tags are then generated, such as preferred_channel: app_push, best_time_slot: 7 PM to 9 PM. Of course, the optimal trigger characteristics may differ for different target users. Once message trigger effect data or user profile tag library is obtained, it is integrated into the intelligent workflow for application, that is, persistently written to the message task queue database. The message task queue database can exist in the CRM system (Customer Relationship Management) to achieve dynamic and reusable user segmentation.

[0065] As can be seen, implementing this optional embodiment extracts user reach data and generates optimal trigger channels / time tags after structured processing. This integrates the preference characteristics of millions of users to form a complete, reliable, and accurate user profile tag library. This allows for automatic matching of the optimal strategy when sending message reminders, such as renewal reminders, further improving message reach and efficiency, and consequently, message conversion rates. At the same time, it reduces invalid pushes, such as reducing SMS messages sent to users of preferred apps, saving channel resources. This solves the problems of blind channel selection and inefficient time matching in traditional push notifications, achieving a dual improvement in resource utilization and user experience.

[0066] Example 3 Please see Figure 3 , Figure 3 This is a schematic diagram of a concurrent message push device based on a distributed microservice architecture, as disclosed in an embodiment of the present invention. This device is applied to a middleware service encapsulated in the form of microservices, and can decouple and adapt to any scenario requiring message push, such as marketing outreach, order status synchronization, risk control reminders, and customer service collaboration. Each scenario has a corresponding message middleware platform. Figure 3 As shown, the device may include: The parsing module 301 is used to parse the asynchronous message push notification when it is detected, and obtain the task identifiers of all message push tasks that need to be pushed. The acquisition module 302 is used to acquire message data of each message push task from a pre-created message task queue database according to the task identifier of each message push task. The message task queue database is used to store the message dataset to be pushed and the task identifier of each message data in the message dataset. The generation module 303 is used to generate target messages to be sent to all target users corresponding to each message push task based on the message data of each message push task. The determination module 304 is used to determine the push channel identifier of each target message corresponding to the message push task based on the message data of each message push task; The push module 305 is used to control the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to the target message, based on the push channel identifier corresponding to each target message.

[0067] It is evident that implementation Figure 3The described device analyzes the task identifiers of detected asynchronous message notifications to retrieve corresponding message data from the message task queue database, generates corresponding messages to be sent, and identifies the message adapter pusher matched with the corresponding distributed message queue through the corresponding push channel. This improves message push throughput and system resource utilization. The messages to be sent are then pushed concurrently to the corresponding users through the corresponding message adapter pusher, improving the efficiency and accuracy of concurrent message push and thus increasing message reach. Furthermore, by decoupling business logic from push channels through multi-adaptor interfaces, when a new message channel needs to be added, a message adapter pusher can be added directly without modifying the core code, reducing development resource waste and lowering channel expansion costs. Finally, by using the message task queue database and distributed queues to achieve traffic peak shaving and valley filling, the device improves task configuration efficiency, especially in handling peak requests in complex scenarios such as renewal reminders during promotional periods, reducing message backlog and ensuring full utilization of message task queue database resources, thereby continuously improving message concurrency efficiency.

[0068] In an optional embodiment, such as Figure 4 As shown, the device may further include: Storage module 306 is used to store the target message of each target user to the message task queue database; Specifically, the push module 305, based on the push channel identifier corresponding to each target message, controls the message adapter pusher matching the distributed message queue corresponding to that push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to that target message in the following ways: Based on the push channel identifier corresponding to each target message, the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier is controlled, and the operation of pushing the corresponding target message to be sent to the corresponding target user is executed through the message task queue database. Specifically, the push module 305, based on the push channel identifier corresponding to each target message, controls the message adapter pusher matched with the distributed message queue corresponding to that push channel identifier, and executes the specific method of pushing the corresponding target message to the corresponding target user through the message task queue database, including: Based on the push channel identifier corresponding to each target message, the corresponding distributed message queue is adapted, and the corresponding message identifier is sent to the corresponding message adapter pusher through the distributed message queue. Each target message has a corresponding message identifier. Based on the message adapter pusher, the system retrieves the target message to be sent that matches the message identifier from the message task queue database, and calls the message push interface that matches the message adapter pusher to push the corresponding target message to the target user corresponding to the target message.

[0069] It is evident that implementation Figure 4 The described device first stores the messages to be sent in the message task queue database, persistently storing the messages to be sent to ensure no loss. Then, it adapts to the corresponding distributed message queue according to the push channel identifier and sends the message identifier to the message adapter pusher. The message adapter pusher retrieves the message from the message task queue database as needed and calls the corresponding message push interface to push it. This not only smooths out peak traffic during promotional events through the distributed queue, but also reduces the cost of channel expansion by using the adapter pattern. Adding a new WeChat Enterprise channel only requires adding an adapter. At the same time, the retry mechanism of the distributed message queue combined with the persistence of the message task queue database decouples storage and push, improves system throughput, further improves the delivery rate and triggering efficiency of message reminders, and reduces redundant resource consumption. The independent scaling of each channel pusher is particularly suitable for efficient and reliable message push in scenarios with tens of millions of users.

[0070] In another optional embodiment, the generation module 3003 generates a specific method for generating the target messages to be sent to all target users corresponding to each message push task based on the message data of each message push task, including: For any message push task, based on the message data of the message push task, obtain the channel template content that matches the push channel identifier in the message data of the message push task, and perform a mapping operation on the placeholder in the message data of the message push task to obtain the mapping content of the placeholder. Based on the mapping content of the placeholder and the channel template content matched by the push channel identifier, generate the target message to be sent to the target user. And, such as Figure 4 As shown, the device may further include: The verification module 307 is used to perform a legality verification operation on the message data of any message push task before the generation module 303 generates the target message to be sent for all target users corresponding to the message push task based on the message data of each message push task, and obtain the message data verification result of the message push task. When the message data verification result of the message push task is used to indicate that the verification is passed, the generation module 303 is triggered to perform the operation of generating the target message to be sent for all target users corresponding to the message push task based on the message data of each message push task. The legitimacy verification operation includes one or more of the following: task identifier verification operation, task status verification operation, template verification operation corresponding to the push channel identifier, channel key verification operation corresponding to the push channel identifier, user legitimacy verification operation, and push time verification operation.

[0071] It is evident that implementation Figure 4The described device achieves automatic conversion from general templates to multi-channel personalized messages through channel template matching and placeholder dynamic mapping mechanisms. It also ensures core data consistency by relying on the core business database to store template structures, reducing message format errors and improving the accuracy of personalized message generation. This is particularly suitable for efficient and personalized message generation in scenarios with tens of millions of users, thereby improving message concurrency reach and further increasing click-through rates and conversion rates. Furthermore, after receiving message data from the push task, it further analyzes multiple dimensions such as task identifier, status, template, channel key, user legitimacy, and push time. Message data is validated to effectively block invalid message push requests, such as those with missing template parameters, expired channel keys, or terminated user leases. This proactive filtering of illegal push tasks significantly reduces storage pressure on the message queue and invalid traffic in the distributed queue. Specifically: template validation directly blocks incorrect renewal reminder templates, reducing erroneous content pushes; channel key validation retrieves the latest key from the core business database, reducing push failures due to expired keys; user legitimacy validation filters terminated users, reducing invalid pushes; status validation reduces duplicate processing of the same task; and push time validation ensures accurate execution of scheduled tasks, improving the overall accuracy and compliance of message pushes. Only if the message is valid is the corresponding message to be sent generated, improving the effectiveness and accuracy of message generation. This further enhances the accuracy and efficiency of message concurrency, ultimately increasing message reach and reducing user complaint rates.

[0072] In yet another alternative embodiment, such as Figure 4 As shown, the device may further include: The first detection module 308 is used to detect multiple message push requests; The parsing module 301 is also used to perform a parsing operation on each message push request to obtain the message data of the message push request. The message data of each message push request includes message data of multiple first users. The message data of each first user includes the identifier of the first user, the push channel identifier and the message push strategy. All first users include all target users. The creation module 309 is used to create a message push task matching the first user and the task identifier of the message push task based on the message data of each first user, and to store the message push task and the corresponding task identifier of each first user corresponding to each message push request in the message task queue database.

[0073] It is evident that implementation Figure 4The described device implements a unified message push entry point through the adapter pattern, collects and parses message push requests from various sources, and can parse message push requests into message data in a unified standard format without modifying the core process, even if a new message push request type is added. This ensures that subsequent processes can handle the message push requests uniformly. After parsing the message data into a unified standard format, the device creates a corresponding message push task and task identifier and stores them in the corresponding message task queue database to support high-concurrency message reading and writing. The read and write performance reaches tens of thousands per second, thereby further improving the efficiency of concurrent message push.

[0074] In yet another alternative embodiment, such as Figure 4 As shown, the device may further include: The listening module 310 is used to listen to the push result of any target message during the message push process and obtain the push listening result of the target message. The update module 311 is used to update the channel success data corresponding to the target message in a pre-determined cache database when the push listening result of the target message indicates that the target message has been successfully pushed to the corresponding target user. The update module 311 is also used to update the number of push retry and sending status of the target message in the cache database when the push listening result of the target message indicates that the target message failed to be pushed to the corresponding target user. The push module 305 is also used to add the target message to the message task queue database and re-execute the push operation.

[0075] It is evident that implementation Figure 4 The described device monitors the success or failure of each message push. For successful pushes, it records the number of times the message template was successfully used and the number of times the channel was successfully pushed in the cache database. This allows for adjustments to the use of different message templates and channels in subsequent pushes, thereby improving resource utilization, concurrency efficiency, success rate, and message reach. For failed pushes, it updates the number of push retries and sending status in the cache database, ensuring traceability of message sending status, facilitating retry management, and adding the message back to the message task queue database for re-push. The distributed queue ensures message reliability, reduces message loss, contributes to successful message push, and guarantees message reach.

[0076] In yet another alternative embodiment, such as Figure 4 As shown, the device may further include: The second detection module 312 is used to monitor message processing data during the message push process. The judgment module 313 is used to determine whether it is necessary to perform a capacity adjustment operation on the system based on the monitored message processing data; The determination module 304 is also used to determine the matching capacity adjustment parameters based on message processing data when it is determined that a capacity adjustment operation needs to be performed on the system. The adjustment module 314 is used to perform corresponding capacity adjustment operations on the system according to the capacity adjustment parameters; The message processing data includes the system's running memory usage rate and / or the number of message processing requests per unit time. When the system's running memory usage rate is greater than or equal to the first preset usage rate, or when the number of message processing requests is greater than or equal to the first preset processing capacity, the capacity adjustment operation is an expansion operation. When the system's running memory usage rate is less than or equal to the second preset usage rate, and / or when the number of message processing requests is less than or equal to the second preset processing capacity, the capacity adjustment operation is a reduction operation. Among them, the utilization rate of the first preset is greater than that of the second preset, and the processing volume of the first preset is greater than that of the second preset.

[0077] It is evident that implementation Figure 4 The described device, during message concurrency, monitors the system's memory usage and the number of message processing requests, compares them with corresponding preset values, and then flexibly configures the HPA strategy based on the comparison results. Relying on the public cloud, it can achieve adaptive capacity elastic scaling, expanding capacity during peak periods to ensure processing capacity and reduce response latency during message concurrency, and shrinking capacity during off-peak periods to reduce resource waste, thereby further improving throughput and resource utilization, i.e., the number of message processing and push tasks that the system can complete per unit time, and reducing operation and maintenance costs during peak periods without manual intervention in the scaling process.

[0078] In yet another alternative embodiment, such as Figure 4 As shown, the determining module 304 determines the specific method of the push channel identifier for each target message corresponding to each message push task based on the message data of each message push task, including: The message platform determines the identifier of each target user based on the message data of each message push task, and determines the channel identifier that matches the identifier of the target user from the channel profile tag set in the pre-built user profile tag library, which serves as the push channel identifier for the target message corresponding to the target user. The determination module is also used to determine the push time strategy matching the identifier of each target user from the time profile tag set in the user profile tag library before the push module controls the message adapter pusher matching the distributed message queue corresponding to the push channel identifier to push the corresponding target message to the target user corresponding to the target message, based on the push channel identifier corresponding to each target message. When the push time strategy is used to indicate that the message needs to be pushed immediately, the push module is triggered to perform the step of controlling the message adapter pusher matching the distributed message queue corresponding to the push channel identifier to push the corresponding target message to the target user corresponding to the target message. The determination module is also used to determine the corresponding push time according to the push time strategy when the push time strategy is used to indicate that a non-real-time push message is required, and to trigger the push module to perform the following steps when the push time is reached: according to the push channel identifier corresponding to each target message, control the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier to push the corresponding target message to the target user corresponding to the target message.

[0079] It is evident that implementation Figure 4 After receiving message data, the described device matches channel profile tags from the channel profile tag set using the user identifier to determine the push channel identifier, improving the accuracy and efficiency of push channel identifier determination. Then, it matches time profile tags, that is, it realizes personalized matching of channel and time through the user profile tag library, reducing blind pushes. Based on the specific situation of the time profile tag, it selects instant push or time monitoring. When the push time arrives, it sends the message identifier to the message adaptation pusher through a distributed message queue. The message adaptation pusher then pushes the message, further improving the accuracy of concurrent message push, thereby further improving the accuracy and efficiency of message delivery.

[0080] In yet another alternative embodiment, such as Figure 4 As shown, the acquisition module 302 is also used to acquire message reach effect data within a target time period in the past. The message reach effect data includes message reach effect data of multiple second users. The message reach effect data of each target second user includes the second user's identifier, the reach channel of all messages that successfully reached the second user within the target time period, the push time of each message, and various factors such as the second user's click status and conversion status for each message. And such as Figure 4 As shown, the device may further include: The structured processing module 315 is used to perform structured processing on the message delivery effect data of any second user, obtain structured message delivery effect data, and analyze the message delivery effect data to obtain the best delivery characteristics of the second user within the target time period. The generation module 303 is also used to generate a profile label for the second user based on the best reach features and the corresponding channel identifier. The best reach features for the second user include the best reach channel and the best reach push time. The profile label for the second user includes the channel profile label and the time profile label. The generation module 303 is also used to generate a user profile tag library based on the profile tags of all second users. The user profile tag library is used to store channel profile tag sets and time profile tag sets. All second users include all target users.

[0081] It is evident that implementation Figure 4 The described device extracts user reach data and generates optimal trigger channels / time tags after structured processing. This integrates the preference characteristics of millions of users to form a complete, reliable, and accurate user profile tag library. This allows for automatic matching of the optimal strategy when sending message reminders, such as subscription renewal reminders, further improving message reach and efficiency, and consequently, message conversion rates. Simultaneously, it reduces invalid pushes, such as reducing SMS messages sent to users of preferred apps, saving channel resources. This solves the problems of blind channel selection and inefficient time matching in traditional push notifications, achieving a dual improvement in resource utilization and user experience.

[0082] Example 4 Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a message middleware platform disclosed in an embodiment of the present invention. Figure 5 As shown, the device may include: Memory 401 storing executable program code; Processor 402 coupled to memory 401; The processor 402 calls the executable program code stored in the memory 401 to execute some or all of the steps in any of the concurrent message push methods based on a distributed microservice architecture in Embodiment 1 or Embodiment 2 of the present invention.

[0083] Example 5 This invention discloses a computer storage medium storing computer instructions. When these computer instructions are invoked, they are used to execute some or all of the steps in any of the concurrent message push methods based on a distributed microservice architecture disclosed in Embodiments 1 and 2 of this invention.

[0084] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0085] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0086] Finally, it should be noted that the above embodiments are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A concurrent message push method based on a distributed microservice architecture, characterized in that, The method is applied to a message middleware platform, and the method includes: When an asynchronous message push notification is detected, the message platform parses the asynchronous message push notification to obtain the task identifiers of all message push tasks that need to be pushed, and retrieves the message data of each message push task from a pre-created message task queue database based on the task identifier of each message push task. The message task queue database is used to store the message dataset that needs to be pushed and the task identifier of each message data in the message dataset. The message platform generates target messages to be sent to all target users corresponding to each message push task based on the message data of each message push task, and determines the push channel identifier of each target message corresponding to each message push task based on the message data of each message push task. The message middle platform controls the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to the target message, based on the push channel identifier corresponding to each target message.

2. The concurrent message push method based on a distributed microservice architecture according to claim 1, characterized in that, The method further includes: The message platform stores the target message for each target user into the message task queue database; The message middle platform, based on the push channel identifier corresponding to each target message, controls a message adapter pusher matching the distributed message queue corresponding to that push channel identifier to push the corresponding target message to the target user corresponding to that target message, including: The message platform controls a message adapter pusher that matches the distributed message queue corresponding to the push channel identifier according to the push channel identifier of each target message, and performs the operation of pushing the target message to be sent to the corresponding target user through the message task queue database. The message platform, based on the push channel identifier corresponding to each target message, controls a message adapter pusher matching the distributed message queue corresponding to that push channel identifier, and executes the operation of pushing the corresponding target message to the corresponding target user through the message task queue database, including: The message platform adapts to the corresponding distributed message queue according to the push channel identifier corresponding to each target message, and sends the corresponding message identifier to the corresponding message adapter pusher through the distributed message queue. Each target message has a corresponding message identifier. The message platform, based on the message adapter pusher, retrieves the target message to be sent that matches the message identifier from the message task queue database, and calls the message push interface that matches the message adapter pusher to push the corresponding target message to the target user corresponding to the target message.

3. The concurrent message push method based on a distributed microservice architecture according to claim 1, characterized in that, The message platform generates target messages to be sent to all target users corresponding to each message push task based on the message data of that task, including: For any of the aforementioned message push tasks, the message platform obtains the channel template content that matches the push channel identifier in the message data of the message push task based on the message data of the message push task, and performs a mapping operation on the placeholder in the message data of the message push task to obtain the mapped content of the placeholder. The message platform generates the target message to be sent for the target user based on the mapping content of the placeholder and the channel template content matched by the push channel identifier. Furthermore, before the message platform generates the target messages to be sent to all target users corresponding to each message push task based on the message data of that message push task, the method further includes: For any of the message push tasks, the message platform performs a legality verification operation on the message data of the message push task to obtain the message data verification result of the message push task. When the message data verification result of the message push task is used to indicate that the verification is passed, the operation of generating the target message to be sent to all target users corresponding to the message push task is performed based on the message data of each message push task. The legality verification operation includes one or more of the following: task identifier verification operation, task status verification operation, template verification operation corresponding to push channel identifier, channel key verification operation corresponding to push channel identifier, user legitimacy verification operation, and push time verification operation.

4. The concurrent message push method based on a distributed microservice architecture according to any one of claims 1-3, characterized in that, The method further includes: The message platform detects multiple message push requests and performs a parsing operation on each message push request to obtain the message data of the message push request. The message data of each message push request includes message data of multiple first users. The message data of each first user includes the identifier of the first user, the push channel identifier, and the message push strategy. All first users include all target users. The message platform creates a message push task matching the first user and a task identifier for the message push task based on the message data of each first user, and stores the message push task and corresponding task identifier for each first user corresponding to each message push request in the message task queue database.

5. The concurrent message push method based on a distributed microservice architecture according to any one of claims 1-3, characterized in that, The method further includes: For any of the target messages, during the message push process, the message platform listens to the push result of the target message and obtains the push listening result of the target message; When the push monitoring result of the target message indicates that the target message has been successfully pushed to the corresponding target user, the message platform updates the channel success data corresponding to the target message in a pre-determined cache database; When the push monitoring result of the target message indicates that the target message failed to be pushed to the corresponding target user, the message platform updates the push retry count and sending status of the target message in the cache database, and adds the target message to the message task queue database to re-execute the push operation.

6. The concurrent message push method based on a distributed microservice architecture according to any one of claims 1-3, characterized in that, The method further includes: During the message push process, the message platform monitors the message processing data during the message push process, and determines whether it is necessary to perform a capacity adjustment operation on the system based on the monitored message processing data. When it is determined that a capacity adjustment operation needs to be performed on the system, the message platform determines the matching capacity adjustment parameters based on the message processing data, and performs the corresponding capacity adjustment operation on the system based on the capacity adjustment parameters. The message processing data includes system memory usage and / or the number of message processing requests per unit time. When the system memory usage is greater than or equal to a first preset usage, or when the number of message processing requests is greater than or equal to a first preset processing capacity, the capacity adjustment operation is an expansion operation. When the system memory usage is less than or equal to a second preset usage, and / or when the number of message processing requests is less than or equal to a second preset processing capacity, the capacity adjustment operation is a reduction operation. Wherein, the first preset utilization rate is greater than the second preset utilization rate, and the first preset processing volume is greater than the second preset processing volume.

7. The concurrent message push method based on a distributed microservice architecture according to claim 1 or 2, characterized in that, The message platform determines the push channel identifier for each target message corresponding to each message push task based on the message data of each message push task, including: The message platform determines the identifier of each target user based on the message data of each message push task, and determines the channel identifier that matches the identifier of the target user from the channel profile tag set in the pre-built user profile tag library, which serves as the push channel identifier of the target message corresponding to the target user. Before the message middle platform controls the message adapter pusher matching the distributed message queue corresponding to the push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to the target message, based on the push channel identifier corresponding to each target message, the method further includes: The message platform determines a push time strategy that matches the identifier of each target user from the time profile tag set in the user profile tag library. When the push time strategy is used to indicate that a message needs to be pushed immediately, the step of controlling the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier according to each target message to push the corresponding target message to the target user corresponding to the target message is executed. When the push time strategy is used to indicate that a non-real-time push message is required, the message platform determines the corresponding push time according to the push time strategy, and when the push time is reached in real time, it executes the step of controlling the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier to push the corresponding target message to the target user corresponding to the target message according to the push channel identifier corresponding to each target message.

8. The concurrent message push method based on a distributed microservice architecture according to claim 7, characterized in that, The method further includes: The message platform acquires message reach effect data within a target time period in the past. The message reach effect data includes message reach effect data for multiple second users. Each second user's message reach effect data includes the second user's identifier, the reach channel of all messages that successfully reached the second user within the target time period, the push time of each message, and various factors such as the second user's click status and conversion status for each message. For any second user, the message platform performs structured processing on the message reach effect data of the second user to obtain structured message reach effect data, and analyzes the message reach effect data to obtain the best reach features of the second user within the target time period, and generates profile tags for the second user based on the best reach features and the corresponding channel identifier. The best reach features of the second user include the best reach channel and the best reach push time, and the profile tags of the second user include channel profile tags and time profile tags. The message platform generates a user profile tag library based on the profile tags of all the second users. The user profile tag library is used to store channel profile tag sets and time profile tag sets. All the second users include all the target users.

9. A concurrent message push device based on a distributed microservice architecture, characterized in that, The device is used in a message middleware platform, and the device includes: The parsing module is used to parse the asynchronous message push notification when it is detected, and obtain the task identifiers of all message push tasks that need to be pushed. The acquisition module is used to acquire message data of each message push task from a pre-created message task queue database according to the task identifier of each message push task. The message task queue database is used to store the message dataset to be pushed and the task identifier of each message data in the message dataset. The generation module is used to generate target messages to be sent to all target users corresponding to each message push task based on the message data of each message push task. The determining module is used to determine the push channel identifier of each target message corresponding to the message push task based on the message data of each message push task; The push module is used to control the message adapter pusher that matches the distributed message queue corresponding to the push channel identifier to perform the operation of pushing the corresponding target message to the target user corresponding to the target message, based on the push channel identifier corresponding to each target message.

10. A message middleware platform, characterized in that, The message middleware includes: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the concurrent message push method based on a distributed microservice architecture as described in any one of claims 1-8.

Images