Saas system message pushing method and system based on message queue

Abstract

The invention relates to a Saas system message pushing method and system based on a message queue, and belongs to the technical field of message pushing, and the method comprises the steps that each micro-service instance maintains a corresponding local long connection pool; when the business service generates a message needing to be pushed to a target user, the message is published to a message theme corresponding to identification information in a message queue according to the identification information of a tenant to which the target user belongs; the micro-service instance subscribing to the message theme corresponding to the target user receives the message, inquires a local long connection pool of the micro-service instance after receiving the message, and judges whether long connection exists between the micro-service instance and the target user or not; if the long connection exists, the corresponding micro-service instance pushes the message to the target user and confirms the consumption message; and if the long connection does not exist, the corresponding micro-service instance discards or ignores the message. The method has the advantages that on the premise of guaranteeing real-time and accurate delivery of the message, the system overhead is remarkably reduced, and the elastic expansion of the system scale can be supported.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of message pushing, in particular to a SaaS system message pushing method and system based on a message queue. BACKGROUND

[0002] With the deep integration of cloud computing and the Software as a Service (SaaS) mode, the multi-tenant architecture has become the mainstream of modern enterprise-level applications. Under this architecture, a single software instance can serve multiple tenants, and the data and operations of each tenant are strictly logically isolated, thereby achieving efficient use of resources and significant cost reduction. In order to improve user experience, many SaaS applications, especially instant messaging (IM), online collaboration, real-time monitoring, etc., need to provide real-time message pushing capabilities based on long connections (such as WebSocket) for end users.

[0003] In the current era of microservice architecture, the backend system supporting the above-mentioned SaaS applications is usually composed of multiple independently deployed, horizontally scalable microservice instances. The long connections of users are scattered on these different microservice instances. This distributed connection feature raises a key technical problem: when the system needs to push a real-time message to a specific user, how to accurately and efficiently route the message to the microservice instance (or instances) that has established a long connection with the user.

[0004] To this end, the industry's common solution is through load balancing, database polling, etc., but these methods have shortcomings in handling real-time and system resource consumption. Load balancing can distribute connections, but the load balancer only distributes connection requests to a certain instance when the user initially establishes a connection, but it cannot sense where the connection is distributed throughout its life cycle, so it cannot be used as a decision point for subsequent message routing. Database polling stores all user-instance mapping relationships in a central database (such as Redis). When a message needs to be pushed, the database is first queried to determine the target instance, and then a call is made to the instance. This approach puts a lot of pressure on the registry center in high-concurrency scenarios, and the query operation itself introduces latency, making it difficult to meet the requirements of millisecond-level real-time pushing. In summary, existing technologies generally face the problems of inaccurate message routing, high system latency, large resource consumption, and poor horizontal scalability when dealing with real-time message accurate pushing in the SaaS multi-tenant, microservice environment, so there is room for improvement. SUMMARY

[0005] In order to ensure real-time and accurate delivery of messages, significantly reduce system overhead, and support elastic expansion of system size, the present application provides a SaaS system message pushing method and system based on a message queue.

[0006] Firstly, this application provides a message push method for a SaaS system based on a message queue. The execution entity of the method is a message push system for a SaaS system based on a message queue. The system includes a message queue and multiple microservice instances. The method includes: Each microservice instance maintains a corresponding local long-connection pool, which is used to record user information that has established a long connection with the corresponding microservice instance. When a business service generates a message that needs to be pushed to a target user, the message is published to the message queue and the message topic corresponding to the identification information according to the identification information of the tenant to which the target user belongs; The microservice instance that has subscribed to the message topic corresponding to the target user receives the message and, after receiving the message, queries its own local long connection pool to determine whether a long connection exists with the target user. If a long-lived connection exists, the corresponding microservice instance will push the message to the target user and confirm the consumption of the message; If no long-lived connection exists, the corresponding microservice instance will discard or ignore the message.

[0007] By adopting the above technical solution, and through a dual filtering mechanism of "publishing to the corresponding message topic based on tenant identification information" and "judging by the local connection pool of microservice instances," the system can automatically and accurately route messages to the specific microservice instances that currently maintain a long-term connection with the target user. Compared with existing technologies, this solution overcomes the shortcomings of traditional point-to-point communication, which cannot locate dynamic distributed connections, and the huge resource waste caused by full-node broadcasting. Furthermore, by using a message queue publish-subscribe mechanism for event-driven message delivery, messages are broadcast to all relevant microservice instances in real time once generated. Each microservice instance performs local querying and pushing in parallel, completely avoiding the query waiting intervals and central node performance bottlenecks inherent in solutions based on database polling, significantly reducing the end-to-end latency from message generation to delivery to the user, and meeting the stringent millisecond-level response requirements of high-concurrency scenarios such as instant messaging and real-time notifications. Moreover, messages are only consumed and pushed to the microservice instances that ultimately hold the connection to the target user; for instances that do not hold the connection, messages are immediately discarded, avoiding unnecessary network transmission, protocol parsing, and business processing overhead. This on-demand consumption model significantly reduces the overall system load. Compared to solutions that require maintaining a global state, frequent central queries, or full-instance broadcasting, this method distributes computational and matching pressure locally across each microservice instance. Resource consumption is approximately linearly related to the number of connections and message volume, resulting in extremely high efficiency. Furthermore, the system's core routing logic (topic subscription, local filtering) is independent of the number of specific microservice instances. When adding a new microservice instance, it only needs to subscribe to the required message topics to seamlessly join the cluster and undertake message push tasks without modifying the configuration or routing logic of existing services. Compared to existing technologies, the system performance of this application can improve almost linearly with the increase in microservice instances, gracefully handling user growth and traffic surges during peak business periods, solving the problem of difficult scaling under centralized architectures. Finally, microservice instances do not need to be aware of each other's existence or state, communicating loosely only through message queues. The failure or restart of a single instance will not affect the normal operation of the message queue and other instances, nor will it lead to the loss of global connection state information, reducing system complexity, improving the isolation of local faults, and making the overall system more robust and easier to maintain.

