Multi-process SSE long connection management method and device, equipment and storage medium

Abstract

This invention provides a multi-process SSE long-connection management method, apparatus, device, and storage medium, relating to the fields of real-time communication and distributed computing technologies. The method includes: configuring an independently managed local server-side push event SSE connection pool for each worker process, wherein the local SSE connection pool manages one or more SSE long connections; in response to receiving a business message to be pushed, obtaining the currently configured push mode; if the push mode is a first mode, broadcasting the business message to all worker processes through an inter-process message synchronization middleware, so that each worker process searches for and pushes the business message to a matching connection from the local SSE connection pool; if the push mode is a second mode, pushing is only performed in the local SSE connection pool of the source worker process that generated the business message, thereby ensuring the consistency and flexibility of SSE long-connection message pushing in a multi-process environment.

Description

Technical Field

[0001] This invention relates to the fields of real-time communication and distributed computing technology, and in particular to a multi-process SSE long-connection management method, apparatus, device and storage medium. Background Technology

[0002] With the increasing demand for real-time push capabilities in web applications, Server-SentEvents (SSE), as a lightweight server-side push technology, is widely used in scenarios such as message notifications, artificial intelligence (AI) dialogue, and data monitoring. Node.js, as the mainstream backend framework for high-concurrency web services, typically employs a multi-process cluster mode, such as Process Manager 2 (PM2), to fully utilize multi-core server resources. In existing technologies, SSE long-lived connections are usually maintained by a single Node.js process, or each process independently manages its own SSE connection in a multi-process environment. To achieve consistent message push in a multi-process environment, some solutions introduce middleware such as Redis for inter-process message synchronization, or use load balancers to achieve connection stickiness.

[0003] However, in a Node.js multi-process cluster environment, when multiple worker processes independently manage SSE long connections, it is difficult for the business messages pushed by the server to be correctly pushed to the worker process where the target client is located. Summary of the Invention

[0004] This invention provides a multi-process SSE long connection management method, apparatus, device, and storage medium to solve the defect in the prior art that the business messages pushed by the server are difficult to be correctly pushed to the working process of the target client in a multi-process cluster environment, and to achieve consistency and flexibility of SSE long connection message push in a multi-process environment.

[0005] This invention provides a multi-process SSE long-connection management method, applicable to a multi-process cluster including at least two worker processes, comprising the following steps: Configure an independently managed local server push event SSE connection pool for each worker process, and the local SSE connection pool manages one or more SSE long connections; In response to receiving a business message to be pushed, obtain the currently configured push mode; If the push mode is the first mode, the business message is broadcast to all worker processes through the inter-process message synchronization middleware, so that each worker process can find and push the business message to the matching connection from the local SSE connection pool; if the push mode is the second mode, the push is only performed in the local SSE connection pool of the source worker process that generated the business message.

[0006] In some embodiments, if the push mode is a first mode, the method further includes: Perform a health check on the inter-process message synchronization middleware; When an anomaly is detected in the inter-process message synchronization middleware, the push mode is switched to the second mode.

[0007] In some embodiments, it also includes: Obtain server resource load metrics and / or the total number of current SSE connections; When the resource load index or the current total number of SSE connections meets the preset expansion conditions, a new working process is added, and the newly added SSE connection requests are allocated to the new working process. When the resource load index or the current total number of SSE connections meets the preset scaling-down conditions, at least one worker process to be destroyed is terminated, and before termination, the SSE connections on the worker process to be destroyed are migrated or rebuilt to one or more other worker processes.

[0008] In some embodiments, the inter-process message synchronization middleware is Redis's publish / subscribe mechanism or a message queue system; When broadcasting the business message through the inter-process message synchronization middleware, the inter-process message synchronization middleware supports message deduplication, order control, and failure retry mechanisms.

[0009] In some embodiments, the local SSE connection pool managed independently by each worker process uses a key-value pair data structure to manage the multiple SSE long connections, where the key is the connection identifier and the value is the SSE connection object. The connection identifier is also used for targeted push, group push based on connection group tags, and global broadcast to all SSE long connections.

[0010] In some embodiments, broadcasting the business message to all worker processes via an inter-process message synchronization middleware includes: The source worker process that receives the business message publishes the business message to the inter-process message synchronization middleware; The inter-process message synchronization middleware forwards the business message to all working processes in the multi-process cluster. After receiving the business message, each worker process searches for one or more SSE connections that match the business message in its own local SSE connection pool, and performs a push operation on the found connections.

[0011] In some embodiments, it also includes: An integrated process management tool monitors the worker processes in the multi-process cluster; When any worker process is detected to have exited abnormally, the process management tool will automatically restart that worker process. The restarted worker process reinitializes the local SSE connection pool and rebuilds the SSE session for the client corresponding to the terminated connection.

[0012] The present invention also provides a multi-process SSE long connection management device, applied in a multi-process cluster including at least two worker processes, comprising the following modules: The process allocation module is used to configure an independently managed local server push event SSE connection pool for each worker process, wherein the local SSE connection pool manages one or more SSE long connections; The pattern acquisition module is used to obtain the currently configured push pattern in response to receiving a business message to be pushed; The push processing module is configured to, if the push mode is the first mode, broadcast the business message to all worker processes through the inter-process message synchronization middleware, so that each worker process can search for and push the business message to the matching connection from the local SSE connection pool; if the push mode is the second mode, push is only performed in the local SSE connection pool of the source worker process that generated the business message.

[0013] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the multi-process SSE long connection management method as described above.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the multi-process SSE long connection management methods described above.

[0015] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements any of the multi-process SSE long connection management methods described above.

[0016] This invention provides a multi-process SSE long connection management method, apparatus, device, and storage medium. By configuring an independently managed local SSE connection pool for each worker process, and selecting to broadcast to all worker processes or push only locally in the source worker process according to the currently configured push mode, it achieves consistency guarantee and deployment flexibility for SSE long connection message push in a multi-process environment. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the multi-process SSE long connection management method provided by the present invention.

[0019] Figure 2 This is a schematic diagram of the architecture of the multi-process SSE long connection management system provided by the present invention.

[0020] Figure 3 This is a flowchart illustrating the multi-process SSE long connection management method provided by the present invention.

[0021] Figure 4 This is a schematic diagram of the structure of the multi-process SSE long connection management device provided by the present invention.

[0022] Figure 5 This is a schematic diagram of the physical structure of the electronic device provided by the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0024] With the increasing demand for real-time push capabilities in web applications, Server-SentEvents (SSE), as a lightweight server-side push technology, is widely used in scenarios such as message notifications, artificial intelligence (AI) dialogue, and data monitoring. Node.js, as the mainstream backend framework for high-concurrency web services, typically employs multi-process cluster modes such as PM2 to fully utilize multi-core server resources. In existing technologies, SSE long-lived connections are usually maintained by a single Node.js process, or in a multi-process environment, each process independently manages its own SSE connection. To achieve consistent message push in a multi-process environment, some solutions introduce middleware such as Redis for inter-process message synchronization, or use load balancers to achieve connection stickiness.

[0025] However, in a Node.js multi-process cluster environment, when multiple worker processes independently manage SSE long connections, it is difficult for the business messages pushed by the server to be correctly pushed to the worker process where the target client is located.

[0026] Figure 1 This is a flowchart illustrating the multi-process SSE long-connection management method provided by the present invention. Figure 1 As shown, the method includes the following: Step 101: Configure an independently managed local server push event SSE connection pool for each worker process. The local SSE connection pool manages one or more SSE long connections.

[0027] In this context, a worker process refers to an independent process within a multi-process cluster, such as a Node.js process started in PM2 cluster mode. Each process can independently handle network requests and maintain connections. SSE (Server-Sent Events) refers to a technical specification for servers to push real-time data unidirectionally to clients based on the Hypertext Transfer Protocol (HTTP), supporting automatic reconnection mechanisms. An SSE connection pool refers to a data structure used to centrally manage one or more SSE long-lived connections. Each worker process independently maintains its own connection pool, and each connection in the pool corresponds to one client.

[0028] It should be noted that in a multi-process cluster, at least two worker processes can be started (for example, 4 or 8 depending on the number of CPU cores on the server). Each worker process configures a local SSE connection pool upon startup or when it first receives an SSE connection request. This SSE connection pool manages all long-lived SSE connections established with the current worker process. When a client initiates an SSE connection request to the server, the load balancer (such as Nginx) distributes the request to one of the worker processes. After establishing the SSE connection, the worker process stores the connection object in its local connection pool. The multi-process cluster can be a Node.js multi-process cluster; Node.js is a JavaScript runtime environment based on the Chrome V8 engine.

[0029] Step 102: In response to receiving the business message to be pushed, obtain the currently configured push mode.

[0030] Business messages refer to real-time data that needs to be pushed from the server to the client, such as streaming responses in AI dialogues, system notifications, and market data. The push mode refers to the pre-configured message synchronization method, which determines the synchronization strategy of business messages between workflow processes. The push mode can be pre-set through configuration files, environment variables, or startup parameters.

[0031] It should be noted that when the server needs to push business messages to the client, it first obtains the currently configured push mode of the system. The push mode is preset by the operations and maintenance personnel during system deployment based on the business scenario. For example, for scenarios where the push content is strongly bound to a specific user and the number of processes is small, the second mode can be configured; for scenarios that need to ensure that all clients can receive messages and have high consistency requirements, the first mode, i.e., consistency mode, can be configured.

[0032] Step 103: If the push mode is the first mode, the business message is broadcast to all worker processes through the inter-process message synchronization middleware, so that each worker process searches for and pushes the business message to a matching connection from its local SSE connection pool. If the push mode is the second mode, the push is only performed in the local SSE connection pool of the source worker process that generated the business message.

[0033] Consistency mode refers to an inter-process message synchronization mode where all worker processes broadcast messages through middleware. Upon receiving a broadcast message, each worker process retrieves the connection corresponding to the target client from its local SSE connection pool and pushes the message, ensuring all clients receive the message. Inter-process message synchronization middleware refers to middleware used to broadcast messages between worker processes, such as Redis's publish / subscribe (Pub / Sub) functionality and message queues (such as RabbitMQ and Kafka).

[0034] It should be noted that when the system is currently configured with the first push mode, the worker process that generates the business message sends the business message to be pushed to the inter-process message synchronization middleware. The middleware then broadcasts the business message to all worker processes.

[0035] Upon receiving a broadcast message, each worker process searches its local SSE connection pool for a matching SSE long-lived connection based on the target client identifier carried in the business message. If a match is found, the business message is pushed to the client through that connection; otherwise, no action is taken.

[0036] In this way, regardless of which worker process the client's SSE long connection is established on, the client can receive the pushed messages, thus ensuring consistent message delivery in a multi-process environment.