[0008] Optionally, the method further includes: Based on users' historical message consumption data, interest profiles are generated for each user. Based on the interest profile, users with similar interest profiles within the same microservice instance are dynamically categorized into different virtual interest groups; wherein each virtual interest group is associated with a specific message subtopic, and the message subtopic belongs to a message topic named with the tenant's identification information; The message topic corresponding to the identification information, which is published to the message queue, includes: Based on the type of the message, the message is published to the message subtopic in the message queue that corresponds to the virtual interest group to which the target user belongs; The microservice instance that has subscribed to the message topic corresponding to the target user receives the message and, after receiving the message, queries its own local long-connection pool to determine whether a long connection exists with the target user, including: A microservice instance that has subscribed to the message subtopic receives the message and, after receiving the message, queries whether the target user exists in the virtual interest group associated with the message subtopic. If it exists, it is considered that there is a long connection with the target user.

[0009] By adopting the above technical solution, messages are no longer broadcast to all instances of the entire tenant, but are only sent to instances that have subscribed to specific interest subtopics. This fundamentally reduces the unnecessary use of network bandwidth and the overhead of unnecessary message processing for a large number of microservice instances. Microservice instances determine whether to hold a connection for a target user by querying the virtual interest group member list instead of querying the full connection pool. Since the group list is an abstract set of interests, it is usually much smaller than the full connection pool, making this query operation faster and with less memory overhead, reducing the decision latency of individual instances and improving the overall throughput of the system. Different message types (such as orders, chat, and announcements) are delivered through different subtopics, making the classification and management of message flows clearer and laying the foundation for subsequent fine-grained processing and monitoring.

[0010] Optionally, the same user can belong to multiple different virtual interest groups; If a long-lived connection exists, the corresponding microservice instance will push the message to the target user, including: The microservice instance that has a long-lived connection with the target user is selected as the target microservice instance. The target microservice instance performs load-aware routing decision, which includes the following steps: Obtain the real-time load status of the target user within the target microservice instance and the virtual interest groups to which they belong; Based on the real-time load status, select the target virtual interest group with the optimal load from among the virtual interest groups to which the target user belongs; The message is delivered to the target user by a virtual interest group.

[0011] By adopting the above technical solution, when a target user belongs to multiple virtual interest groups, the system can dynamically select the least busy path to process messages based on the real-time load status of each group. This effectively avoids the situation where other types of messages belonging to users in a particular interest group (such as a "chat group") are also blocked when the instantaneous pressure on that group is too high. It ensures that user messages are always quickly pushed through the "channel" with the strongest processing capacity within their connection instance, and even when some channels are congested, they can still be delivered in a timely manner through other available channels, significantly reducing end-to-end message latency and improving service availability.

[0012] Optionally, the method further includes: Continuously monitor users' real-time behavior data and dynamically update the corresponding user's interest profile based on the real-time behavior data; Whenever a user's interest profile is updated and the corresponding update indicates that the user should be added to a new virtual interest group, the corresponding user is designated as the first user and added to the new virtual interest group. If a message with the first user as the target user already exists, a transition strategy is executed, the transition strategy including: The message subtopic associated with the newly added virtual interest group of the first user is temporarily marked as the transitional subtopic of the first user; a transitional message buffer corresponding to the first user and the transitional subtopic is established to temporarily store messages sent to the transitional subtopic and received by the first user; after the operation of adding the first user to the new virtual interest group is completed, the messages temporarily stored in the transitional message buffer are consumed, and messages are pushed to the first user by executing the load-aware routing strategy.

[0013] By adopting the above technical solution, during the critical time window when user interest profiles are updated and new groups need to be added, the temporary construction of "transitional subtopics" and "transitional message buffers" ensures that messages belonging to the new interest categories sent to users during this period are safely stored and resent after the state stabilizes. This mechanism completely solves the technical problem of message loss that may occur due to asynchronous updates of the system state. Users are completely unaware of the background adjustment process of the interest group structure, and their message reception is continuous and complete, ensuring the smoothness of the service.

[0014] Optionally, delivering the message to the target user via the target virtual interest group includes: Encapsulate the message with internal routing metadata to generate an internal routing message. The internal routing metadata includes at least a target virtual interest group identifier. The internal routing message is delivered to the internal service queue within the target microservice instance that corresponds to the target virtual interest group identifier. The system listens to and consumes the internal service queue to obtain the internal routing message, parses the internal routing message to obtain the corresponding target user identifier, queries the local long connection pool based on the target user identifier to obtain the corresponding long connection, and pushes the original message content in the internal routing message to the target user through the long connection.

[0015] By adopting the above technical solution, and through the cooperation of "internal routing metadata," "internal service queues," and dedicated consumption threads for each group, the routing decision logic and the final push execution logic are clearly decoupled. This allows the load balancing strategy to evolve independently, while the push execution module remains stable. New virtual interest groups can be easily expanded by adding corresponding internal queues and consumption threads without modifying the core routing and push architecture. Simultaneously, this mechanism facilitates monitoring the queuing and processing status within each group.

[0016] Optionally, the load-aware routing decision further includes: Based on the historical load data of each virtual interest group, predict its load trend for a future preset time period; The step of selecting the target virtual interest group with the optimal load from the virtual interest groups to which the target user belongs, based on the real-time load status, includes: Based on the real-time load status and the predicted load trend, the target virtual interest group with the optimal overall load is selected from the virtual interest groups to which the target user belongs.

[0017] By adopting the above technical solutions, the system not only reacts based on the current load but also predicts the load change trends of each group in the short term. This allows it to proactively avoid upcoming traffic peaks and pre-route messages to less busy groups, thereby achieving a better and more stable load balancing effect. For groups with rapidly increasing loads, the prediction mechanism can pre-emptively distribute traffic, effectively smoothing the traffic curve and avoiding the risk of performance fluctuations or avalanches caused by instantaneous pressure surges.

[0018] Optionally, the method further includes: When each microservice instance maintains its corresponding local long-lived connection pool, it also monitors and records the real-time health indicators of each long-lived connection. When a message needs to be pushed to a target user, if the health of its long connection is lower than the first threshold, a degradation strategy is executed. The degradation strategy includes at least: pushing only high-priority messages and reducing the message push frequency.

[0019] By adopting the above technical solution and quantifying connection health, the system can identify connections with poor network conditions. Degradation strategies (such as rate limiting and caching) are implemented for these connections, avoiding numerous destined-to-fail or inefficient push attempts on unreliable links, significantly saving server-side computing, network, and I / O resources. In weak network environments, priority is given to delivering high-priority critical messages, while non-urgent messages are delayed or asynchronously retrieved, which aligns with user expectations. Simultaneously, the saved resources are used to serve users with healthy connections, achieving intelligent and fair allocation of system resources among users with connections of different quality, thus improving overall service efficiency.

[0020] Secondly, this application provides a SaaS system message push system based on message queues, including multiple microservice instances and a message publishing module; Each microservice instance is configured with: The long connection management module is used to maintain the corresponding local long connection pool, which is used to record user information that has established a long connection with the corresponding microservice instance. The message consumption module is used to subscribe to one or more message topics in the message queue and receive messages sent to the subscribed topics; The message publishing module is used to publish the message to the message queue and the message topic corresponding to the identification information when the business service generates a message that needs to be pushed to the target user, based on the identification information of the tenant to which the target user belongs; The message consumption module is further configured to, upon receiving the message, call the long connection management module to query the local long connection pool to determine whether the current microservice instance has a long connection with the target user; if a long connection is determined to exist, the message is pushed to the target user through the long connection, and the message is confirmed to be consumed by the message queue; if a long connection is determined not to exist, the message is discarded or ignored.

[0021] Thirdly, this application provides a message push device for a SaaS system based on a message queue, including a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any of the methods in the first aspect.

[0022] Fourthly, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor and execute the method described in any of the first aspects.

[0023] In summary, this application includes at least one of the following beneficial technical effects: In this application, by utilizing the publish-subscribe mechanism of a message queue, precise broadcasting and routing of messages between different microservice instances can be achieved. When a long-lived connection exists between a microservice and a user, messages can be effectively consumed and sent to the user through the long-lived connection channel. This ensures that messages reach the service instance where the user resides, avoiding message loss or delivery to the wrong instance.

[0024] Furthermore, by using a message queue system in the microservice architecture, the real-time performance of message delivery is significantly improved. Once a message is published, it can be immediately broadcast to all microservice instances, and timely message consumption and push can be achieved based on the user's connection status, reducing latency and meeting the real-time communication needs in high-concurrency scenarios.

[0025] Because this application relies on a distributed message queue system, it can maintain good scalability even as the number of microservice instances and tenants increases. Regardless of how many microservice nodes or tenants are added to the system, the architecture of this invention can ensure that messages are effectively broadcast and consumed, thereby supporting large-scale system expansion.

[0026] Furthermore, a significant advantage of this application is improved system resource utilization. Messages are only consumed when a long-lived connection to the target user exists within the microservice instance, thus avoiding unnecessary message processing and pushing. This mechanism reduces the propagation and processing of redundant messages, lowers system load and bandwidth consumption, and optimizes resource utilization. Attached Figure Description

[0027] 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.

[0028] Figure 1 This is a flowchart illustrating the message push method for a SaaS system based on a message queue disclosed in an embodiment of this application.

[0029] Figure 2 This is a structural block diagram of a SaaS message push system based on message queues disclosed in an embodiment of this application. Detailed Implementation

[0030] The following is in conjunction with the appendix Figures 1-2 This application will be described in further detail.

[0031] This application discloses a message push method for a SaaS system based on a message queue (hereinafter referred to as the message push method). The execution entity of the message push method is a message push system for a SaaS system based on a message queue (hereinafter referred to as the message push system), which includes a message queue and multiple microservice instances. The following will combine... Figure 1 This section details the specific process by which the message push system executes the message push method.

[0032] S101, Each microservice instance maintains a corresponding local long connection pool, which is used to record user information that has established a long connection with the corresponding microservice instance; S102, When a business service generates a message that needs to be pushed to the target user, the message is published to the message queue and the message topic corresponding to the identification information according to the identification information of the tenant to which the target user belongs; S103, the microservice instance that subscribed to the message topic corresponding to the target user receives the message, and after receiving the message, queries its own local long connection pool to determine whether there is a long connection with the target user; S104, If a long connection exists, the corresponding microservice instance will push the message to the target user and confirm the consumption of the message; S105 If no long-lived connection exists, the corresponding microservice instance will discard or ignore the message.

[0033] In implementation, this embodiment is implemented in a typical SaaS multi-tenant instant messaging (IM) system. This system adopts a microservice architecture, mainly including: a user management service, a chat service, a message push microservice cluster (containing multiple instances), and a distributed message queue (such as Apache Kafka or RabbitMQ). User clients (Web or App) maintain a long-lived connection with the message push microservice instances via the WebSocket protocol.

[0034] For S101, the implementation principle is as follows: Each message push microservice instance initializes a long-connection management module in its local memory upon startup. The core of this module is a thread-safe hash table (e.g., ConcurrentHashMap in Java) serving as a local long-connection pool. The specific actions for maintaining this local long-connection pool include: 1. Connection Registration: When a user client (e.g., user B) successfully establishes a WebSocket connection with a microservice instance (e.g., instance P2), the long-connection management module of instance P2 immediately inserts a record into the local long-connection pool. The key of this record can be a "user identifier," and the value is a structure containing a connection session object and metadata. The specific form of the user information includes at least: a user identifier (a string used to uniquely identify the user, such as "user_B" or the numeric ID "1001"), a tenant identifier (a string used to uniquely identify the tenant to which the user belongs, such as "tenant_T" or "company_A"), a connection session object (an object reference representing the physical network connection (e.g., a Channel object in the Netty framework), used for subsequent message pushes), and may also include the connection establishment time, last active timestamp, etc.

[0035] 2. Connection Keep-Alive and State Maintenance: A heartbeat mechanism is established between the server and the client. Instance P2 periodically (e.g., every 30 seconds) sends a heartbeat packet to user B via a WebSocket connection and expects a response. If no response is received within a preset time (e.g., 90 seconds), the connection is considered invalid.

[0036] 3. Connection cleanup: When a user is detected to have actively disconnected (e.g., a close frame is received) or the heartbeat times out and the connection is determined to be invalid, the long connection management module of instance P2 will immediately delete the record with the key "user_B" from the local long connection pool and release the related resources.