[0037] The second mode, or minimalist mode, is an inter-process message synchronization mode. In this mode, worker processes do not synchronize messages; each worker process only pushes messages to the SSE long-lived connections in its local SSE connection pool. This mode is suitable for scenarios where the pushed content is bound to the user and the number of processes is small. The source worker process refers to the worker process that receives the trigger request for the business message to be pushed and is responsible for executing the push operation. The second mode is configured to be enabled when the number of worker processes in the multi-process cluster is below a preset threshold, or when a load balancing strategy ensures that requests from the same client are always routed to the same worker process.

[0038] It's important to note that when the system's current push mode is the second mode (minimalist mode), the worker process generating the business message does not broadcast across processes through middleware. Instead, it directly searches its local SSE connection pool for a matching SSE long-lived connection to the target client and pushes the business message to that client. In this mode, if the target client's SSE long-lived connection is established on another worker process, that client will not receive the pushed message. Therefore, the second mode is suitable for scenarios where load balancing strategies (such as IP hashing or user ID hashing) ensure that requests from the same client are always routed to the same worker process. The advantage of the second mode is that it eliminates the need for additional middleware, resulting in a simpler system architecture and lower deployment and maintenance costs.

[0039] This embodiment configures an independently managed local SSE connection pool for each worker process and supports flexible switching between simplified mode and consistency mode, which can reduce system complexity while ensuring message consistency and high availability of push services in a multi-process environment.

[0040] For example, a combined mechanism of local connection pool and inter-process message synchronization is provided, as well as an inter-process message synchronization and consistency guarantee mechanism.

[0041] This embodiment provides two modes: i. Minimalist mode: No synchronization is required between processes, suitable for scenarios where push content is bound to users and the number of processes is small. ii. Consistent mode: Inter-process message broadcasting is implemented through middleware such as Redis Pub / Sub. After receiving the message, all processes push it to their local SSE connection, ensuring message consistency.

[0042] In some embodiments, if the push mode is a first mode, the method further includes: Perform a health check on the inter-process message synchronization middleware; When an anomaly is detected in the inter-process message synchronization middleware, the push mode is switched to the second mode.

[0043] Health checks refer to the system's periodic probing of middleware availability, such as by sending heartbeat packets, checking connection status, and capturing abnormal responses to determine if the middleware is functioning correctly. Middleware anomalies refer to the failure or unavailability of the inter-process message synchronization middleware, such as Redis service crashes, network connection drops, or response timeouts. Switching refers to the system automatically changing the push mode from one mode to another without manual intervention.

[0044] It should be noted that when the system is currently configured with the first push mode, since this mode relies on an inter-process message synchronization middleware (such as Redis) for message broadcasting, the availability of the middleware directly affects the consistency of message pushes. Therefore, the system needs to perform health checks on the middleware.

[0045] Health checks can be implemented in several ways, such as periodically sending Packet Internet Groper (PING) commands to Redis and waiting for a PONG response; checking the Transmission Control Protocol (TCP) connection status with the middleware; or listening for exceptions thrown by the middleware. The frequency of health checks can be set according to actual needs, for example, once every 5 seconds.

[0046] When a middleware malfunction is detected (e.g., three consecutive unresponsive PINGs, connection timeout), the system automatically performs a degradation operation: switching the push mode from consistent mode to simplified mode. After the switch, subsequent business messages will be processed according to the simplified mode push logic, meaning they are only pushed within the local SSE connection pool of the source worker process that generated the business message. After switching to simplified mode, the system continuously performs background probing of the middleware, and can automatically switch back to consistent mode once the middleware recovers.

[0047] Through this automatic degradation mechanism, even if the middleware fails, the system's core push function will not be interrupted, but will continue to run in a degraded, simplified mode, thus ensuring the basic availability of the service.

[0048] This embodiment ensures the fault tolerance and high availability of the multi-process SSE push service by performing health checks on the middleware in consistency mode and automatically downgrading to the second mode when an anomaly occurs.

[0049] For example, this embodiment provides an automatic degradation and fault-tolerant SSE push guarantee mechanism. a) When the middleware (such as Redis) malfunctions or the process restarts, the system automatically switches to local push mode to ensure that core functions are not interrupted. b) The process automatically restarts in case of malfunction, and the SSE connection is automatically rebuilt, minimizing user perception.

[0050] In some embodiments, it also includes: Obtain server resource load metrics and / or the total number of current SSE connections; When the resource load index or the current total number of SSE connections meets the preset expansion conditions, a new working process is added, and the newly added SSE connection requests are allocated to the new working process. When the resource load index or the current total number of SSE connections meets the preset scaling-down conditions, at least one worker process to be destroyed is terminated, and before termination, the SSE connections on the worker process to be destroyed are migrated or rebuilt to one or more other worker processes.

[0051] Resource load metrics refer to parameters related to server operating status, such as CPU utilization, memory usage, and network input / output (IO). Current total SSE connections refer to the sum of all SSE long-lived connections currently held by all worker processes. Expansion conditions refer to preset threshold conditions that trigger the addition of worker processes, such as an average CPU utilization exceeding 70%, or the current total number of SSE connections approaching the product of the single-process connection limit and the number of processes. Shrinking conditions refer to preset threshold conditions that trigger the reduction of worker processes, such as an average CPU utilization below 30% and a low current total number of SSE connections. Worker processes to be destroyed refer to worker processes selected for termination during the shrinking process. Migration or rebuilding refers to the operation of transferring SSE connections from worker processes to be destroyed to other worker processes. Migration refers to rebuilding connections through the client reconnection mechanism, while rebuilding refers to a new process actively establishing a connection.