[0037] For S102, the implementation principle is as follows: In the message push system described in this application, any business scenario requiring real-time message push to end users is handled by a corresponding, single-responsibility backend service. The determination of the business service follows the preset rules of the system architecture: The message push system API gateway routes the request to the corresponding business service based on the same resource identifier (URI) path and / or request type of the client request. When an end user (such as user A) performs an operation on the client (such as sending a chat message, submitting an approval request, or triggering a system alarm), the client sends a specific HTTP / RPC request to the system backend. After being routed by the API gateway, this request will definitely reach the business service responsible for handling the business logic (for example, a request to send a chat message is routed to the chat business service; a request to submit an approval request is routed to the workflow engine service). After completing its core business logic (such as data verification, status update, persistent storage, etc.), if its business process includes the need to send real-time notifications to specific users, then the business service will act as a message producer and trigger the message push process of this application. Therefore, the business service does not refer to a specific service, but to any microservice in the message push system that needs to trigger real-time push.

[0038] When preparing to publish a push message, a business service must determine the target user and their associated tenant. The specific implementation principle is as follows: the business service can directly obtain the unique identifier of the target user from the business context it has processed. For example, in a chat scenario, the target user identifier comes from the message recipient field; in an approval scenario, it comes from the applicant or approver field. To obtain the tenant identification information of the target user, the push message system maintains user-tenant mapping relationship data. This data typically exists in two ways and is available for querying: Method 1 (Centralized Caching): During message push system initialization or user login, the mapping relationship between user identifier and tenant identifier is loaded into a globally shared distributed cache (such as Redis). Business services can obtain the tenant identifier corresponding to the target user by querying this cache.

[0039] Method 2 (Local Query): The business service directly queries the data tables or databases that it can access and that store user information, and retrieves the tenant identifier of the target user from the user's profile records.

[0040] The message push system uses a predefined topic naming rule that is bound to a tenant. For example, the rule is: "message.push.tenant." + [tenant identifier]. After obtaining the tenant identifier (e.g., "tenant_T"), the business service dynamically generates a specific message topic name according to this rule: "message.push.tenant.tenant_T". This topic is the message topic corresponding to the tenant's identification information.

[0041] Finally, the business service publishes the constructed push message (the message body must at least contain the target user identifier and message content) to the aforementioned topic ("message.push.tenant.tenant_T") in the message queue. After publication, the business service's responsibility is complete, and the message queue and message push microservice cluster will be responsible for subsequent distribution and push.

[0042] The implementation principle of step S103 is as follows: In the initial stage of the message push system's operation, all microservice instances (P1, P2, P3...) have subscribed to message topics related to the tenants they serve, based on their service configurations, upon startup. In this embodiment, assuming instances P1, P2, and P3 have all subscribed to the topic "push.topic.tenant.tenant_T", when a message is published to this topic, the message queue will push (broadcast) this message to instances P1, P2, and P3. Instances P1, P2, and P3 will each receive a copy of this message.

[0043] For step S104, the implementation principle is as follows: after receiving the message, each microservice instance performs the following operations in parallel: S1041: Parse the message and obtain the target user identifier (e.g., "user_B").

[0044] S1042: Query the local long-lived connection pool (i.e., the local ConcurrentHashMap) to check if a record with the key "user_B" exists.

[0045] S1043: If found (as in example P2), obtain its associated WebSocket connection session object. Using the WebSocket connection session object obtained from the local pool, actively push the message content to user B's client. After successful push, send an acknowledgment of consumption to the message queue, which then marks the message as successfully processed and removes it from the instance's subscription queue.

[0046] If the message is not found (e.g., in instances P1 and P3), it is simply discarded or ignored. Under the semantics of some message queues (such as Kafka), they may also automatically commit offsets, which is equivalent to acknowledging consumption, but without performing any push operations.

[0047] Thus, a real-time message from user A to user B was accurately and instantly pushed, provided that user B's long connection only exists on instance P2. Messages from other users in the same tenant (such as user C, if their connection is on instance P1) will also be broadcast through the same "push.topic.tenant.tenant_T" topic and consumed locally by their respective instances, achieving efficient and accurate distributed message routing.

[0048] Optionally, message push methods also include: S201 generates interest profiles for each user based on their historical message consumption data.

[0049] S202, based on interest profiles, dynamically classify users with similar interest profiles within the same microservice instance into different virtual interest groups; wherein, each virtual interest group is associated with a specific message subtopic, and the message subtopic belongs to a message topic named with the tenant's identification information.

[0050] The step S102, "Publishing the message to the message queue with the message subject corresponding to the identification information," includes the following sub-steps: S1021, based on the message type, publish the message to the message subtopic corresponding to the virtual interest group to which the target user belongs in the message queue.

[0051] S103 includes the following steps: A microservice instance that has subscribed to a message subtopic receives the message and, after receiving the message, queries whether the target user exists in the virtual interest group associated with the message subtopic. If it does, it is considered that a long connection exists with the target user.

[0052] S104 includes the following sub-steps: The microservice instance that has a long-lived connection with the target user is selected as the target microservice instance. The target microservice instance performs load-aware routing decision-making, which includes the following steps: S1041, Obtain the real-time load status of the target user within the target microservice instance and the virtual interest groups to which they belong; S1042, Based on the real-time load status, select the target virtual interest group with the best load from the virtual interest groups to which the target user belongs; S1043: Encapsulate internal routing metadata for the message to generate an internal routing message. The internal routing metadata includes at least the target virtual interest group identifier. Deliver the internal routing message to the internal service queue corresponding to the target virtual interest group identifier within the target microservice instance. Listen to and consume the internal service queue to obtain the internal routing message. Parse the internal routing message to obtain the corresponding target user identifier. Based on the target user identifier, query the local long connection pool to obtain the corresponding long connection, and push the original message content in the internal routing message to the target user through the long connection.

[0053] Correspondingly, the message push method also includes the following steps: S301 continuously monitors users' real-time behavior data and dynamically updates the corresponding user's interest profile based on the real-time behavior data.

[0054] S302, whenever any user's interest profile is updated and the corresponding update instruction requires the user to be added to a new virtual interest group, the corresponding user is designated as the first user and added to the new virtual interest group.

[0055] S303, if there are currently messages targeting the first user, then a transition strategy is executed. The transition strategy includes: temporarily marking the message subtopic associated with the newly added virtual interest group of the first user as the first user's transitional subtopic; establishing a transitional message buffer corresponding to the first user and the transitional subtopic to temporarily store messages sent to the transitional subtopic and targeted at the first user; after the operation of adding the first user to the new virtual interest group is completed, consuming the messages temporarily stored in the transitional message buffer, and pushing messages to the first user by executing a load-aware routing strategy.

[0056] In practice, this application further reveals the implementation principle of the complete optimization scheme consisting of interest profiling, virtual grouping, intelligent routing, and dynamic protection mechanisms.

[0057] The first phase (interest profiling and virtual group optimization) is implemented based on the following principles: Within each message push microservice instance, in addition to the long-connection management module, a lightweight user interest analysis service also runs. This service consumes aggregated and anonymized user historical message consumption logs (e.g., synchronized from log streams or data warehouses), employing a configurable rule engine combined with sliding time window statistics to build and periodically update an interest profile for each active user. Its specific construction logic is as follows: The message push system predefines a series of interest tags and their corresponding triggering rules, for example: The tag "Order Notification" has the rule that "the user has consumed messages of type 'ORDER_STATUS_CHANGE' in the past 7 days".

[0058] The tag "System Announcement" has the rule that "users click on or consume 'ANNOUNCEMENT' type messages more than 3 times in the past 24 hours".

[0059] The tag "Team Chat" has the following rule: "A user has exchanged more than 10 messages in chat sessions prefixed with 'TEAM_' within the last hour."

[0060] The interest analytics service maintains a sliding time window-based counter. It processes user consumption events (such as message openings, clicks, and messages in a conversation) in real time and accumulates user behavior counts across different tag dimensions according to predefined rules. Periodically (e.g., every 5 minutes), the service evaluates the statistical data for each user. If a user's behavior count for a tag meets or exceeds the threshold of its corresponding rule, that tag is activated and added to the user's current interest profile. Simultaneously, the system can calculate a weight score (e.g., between 0 and 1.0) for the tag based on the behavior count (e.g., number of clicks) or a time decay function (e.g., more recent behaviors have higher weights) to quantify the intensity of interest. The generated interest profile (containing a set of tags and their weights, e.g., {"Order Notification": 0.9, "System Announcement": 0.7, "Team Chat": 0.8}) is stored in a local cache on the microservice instance (e.g., Guava Cache or Caffeine), with the user identifier as the key, and is updated when a new user behavior event occurs.

[0061] Based on the interest profiles of all online users within the microservice instance, the message push system performs dynamic virtual interest grouping logic. The grouping rules can be simple tag matching (e.g., users with the tag "Order Notification" are grouped into the "Order Group"), or more complex clustering algorithms. Each virtual interest group is represented as a set of user identifiers within the microservice instance. A key design feature is that each virtual interest group is pre- and statically bound to a unique message subtopic. This subtopic is derived from the tenant topic, with a naming convention such as: {tenant topic}.sub.{group identifier}. For example, the "Order Group" under tenant_T might be associated with the following subtopics: message.push.tenant.tenant_T.sub.order.

[0062] Therefore, when a user comes online and their long connection is carried by a microservice instance (such as instance P2), the microservice instance not only registers the user in its local connection pool, but also adds the user's identifier to the member list of one or more corresponding virtual interest groups within the microservice instance based on the user's interest profile. For example, a user interested in both orders and chat will appear in the local member lists of both the "Orders Group" and the "Chat Group" of instance P2.

[0063] The direct effect of this mechanism is that the granularity of message publishing and subscription is refined from the tenant level to the interest level. Business services can publish messages to corresponding interest subtopics (such as .sub.order) based on their business type (such as "order status update"), rather than generalized tenant topics. Microservice instances, on the other hand, achieve more precise "signal reception" by subscribing to all interest subtopics involved in their service users.

[0064] The second phase (steady-state message push process) is implemented in the following principle: When a business service generates a message that needs to be pushed, the business service performs a precise mapping process from message type to subtopic, as follows: When processing their core business logic, business services assign a clear, predefined message type identifier to the message to be pushed, based on the message content or the business event that triggered the message generation. For example, in the order service, a notification that "order has been shipped" can be identified as ORDER_SHIPPED. In the approval service, a notification that "your leave application has been approved" can be identified as APPROVAL_PASSED. In the chat service, a regular text message can be identified as CHAT_TEXT.

[0065] The push notification system maintains a globally shared or service-embedded mapping configuration. This configuration defines the mapping relationship from "message type identifier" to "message subtopic suffix". Mapping rules can be statically configured or dynamically distributed through a configuration center. For example: ORDER_SHIPPED → maps to the subtopic suffix "order"; APPROVAL_PASSED → maps to the subtopic suffix "approval"; CHAT_TEXT → maps to the subtopic suffix "chat".

[0066] After determining the message type identifier and completing its own logic, the business service performs the following steps to determine the final publication address: Step 1: Obtain the tenant identifier of the target user. This step is the same as S102, obtained by querying the user-tenant mapping relationship (e.g., tenant_T).

[0067] Step 2: Apply subtopic naming rules. The message push system uses a predefined, structured naming rule to generate complete message subtopic names. A typical rule is: {tenant-level topic prefix}.sub.{subtopic suffix}.

[0068] Step 3: Generate and Publish. The business service combines the tenant identifier obtained in Step 1 with the subtopic suffix mapped in Step 2 to dynamically construct the complete target message subtopic. For example, for the ORDER_SHIPPED message of tenant_T, the constructed subtopic is: message.push.tenant.tenant_T.sub.order.

[0069] Subsequently, the business service publishes the constructed push message (the message body contains at least the target user identifier and message content, and the message header or attributes may carry the message type identifier ORDER_SHIPPED for optional use in subsequent steps) to the target subtopic in the message queue.