[0052] It should be noted that, to achieve a balance between resource utilization and connection management, the system dynamically adjusts the number of worker processes during runtime. The system acquires server resource load metrics (such as CPU utilization and memory usage) and / or the current total number of SSE connections in real time or periodically. When these metrics meet preset expansion conditions (e.g., average CPU utilization exceeds 70% for one consecutive minute, or the current total number of SSE connections exceeds the current number of processes multiplied by the recommended maximum number of connections per process), the system dynamically adds one or more worker processes. After the newly added worker processes start, the load balancer distributes the new SSE connection requests to these new worker processes, thereby achieving load sharing.

[0053] When resource load metrics meet preset scaling-down conditions (e.g., average CPU utilization is below 30% for 10 consecutive minutes, and the total number of current SSE connections is low), the system dynamically terminates at least one worker process to be destroyed. Before termination, the system needs to migrate or rebuild the SSE connections maintained on the worker process to be destroyed to one or more other worker processes to ensure uninterrupted client connections. The specific migration method can employ a client reconnection mechanism: the worker process to be destroyed sends a reconnection command to the client; upon receiving the command, the client disconnects its current connection and initiates a reconnection request; the load balancer distributes the reconnection request to other worker processes, thus completing the connection migration.

[0054] The specific method of migration / reconstruction, for example: the migration or reconstruction of the SSE connection on the worker process to be destroyed to other worker processes includes: the worker process to be destroyed sends a reconnection instruction to the corresponding client, the client disconnects the current connection and initiates a reconnection request after receiving it, and the load balancer distributes the reconnection request to other worker processes.

[0055] Through the aforementioned dynamic adjustment mechanism, the system can automatically increase or decrease the number of working processes according to the actual load, and ensure the continuity of existing SSE connections when processes are scaled down, thereby achieving an adaptive balance between resource utilization and connection management complexity.

[0056] This embodiment achieves an adaptive balance between resource utilization and connection management complexity in multi-process SSE management by dynamically acquiring resource load indicators and the total number of SSE connections, automatically adjusting the number of working processes, and migrating or rebuilding connections before scaling down.

[0057] For example, this embodiment provides a multi-process SSE management method that adaptively balances process count, performance, and connection management, as well as dynamic process count adjustment and automatic SSE connection migration / reconstruction. The adaptive balancing mechanism for process count, performance, and connection management includes: a) dynamically recommending and adjusting the number of Node.js processes (e.g., 4~8) based on the number of server CPU cores, memory, and business concurrency requirements, with each process independently maintaining an SSE connection pool, balancing performance and management complexity. b) supporting dynamic adjustment of the number of processes at runtime and automatic migration or reconstruction of SSE connections to ensure service continuity.

[0058] In some embodiments, the inter-process message synchronization middleware is Redis's publish / subscribe mechanism or a message queue system; When broadcasting the business message through the inter-process message synchronization middleware, the inter-process message synchronization middleware supports message deduplication, order control, and failure retry mechanisms.

[0059] In Redis, the publish / subscribe mechanism refers to a message communication pattern provided by Redis. Publishers send messages to a specified channel, and subscribers receive messages from the channel, enabling message broadcasting between processes. Message queue systems refer to asynchronous communication middleware, such as RabbitMQ and Kafka, used for reliable message delivery between distributed systems or processes. Message deduplication refers to a mechanism that prevents the same message from being pushed repeatedly to the same SSE connection. This is typically achieved by assigning a globally unique identifier to each message, which the receiver uses to determine whether it has been processed. Sequence control refers to a mechanism that ensures messages sent to the same SSE connection are pushed in the order they were sent. This is typically achieved by assigning a sequence number to each message, which the receiver uses for caching and sorting. Failure retry refers to a mechanism where the system automatically retryes sending messages when broadcasting or pushing fails. The number of retries and the retry interval can be set.

[0060] It's important to note that to achieve inter-process message synchronization and consistency guarantees, the inter-process message synchronization middleware can employ Redis's publish / subscribe (Pub / Sub) mechanism or a message queue system (such as RabbitMQ or Kafka). Redis Pub / Sub is a lightweight message broadcasting solution suitable for scenarios with high throughput requirements and where a small amount of message loss is acceptable. When using Redis Pub / Sub, the worker process generating the business message publishes the message to a specified channel. All worker processes subscribed to that channel receive the message and push it to the corresponding connection in their local SSE connection pool. Message queue systems (such as RabbitMQ or Kafka) are suitable for scenarios with high message reliability requirements. Unlike Redis Pub / Sub, message queues support advanced features such as message persistence, consumption confirmation, and dead-letter queues, providing better protection against message loss. When broadcasting business messages through the above middleware, the middleware or worker processes also support the following three enhancement mechanisms: Message deduplication: Each business message carries a globally unique identifier. When a worker process receives a broadcast message, it uses this identifier to determine whether the message has already been processed. If it has been processed, the message is discarded; otherwise, it is pushed locally. This mechanism prevents clients from receiving duplicate messages due to network jitter or middleware rebroadcasting.

[0061] Sequence control: Business messages sent to the same SSE connection carry sequence numbers. After receiving a broadcast message, the worker process caches and sorts the messages according to the sequence numbers, and then pushes them to the client in the correct order. This mechanism guarantees the order of messages.