[0070] Microservice instances that have subscribed to this message's subtopic will receive this message. Upon receiving it, the microservice instance will execute the following matching logic: Parse the message to obtain the target user identifier, and query the local member list of virtual interest groups associated with this message's subtopic. If the target user identifier exists in the list, then this microservice instance is determined to be the target microservice instance, and it is confirmed that it holds a long connection to the target user.

[0071] Once a microservice instance is identified as the target instance, it does not immediately perform a push notification. Instead, it enters a load-aware routing decision phase driven by the instance's load-aware routing decision module (hereinafter referred to as the "routing decision maker"). This routing decision maker is a local software component initialized at startup for each microservice instance. Its core responsibility is to select the optimal processing path for messages based on real-time system status. The specific implementation principle of load-aware routing decision is as follows: The routing decision-maker first queries the user-virtual interest group mapping table maintained by this instance (this table was created and maintained in the interest grouping step described above). Using this table, the decision-maker obtains a list of all virtual interest group identifiers to which the target user belongs within the current instance. For example, the query reveals that the target user simultaneously belongs to the "Order Processing Group," the "System Announcement Group," and the "Instant Chat Group."

[0072] Each virtual interest group (FIG) is bound to one or more dedicated message processing threads (or coroutines / asynchronous task queues) within the microservice instance. To monitor load in real time, the messaging system maintains a set of key local performance metrics for each FIG. These metrics are collected through the following mechanisms: Queue monitoring: Each group's associated internal service queue (such as LinkedBlockingQueue) provides a size() or similar method to directly obtain the number of messages currently pending. The routing decision-maker obtains the core load metric of the number of pending tasks in real time by calling these methods or listening for queue length change events.

[0073] Resource Metrics: For more complex load assessments, microservice instances can integrate lightweight performance metric libraries (such as Micrometer). Each group's dedicated processing thread can report its CPU time slice usage and average processing time over a recent period to a shared in-memory data structure (such as a ConcurrentHashMap, where the key is the group identifier and the value is a metric snapshot). The routing decision-maker reads these metrics from this data structure periodically or on demand.

[0074] Healthy Heartbeat: Each processing thread periodically reports its "active" status to a centralized coordinator (or directly sets a flag in shared memory). The decision-maker can indirectly assess the saturation or abnormal state of the group processing capacity by judging the delay or timeout of the thread's response to the heartbeat.

[0075] When a decision is triggered, the routing decision-maker synchronously or retrieves from the local cache the real-time load metrics of each group to which the target user belongs, which were maintained in the above steps. It sorts and compares these groups according to a preset routing strategy algorithm (e.g., "always select the group with the fewest pending tasks" or "the group with the lowest weighted score based on the combined queue length and the most recent average time consumption").

[0076] Ultimately, the routing decision-maker outputs a unique target virtual interest group (VOP) identifier, which points to the VOP determined to be the most load-optimized at the current moment. This selection may differ from the original group associated with the sub-message topic of the message source (i.e., the target VOP is not necessarily the VOP associated with the sub-message topic related to the message type). For example, a message pushed to the target user might be an order message, but because the associated "order group" is busy, it might be chosen to be processed by the currently idle "chat group." The message will be routed to the target VOP for processing, not necessarily the group corresponding to its original business type.

[0077] After selecting a target virtual interest group, the internal routing mechanism (corresponding to S1043) is executed: the message push system encapsulates the message into an internal routing message, which contains at least two key fields: targetUserId (target user identifier) ​​and targetGroupId (target virtual interest group identifier). The encapsulated message is delivered to the internal service queue corresponding to the target virtual interest group (e.g., a LinkedBlockingQueue instance). It should be noted that each virtual interest group is handled by one or more dedicated consumer threads within the microservice instance. These consumer threads continuously monitor their respective internal service queues. When the consumer thread of the "chat group" retrieves the aforementioned internal routing message from the queue, it parses the targetUserId, then queries the local long-connection pool (this step is consistent with the content described in S1043) to obtain the user's WebSocket connection session object, and finally pushes the message content to the target user client through this connection. This internal routing mechanism achieves elastic scheduling and decoupling of processing capabilities within the instance.

[0078] The third phase (dynamic updating of interest profiles and transition assurance) is implemented based on the following principles: A user's interest profile is not static. The interest analytics service within the microservice instance continuously receives real-time user behavior feedback (such as clicks or browsing specific types of messages) and updates its interest profile asynchronously accordingly. When an update necessitates adding the user to a new virtual interest group (e.g., the user develops a new "promotion" interest and needs to be added to the "promotion group"), the push notification system performs a two-phase (preparation phase, execution and backfilling phase) atomic commit operation to ensure no messages are lost. During the preparation phase, before adding a user to a new virtual interest group, the push notification system first temporarily marks the message subtopic (e.g., .sub.promo) associated with this new virtual interest group as a transitional subtopic for that user. Simultaneously, a temporary buffer (e.g., a ConcurrentLinkedQueue) is created in the microservice instance's memory, identified jointly by the user's identifier and the sub-message topic.

[0079] During the execution and backfilling phase: The push notification system formally adds the user identifier to the new virtual interest group member list. Crucially, within the time window between the completion of the preparation phase and the successful completion of the execution and backfilling phase, if a new message targeting the user arrives at this microservice instance and is sent to the ".sub.promo" sub-message topic, the message will not be incorrectly discarded (because the user has not yet been formally added to the new virtual interest group), but will be intercepted and temporarily stored in the aforementioned temporary buffer. Once the user (i.e., the first user) is successfully added to the new group, the push notification system will immediately retrieve all messages from the temporary buffer and use them as input, re-processing them in the aforementioned load-aware routing decision-making process to push them to the first user, thereby ensuring the continuity of the message flow during the user's interest state migration.

[0080] Optionally, load-aware routing decisions also include: Based on the historical load data of each virtual interest group, predict its load trend for a future preset time period; The step of selecting the target virtual interest group with the optimal load from the virtual interest groups to which the target user belongs, based on the real-time load status, includes: Based on the real-time load status and the predicted load trend, the target virtual interest group with the optimal overall load is selected from the virtual interest groups to which the target user belongs.