[0062] Retry on Failure: The system automatically retryes when broadcasting a message via middleware fails, or when a worker process fails to push a message to the SSE connection. The number of retries and the retry interval can be configured according to business needs (e.g., a maximum of 3 retries, with a 1-second interval between each retrieval). This mechanism improves the reliability of message push.

[0063] Through the above mechanism, this embodiment can ensure message consistency, order, and reliability in a multi-process SSE environment.

[0064] This embodiment uses Redis Pub / Sub or message queues as inter-process message synchronization middleware and supports message deduplication, order control and failure retry mechanisms to ensure the consistency, order and reliability of multi-process SSE push.

[0065] For example, in this embodiment, inter-process message synchronization can use message queues (such as RabbitMQ or Kafka) instead of Redis Pub / Sub. The inter-process message synchronization and consistency guarantee mechanism supports message deduplication, order control, and failure retries.

[0066] In some embodiments, the local SSE connection pool managed independently by each worker process uses a key-value pair data structure to manage the multiple SSE long connections, where the key is the connection identifier and the value is the SSE connection object. The connection identifier is also used for targeted push, group push based on connection group tags, and global broadcast to all SSE long connections.

[0067] Key-value data structures refer to data structures that store data using key-value pairs, such as Maps and Objects, allowing for quick lookup of values ​​using keys. A connection identifier is a string or ID used to uniquely identify an SSE long-lived connection, such as a client ID, user ID, or session ID. An SSE connection object represents an instance of an SSE long-lived connection, containing context information, message sending methods, and connection status. Targeted push refers to the operation of pushing messages to a specific SSE long-lived connection, precisely locating the target connection using the connection identifier. Group tags refer to one or more classification tags added to SSE connections, used to group connections with the same tag together. Group push refers to the operation of pushing messages to all SSE long-lived connections with the same group tag in batches. Global broadcast refers to the operation of pushing messages to all SSE long-lived connections, regardless of which worker process the connection belongs to.

[0068] It should be noted that, in order to improve the management efficiency and push flexibility of SSE connections, each worker process's local SSE connection pool uses a key-value pair data structure (such as a JavaScript Map object) to manage the multiple SSE long connections it holds.

[0069] Specifically, the connection identifier (such as client ID, user ID, or a unique connection ID generated by the system) is used as the key, and the SSE connection object is used as the value, stored in this key-value pair data structure. The advantage of this storage method is that when a message needs to be pushed to a specific client, the worker process can quickly find the corresponding SSE connection object through the connection identifier, thereby efficiently completing the message push.

[0070] Based on the connection identifier, this embodiment supports the following three push methods: Targeted push: When a message needs to be pushed to a specific single client, the worker process directly uses the client's connection identifier as the key to look up the corresponding SSE connection object in the key-value pair data structure, and then pushes the business message to the client through that connection object. This method is accurate and efficient, and is suitable for one-to-one message push scenarios (such as sending system notifications to specific users).

[0071] Grouped Push: One or more group tags can be set for each SSE connection (e.g., tags can be set according to user level, region, subscribed channels, etc.). When a message needs to be pushed to a group of clients, the worker process traverses its local SSE connection pool, filters out all connections with the target group tag, and then pushes messages to these connections in batches. This method is suitable for one-to-many message push scenarios (e.g., pushing exclusive event notifications to all VIP users).

[0072] Global Broadcast: When a message needs to be pushed to all clients, the worker process iterates through all SSE connection objects in its local SSE connection pool and pushes the message to each connection one by one. Combined with the consistency pattern in a multi-process architecture, after being broadcast to all worker processes through middleware, each worker process performs a global broadcast operation, thereby achieving message broadcasting to all clients in the entire cluster. This approach is suitable for system-level notification scenarios (such as service upgrade announcements).

[0073] Through the aforementioned key-value pair data structure management and multiple push methods, this embodiment achieves efficient and flexible SSE connection management and message push.

[0074] This embodiment manages the SSE connection pool using a key-value pair data structure and supports targeted push, group push, and global broadcast based on connection identifiers, achieving efficient and flexible SSE connection management and message push.

[0075] For example, this embodiment supports multiple push modes (global broadcast, group push, targeted push). It achieves efficient in-process SSE connection pool management, including: a) each process maintains a local SSE connection pool, using efficient data structures (such as Map / Set) to manage connections, supporting batch push, heartbeat detection, and automatic cleanup of abnormal disconnections. b) It supports advanced features such as connection tags, group push, and targeted messages.

[0076] In some embodiments, broadcasting the business message to all worker processes via an inter-process message synchronization middleware includes: The source worker process that receives the business message publishes the business message to the inter-process message synchronization middleware; The inter-process message synchronization middleware forwards the business message to all working processes in the multi-process cluster. After receiving the business message, each worker process searches for one or more SSE connections that match the business message in its own local SSE connection pool, and performs a push operation on the found connections.

[0077] In some embodiments, it also includes: An integrated process management tool monitors the worker processes in the multi-process cluster; When any worker process is detected to have exited abnormally, the process management tool will automatically restart that worker process. The restarted worker process reinitializes the local SSE connection pool and rebuilds the SSE session for the client corresponding to the terminated connection.

[0078] Process management tools, such as PM2, are used to manage, monitor, and automatically recover worker processes. They support functions like starting, stopping, restarting, log management, and health monitoring. Abnormal exit refers to the unnatural termination of a worker process due to uncaught exceptions, memory overflows, system errors, etc., which differs from normal process termination. Automatic restart refers to the process management tool automatically restarting a worker process without manual intervention after detecting an abnormal exit. Reinitializing the local SSE connection pool means that after restarting, the worker process recreates and configures its local SSE connection pool, restoring it to a state where it can accept new connections. Rebuilding the SSE session refers to the process of re-establishing long-lived SSE connections between the restarted worker process and previously disconnected clients.

[0079] It should be noted that, in order to improve the system's fault tolerance and service availability, this embodiment integrates a process management tool (such as PM2) to monitor and manage the worker processes in the multi-process cluster.

[0080] The process management tool runs continuously, monitoring the health status of each worker process in real time. When any worker process exits abnormally due to uncaught exceptions, memory overflows, system errors, or other reasons, the process management tool automatically performs a restart operation, resuming the worker process without manual intervention.

[0081] The restarted worker process first reinitializes its local SSE connection pool, including creating new connection pool data structures and configuring connection management parameters, restoring it to a state where it can accept new connections. Since the SSE long-lived connections held by the original worker process were forcibly disconnected when it exited abnormally, the restarted worker process needs to rebuild the SSE session of the client corresponding to the terminated connection.

[0082] SSE session reconstruction can leverage the automatic reconnection mechanism built into the SSE protocol: after detecting a connection loss, the client automatically initiates a new SSE connection request to the server. The load balancer distributes this request to a restarted worker process (or other healthy worker processes in the cluster), thereby reconstructing the session. Clients can also request to continue receiving unfinished message streams from the point of disconnection by carrying the Last-Event-ID header, minimizing the perceived interruption for the user.

[0083] Through the aforementioned monitoring and automatic recovery mechanisms, this embodiment can quickly restore services when the working process exits abnormally, ensuring the continuity of SSE long-lived connections and user experience.

[0084] This embodiment monitors the working processes by integrating process management tools and automatically restarts and rebuilds the SSE session when a process exits abnormally, thereby improving the fault tolerance and availability of the multi-process SSE service.

[0085] For example, this embodiment provides dynamic configuration and intelligent monitoring, including: a) integrating process management tools such as PM2 to support process health monitoring, automatic restart based on memory / CPU thresholds, and anomaly alarms; b) supporting real-time monitoring and visualization of key indicators such as SSE connection count, push latency, and message loss.

[0086] As an alternative to the present invention, connection stickiness can be achieved through Nginx layer 4 load balancing + IP hashing, which can partially alleviate the push consistency problem, but the implementation complexity is high.

[0087] Nginx Layer 4 load balancing refers to Nginx load balancing TCP traffic at the transport layer (Layer 4 of the Open Systems Interconnection (OSI) model), forwarding requests based on Internet Protocol (IP) addresses and port numbers without parsing application layer protocol content. IP hashing is a load balancing algorithm that hashes client IP addresses to consistently route requests from the same client to the same backend server, achieving connection stickiness. Connection stickiness refers to the mechanism of consistently routing multiple requests from the same client to the same backend process or server, ensuring that the client's connection state is always maintained by the same process. Specifically, connection stickiness can be achieved by combining Nginx Layer 4 load balancing with the IP hash algorithm, consistently routing requests from the same client to the same worker process, thus partially alleviating message push consistency issues in multi-process environments. However, this solution requires additional configuration and maintenance of the load balancer, resulting in higher implementation complexity.

[0088] As an alternative to the present invention, WebSocket can be used instead of SSE, but WebSocket also has the same management and push consistency issues in a multi-process environment.

[0089] WebSocket refers to a full-duplex communication protocol based on TCP, supporting persistent connections between clients and servers. Both parties can send data to each other at any time, making it suitable for real-time bidirectional communication scenarios. Specifically, the WebSocket protocol can be used to replace SSE for server-side push. However, WebSocket faces similar management and push consistency issues in multi-process environments as SSE, requiring additional synchronization mechanisms to resolve, and does not fundamentally simplify the problem.

[0090] Figure 2 This is a schematic diagram of the architecture of the multi-process SSE long-connection management system provided by this invention. Figure 2 As shown, the multi-process SSE long-connection management system provided by this invention is deployed in a Node.js multi-process cluster environment, including: a client side, a load balancing layer, a server cluster (multi-process working layer), a process management layer, and an optional inter-process communication layer. Specifically: Client side: includes one or more clients (client1, client2... clientN), each client establishes an SSE long connection with the server via the HTTP protocol to receive real-time messages actively pushed by the server.

[0091] Load balancing layer: Deployed between the client and the multi-process worker layer, it is used to receive SSE connection requests initiated by the client and distribute the connection requests to one of the worker processes in the multi-process worker layer according to the preset load balancing strategy (such as round-robin, IP hash, least connections, etc.).

[0092] Multi-process worker layer: This includes at least two worker processes (as shown in the diagram: worker process 1, worker process 2, ..., worker process M), each worker process independently maintaining a local SSE connection pool. Wherein: The local SSE connection pool uses a key-value pair data structure (such as a Map) to manage one or more SSE connections belonging to the current working process. Each connection is stored with the connection identifier as the key and the SSE connection object as the value. Each worker process also includes a push decision module, which determines the push path for business messages based on the currently configured push mode (consistent mode or minimalist mode).

[0093] Inter-process communication message synchronization middleware layer (optional): When the worker process is configured in the first mode, the system introduces an inter-process message synchronization middleware (such as Redis or a message queue as shown in the figure). Any worker process that receives a business message broadcasts the message to the middleware, which then forwards the message to all subscribed worker processes, thereby achieving consistent message push across processes.