[0081] In implementation, during the load-aware routing decision-making process, the routing decision-maker can also integrate a lightweight time-series prediction module. This submodule continuously collects and maintains historical load time-series data for each virtual interest group (VAP). The core collection metric is the length of the service queue within each group, sampled at fixed time intervals (e.g., per second) to form a data sequence within a sliding time window. When routing decisions are required, the prediction submodule, for each candidate VAP belonging to the target user, uses a pre-defined prediction algorithm to predict the load in the next short term (the next sampling period or the next second) based on its latest queue length sequence. The prediction algorithm can be an easily implemented first-order exponential smoothing method. Its calculation process is briefly described as follows: Let S_t be the predicted value (i.e., the smoothed value) at time t, Y_t be the actual observed value (queue length) at time t, and α be the smoothing coefficient (0 < α < 1, configurable). The prediction formula is: S_t+1 = α * Y_t + (1-α) * S_t. S_t+1 is the predicted load value for the next time step. The algorithm only needs to store the previous period's predicted value S_t and the current period's observed value Y_t, resulting in minimal computational overhead.

[0082] The routing decision-maker combines the current real-time load with the predicted future load to form a comparable "comprehensive load assessment." A specific quantification method is as follows: For each candidate group, obtain its current queue length (L_now) and predicted queue length (L_pred). Divide L_now and L_pred by a preset queue capacity reference value (such as the size of the processing thread pool for this group multiplied by a coefficient) to obtain the normalized current load factor F_now and predicted load factor F_pred. Using a configurable weight β (0≤β≤1), calculate the comprehensive load value Score = β*F_now + (1-β)*F_pred. The closer the β value is to 1, the more the decision is biased towards the current situation; the closer it is to 0, the more the decision is biased towards the look-ahead prediction. The routing decision-maker calculates the Score value of all candidate groups and selects the group with the smallest Score value as the final target virtual interest group.

[0083] Optionally, the message push method may also include the following steps: When each microservice instance maintains its corresponding local long-lived connection pool, it also monitors and records the real-time health indicators of each long-lived connection. When a message needs to be pushed to a target user, if the health of its long connection is lower than the first threshold, a degradation strategy is executed. The degradation strategy includes at least: pushing only high-priority messages and reducing the message push frequency.

[0084] In implementation, during the maintenance of the local long-lived connection pool corresponding to the microservice instance, a fine-grained monitoring and adaptive handling mechanism for connection quality can be introduced, as follows: In the original heartbeat keep-alive mechanism, the long-connection management module records the round-trip latency of each heartbeat interaction and maintains the heartbeat success rate within a time window (e.g., the most recent 10 heartbeats). The long-connection management module periodically (e.g., every 5 heartbeats) calculates a dynamic health score for each connection. A specific calculation model is as follows: a baseline latency D_base (e.g., 100ms) and a maximum tolerable latency D_max (e.g., 1000ms) are set. The latency score S_delay = max(0, 1 - (average latency - D_base) / (D_max - D_base)). A score of 1 is awarded when the average latency is less than D_base, and 0 is awarded when it exceeds D_max. The success rate score S_success = number of successful heartbeats in the most recent window / total number of heartbeats. The overall health score Health_Score = w1 * S_delay + w2 * S_success, where w1 and w2 are configurable weights, and w1 + w2 = 1. Health_Score is a value between 0 and 1, with a higher value indicating a healthier connection.

[0085] When a microservice instance (target instance) finds a connection for the target user in its local long-connection pool, the long-connection management module or an associated push preprocessing module will first check the Health_Score stored in the connection record. The push system has at least two default degradation thresholds (e.g., Threshold_Low=0.3, Threshold_High=0.6).

[0086] If Health_Score ≥ Threshold_High: The connection is healthy, and messages are pushed according to the normal process (such as combining subsequent load-aware routing decisions).

[0087] If Threshold_Low ≤ Health_Score < Threshold_High: A minor degradation is triggered. In this case, the message push execution unit within the instance will prioritize the messages.

[0088] If Health_Score < Threshold_Low: A severe degradation is triggered. The message push execution unit will suspend real-time push notifications through this connection.

[0089] The message priority marking mechanism works as follows: the "high priority" of a message is not marked by the message push system at runtime, but is defined at its source. Specifically, when a business service publishes a message to the message queue, it sets a priority identifier (such as priority: HIGH or priority: NORMAL) in the message's attributes or header information based on the message's urgency and business importance. This is part of the business logic.

[0090] The specific actions of the downgrade strategy: Mild Degradation: When the connection is in a mildly degraded state, the message push execution unit parses the priority identifier of the message. Only when the message is identified as "high priority" will the subsequent intelligent routing and push process be executed immediately; for messages identified as "normal priority", they are placed in a delayed sending queue and sent in batches after the connection health recovers or a certain number are accumulated.

[0091] Severe Degradation: When the connection is in a severely degraded state, the message push execution unit abandons real-time push attempts and instead persistently stores information such as message content and target user identifier in the user's offline message database. At the same time, it notifies the client that there are offline messages to be retrieved through an independent, low-overhead control channel (e.g., carrying a flag in the next successful heartbeat response packet).

[0092] This solution enables the push notification system to intelligently protect its own resources and ensure critical communications when network conditions deteriorate, through quantitative health assessment and adaptive degradation based on business priorities. It also guides users to obtain messages in a more network-friendly way (such as by pulling), thereby maintaining service resilience and user experience in complex network environments.

[0093] This application also discloses a SaaS message push system based on message queues. (See also...) Figure 2 It includes multiple microservice instances and a message publishing module: Each microservice instance is configured with: The long connection management module is used to maintain the corresponding local long connection pool, which records the user information that has established a long connection with the corresponding microservice instance. The message consumption module is used to subscribe to one or more message topics in the message queue and receive messages sent to the subscribed topics; The message publishing module is used to publish messages to the message queue and the message topic corresponding to the identification information when the business service generates a message that needs to be pushed to the target user, based on the identification information of the tenant to which the target user belongs; The message consumption module is also used to call the long connection management module to query the local long connection pool after receiving a message, in order to determine whether the current microservice instance has a long connection with the target user; if a long connection is found, the message is pushed to the target user through the long connection and the message consumption is confirmed to the message queue; if no long connection is found, the message is discarded or ignored.