[0094] Process Management Layer: Integrates process management tools such as PM2 to manage the lifecycle of each worker process in the multi-process worker layer, including process startup, monitoring, abnormal restart, and dynamic scaling.

[0095] Figure 3 This is a flowchart illustrating the multi-process SSE long-connection management method provided by the present invention. Figure 3 As shown, the multi-process SSE long-connection management method provided by the present invention includes the following steps: Step 1: Establish an SSE connection and register it to the local connection pool.

[0096] The client initiates an SSE connection request, which is then distributed by the load balancer to a worker process in the multi-process cluster. This worker process receives the connection request and establishes an SSE long-lived connection, and then stores the connection object with its unique identifier as the key in the local SSE connection pool maintained by this process.

[0097] Step 2: Receive the business messages to be pushed.

[0098] When a business server generates a business message that needs to be pushed to a client, the message is sent to a worker process in the multi-process cluster (this process may be the target process when the connection was established, or it may be another process, depending on the message source path).

[0099] Step 3: Obtain the currently configured push mode and determine whether it is the consistency mode or the minimalist mode.

[0100] Upon receiving a business message, the worker process first reads the system's current push mode configuration. If the configuration is set to minimalist mode, proceed to step 4; if the configuration is set to consistent mode, proceed to step 5.

[0101] Step 4: Minimalist Mode - Local Push Only.

[0102] The worker process searches its own locally maintained SSE connection pool for an SSE connection matching the business message (e.g., searching for the corresponding connection based on the user ID carried in the message). If a connection is found, the message is pushed; otherwise, it is discarded or logged. The process ends.

[0103] Step 5: Consistency Mode - Broadcast to all worker processes.

[0104] The worker process publishes the business message to the inter-process message synchronization middleware (such as Redis Pub / Sub), and the middleware broadcasts the message to all worker processes in the cluster.

[0105] Step 6: Each worker process receives a broadcast message.

[0106] All worker processes receive the same business message from the middleware.

[0107] Step 7: Each worker process matches and pushes connections from its local connection pool.

[0108] Each worker process independently searches its own local SSE connection pool for an SSE connection that matches the message (e.g., matching based on the target user ID or target group label in the message) and pushes the message to the matched connection.

[0109] Step 8: Push complete.

[0110] All matched clients received the message pushed by the server, and the process ended.

[0111] The multi-process SSE long connection management device provided by the present invention is described below. The multi-process SSE long connection management device described below can be referred to in correspondence with the multi-process SSE long connection management method described above.

[0112] Figure 4 This is a schematic diagram of the structure of the multi-process SSE long-connection management device provided by the present invention. Figure 4 As shown, the multi-process SSE long-connection management device includes: The process allocation module 210 is used to configure an independently managed local server push event SSE connection pool for each worker process, wherein the local SSE connection pool manages one or more SSE long connections; The pattern acquisition module 220 is used to obtain the currently configured push pattern in response to receiving a business message to be pushed; The push processing module 230 is configured to, if the push mode is the first mode, broadcast the business message to all worker processes through the inter-process message synchronization middleware, so that each worker process can search for and push the business message to the matching connection from the local SSE connection pool; if the push mode is the second mode, push is only performed in the local SSE connection pool of the source worker process that generated the business message.

[0113] In some embodiments, if the push mode is a first mode, the device further includes: The health check module is used to perform health checks on the inter-process message synchronization middleware. The mode switching module is used to switch the push mode to the second mode when an abnormality is detected in the inter-process message synchronization middleware.

[0114] In some embodiments, it also includes: The monitoring and acquisition module is used to obtain the server's resource load indicators and / or the current total number of SSE connections; The expansion control module is used to add working processes and allocate the newly added SSE connection requests to new working processes when the resource load index or the current total number of SSE connections meets the preset expansion conditions. The scaling-down control module is used to terminate at least one worker process to be destroyed when the resource load index or the current total number of SSE connections meets the preset scaling-down conditions, and before termination, migrate or rebuild the SSE connections on the worker process to be destroyed to one or more other worker processes.

[0115] In some embodiments, the inter-process message synchronization middleware is Redis's publish / subscribe mechanism or a message queue system; When broadcasting the business message through the inter-process message synchronization middleware, the inter-process message synchronization middleware supports message deduplication, order control, and failure retry mechanisms.

[0116] In some embodiments, the local SSE connection pool managed independently by each worker process uses a key-value pair data structure to manage the multiple SSE long connections, where the key is the connection identifier and the value is the SSE connection object. The connection identifier is also used for targeted push, group push based on connection group tags, and global broadcast to all SSE long connections.

[0117] In some embodiments, the push processing module 230 is specifically used for: The source worker process that receives the business message publishes the business message to the inter-process message synchronization middleware; The inter-process message synchronization middleware forwards the business message to all working processes in the multi-process cluster. After receiving the business message, each worker process searches for one or more SSE connections that match the business message in its own local SSE connection pool, and performs a push operation on the found connections.

[0118] In some embodiments, it also includes: The process monitoring module is used to integrate process management tools to monitor the worker processes in the multi-process cluster; An automatic restart module is used to automatically restart any worker process when it is detected that the process management tool has exited abnormally. The session reconstruction module is used to reinitialize the local SSE connection pool after a restart and rebuild the SSE session for the client corresponding to the terminated connection.