[0094] This application also discloses a message push device for a SaaS system based on a message queue. The message push device for a SaaS system based on a message queue includes a memory and a processor. The memory stores a computer program that can be loaded by the processor and executed as described above for the message push method for a SaaS system based on a message queue.

[0095] This application also discloses a computer-readable storage medium that stores a computer program that can be loaded by a processor and executed as described above for a message push method for a SaaS system based on a message queue. The computer-readable storage medium includes, for example, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0096] It should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0097] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit the scope of protection of the application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on these embodiments, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

Claims

1. A message push method for a SaaS system based on a message queue, wherein the execution entity of the method is a message push system for a SaaS system based on a message queue, the system comprising a message queue and multiple microservice instances, characterized in that, The method includes: Each microservice instance maintains a corresponding local long-connection pool, which is used to record user information that has established a long connection with the corresponding microservice instance. When a business service generates a message that needs to be pushed to a target user, the message is published to the message queue and the message topic corresponding to the identification information according to the identification information of the tenant to which the target user belongs; The microservice instance that has subscribed to the message topic corresponding to the target user receives the message and, after receiving the message, queries its own local long connection pool to determine whether a long connection exists with the target user. If a long-lived connection exists, the corresponding microservice instance will push the message to the target user and confirm the consumption of the message; If no long-lived connection exists, the corresponding microservice instance will discard or ignore the message.

2. The message push method for a SaaS system based on a message queue according to claim 1, characterized in that, The method further includes: Based on users' historical message consumption data, interest profiles are generated for each user. Based on the interest profile, users with similar interest profiles within the same microservice instance are dynamically categorized into different virtual interest groups; wherein each virtual interest group is associated with a specific message subtopic, and the message subtopic belongs to a message topic named with the tenant's identification information; The message topic corresponding to the identification information, which is published to the message queue, includes: Based on the type of the message, the message is published to the message subtopic in the message queue that corresponds to the virtual interest group to which the target user belongs; The microservice instance that has subscribed to the message topic corresponding to the target user receives the message and, after receiving the message, queries its own local long-connection pool to determine whether a long connection exists with the target user, including: A microservice instance that has subscribed to the message subtopic receives the message and, after receiving the message, queries whether the target user exists in the virtual interest group associated with the message subtopic. If it exists, it is considered that there is a long connection with the target user.

3. The message push method for a SaaS system based on a message queue according to claim 2, characterized in that, The same user can belong to multiple different virtual interest groups; If a long-lived connection exists, the corresponding microservice instance will push the message to the target user, including: The microservice instance that has a long-lived connection with the target user is selected as the target microservice instance. The target microservice instance performs load-aware routing decision, which includes the following steps: Obtain the real-time load status of the target user within the target microservice instance and its respective virtual interest groups; Based on the real-time load status, select the target virtual interest group with the optimal load from among the virtual interest groups to which the target user belongs; The message is delivered to the target user by a virtual interest group.

4. The message push method for a SaaS system based on a message queue according to claim 3, characterized in that, The method further includes: Continuously monitor users' real-time behavior data and dynamically update the corresponding user's interest profile based on the real-time behavior data; Whenever a user's interest profile is updated and the corresponding update indicates that the user should be added to a new virtual interest group, the corresponding user is designated as the first user and added to the new virtual interest group. If a message with the first user as the target user already exists, a transition strategy is executed, the transition strategy including: The message subtopic associated with the newly added virtual interest group of the first user is temporarily marked as the transitional subtopic of the first user; a transitional message buffer corresponding to the first user and the transitional subtopic is established to temporarily store messages sent to the transitional subtopic and received by the first user; after the operation of adding the first user to the new virtual interest group is completed, the messages temporarily stored in the transitional message buffer are consumed, and messages are pushed to the first user by executing the load-aware routing strategy.

5. The message push method for a SaaS system based on a message queue according to claim 3 or 4, characterized in that, The step of delivering the message to the target user via the target virtual interest group includes: Encapsulate the message with internal routing metadata to generate an internal routing message. The internal routing metadata includes at least a target virtual interest group identifier. The internal routing message is delivered to the internal service queue within the target microservice instance that corresponds to the target virtual interest group identifier. The system listens to and consumes the internal service queue to obtain the internal routing message, parses the internal routing message to obtain the corresponding target user identifier, queries the local long connection pool based on the target user identifier to obtain the corresponding long connection, and pushes the original message content in the internal routing message to the target user through the long connection.

6. The message push method for a SaaS system based on a message queue according to claim 5, characterized in that, The load-aware routing decision also includes: Based on the historical load data of each virtual interest group, predict its load trend for a future preset time period; The step of selecting the target virtual interest group with the optimal load from the virtual interest groups to which the target user belongs, based on the real-time load status, includes: Based on the real-time load status and the predicted load trend, the target virtual interest group with the optimal overall load is selected from the virtual interest groups to which the target user belongs.

7. The message push method for a SaaS system based on a message queue according to claim 2, characterized in that, The method further includes: When each microservice instance maintains its corresponding local long-lived connection pool, it also monitors and records the real-time health indicators of each long-lived connection. When a message needs to be pushed to a target user, if the health of its long connection is lower than the first threshold, a degradation strategy is executed. The degradation strategy includes at least: pushing only high-priority messages and reducing the message push frequency.

8. A SaaS message push system based on message queues, characterized in that, Includes multiple microservice instances and a message publishing module; Each microservice instance is configured with: The long connection management module is used to maintain the corresponding local long connection pool, which is used to record user information that has established a long connection with the corresponding microservice instance. The message consumption module is used to subscribe to one or more message topics in the message queue and receive messages sent to the subscribed topics; The message publishing module is used to publish the message to the message queue and the message topic corresponding to the identification information when the business service generates a message that needs to be pushed to the target user, based on the identification information of the tenant to which the target user belongs; The message consumption module is further configured to, upon receiving the message, call the long connection management module to query the local long connection pool to determine whether the current microservice instance has a long connection with the target user; if a long connection is determined to exist, the message is pushed to the target user through the long connection, and the message is confirmed to be consumed by the message queue; if a long connection is determined not to exist, the message is discarded or ignored.

9. A message push device for a SaaS system based on a message queue, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 7.

Images