[0119] Figure 5 This is a schematic diagram of the physical structure of the electronic device provided by the present invention. For example... Figure 5 As shown, the electronic device may include: a processor 310, a communications interface 320, a memory 330, and a communication bus 340, wherein the processor 310, the communications interface 320, and the memory 330 communicate with each other via the communication bus 340. The processor 310 can call logical instructions in the memory 330 to execute a multi-process SSE long-connection management method, which includes: Configure an independently managed local server push event SSE connection pool for each worker process, and the local SSE connection pool manages one or more SSE long connections; In response to receiving a business message to be pushed, obtain the currently configured push mode; If the push mode is the first mode, the business message is broadcast to all worker processes through the inter-process message synchronization middleware, so that each worker process can find and push the business message to the matching connection from the local SSE connection pool. If the push mode is the second mode, then the push is only performed in the local SSE connection pool of the source worker process that generated the business message.

[0120] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0121] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program that can be stored on a non-transitory computer-readable storage medium, wherein when the computer program is executed by a processor, the computer is able to execute the multi-process SSE long connection management method provided by the above methods, the method comprising: Configure an independently managed local server push event SSE connection pool for each worker process, and the local SSE connection pool manages one or more SSE long connections; In response to receiving a business message to be pushed, obtain the currently configured push mode; If the push mode is the first mode, the business message is broadcast to all worker processes through the inter-process message synchronization middleware, so that each worker process can find and push the business message to the matching connection from the local SSE connection pool. If the push mode is the second mode, then the push is only performed in the local SSE connection pool of the source worker process that generated the business message.

[0122] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-process SSE long-connection management method provided by the above methods, the method comprising: Configure an independently managed local server push event SSE connection pool for each worker process, and the local SSE connection pool manages one or more SSE long connections; In response to receiving a business message to be pushed, obtain the currently configured push mode; If the push mode is the first mode, the business message is broadcast to all worker processes through the inter-process message synchronization middleware, so that each worker process can find and push the business message to the matching connection from the local SSE connection pool. If the push mode is the second mode, then the push is only performed in the local SSE connection pool of the source worker process that generated the business message.

[0123] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. 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.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment 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, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and 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; and these 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 multi-process SSE long-connection management method, characterized in that, Applicable to multi-process clusters comprising at least two worker processes, including: Configure an independently managed local server push event SSE connection pool for each worker process, and the local SSE connection pool manages one or more SSE long connections; In response to receiving a business message to be pushed, obtain the currently configured push mode; If the push mode is the first mode, the business message is broadcast to all worker processes through the inter-process message synchronization middleware, so that each worker process can find and push the business message to the matching connection from the local SSE connection pool; if the push mode is the second mode, the push is only performed in the local SSE connection pool of the source worker process that generated the business message.

2. The method according to claim 1, characterized in that, If the push mode is the first mode, it also includes: Perform a health check on the inter-process message synchronization middleware; When an anomaly is detected in the inter-process message synchronization middleware, the push mode is switched to the second mode.

3. The method according to claim 1, characterized in that, Also includes: Obtain server resource load metrics and / or the total number of current SSE connections; When the resource load index or the current total number of SSE connections meets the preset expansion conditions, a new working process is added, and the newly added SSE connection requests are allocated to the new working process. When the resource load index or the current total number of SSE connections meets the preset scaling-down conditions, at least one worker process to be destroyed is terminated, and before termination, the SSE connections on the worker process to be destroyed are migrated or rebuilt to one or more other worker processes.

4. The method according to claim 1, characterized in that, The inter-process message synchronization middleware is Redis's publish / subscribe mechanism or message queue system; When broadcasting the business message through the inter-process message synchronization middleware, the inter-process message synchronization middleware supports message deduplication, order control, and failure retry mechanisms.

5. The method according to claim 1, characterized in that, Each worker process independently manages its local SSE connection pool, which uses a key-value pair data structure to manage the multiple SSE long connections, where the key is the connection identifier and the value is the SSE connection object. The connection identifier is also used for targeted push, group push based on connection group tags, and global broadcast to all SSE long connections.

6. The method according to claim 1, characterized in that, The step of broadcasting the business message to all worker processes through an inter-process message synchronization middleware includes: The source worker process that receives the business message publishes the business message to the inter-process message synchronization middleware; The inter-process message synchronization middleware forwards the business message to all working processes in the multi-process cluster. After receiving the business message, each worker process searches for one or more SSE connections that match the business message in its own local SSE connection pool, and performs a push operation on the found connections.

7. The method according to claim 1, characterized in that, Also includes: An integrated process management tool monitors the worker processes in the multi-process cluster; When any worker process is detected to have exited abnormally, the process management tool will automatically restart that worker process. The restarted worker process reinitializes the local SSE connection pool and rebuilds the SSE session for the client corresponding to the terminated connection.

8. A multi-process SSE long-connection management device, characterized in that, Applicable to multi-process clusters comprising at least two worker processes, including: The process allocation module is used to configure an independently managed local server push event SSE connection pool for each worker process, wherein the local SSE connection pool manages one or more SSE long connections; The pattern acquisition module is used to obtain the currently configured push pattern in response to receiving a business message to be pushed; The push processing module is configured to, if the push mode is the first mode, broadcast the business message to all worker processes through the inter-process message synchronization middleware, so that each worker process can search for and push the business message to the matching connection from the local SSE connection pool; if the push mode is the second mode, push is only performed in the local SSE connection pool of the source worker process that generated the business message.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the multi-process SSE long connection management method as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-process SSE long connection management method as described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the multi-process SSE long connection management method as described in any one of claims 1 to 7.

Images