WebSocket cluster connection scheduling method, system and device and storage medium

Abstract

The invention relates to the field of computer business process management, and provides a WebSocket cluster connection scheduling method, system and device and a storage medium. The method comprises the following steps: reading service identification information of working services and a current connection mapping relationship, and collecting running state data of a plurality of working services; carrying out load balancing analysis on the state data set by the WebSocket management service, calculating to obtain a load score value of a plurality of working services, and judging an overload working service and an idle working service; when the overload working service is identified, screening and obtaining a to-be-migrated user from the associated user connection through a connection selection strategy, and generating a connection migration instruction; the connection migration instruction is issued to the corresponding client, the client is triggered to initiate a reconnection request to the target work service, the target work service reads the session state information of the user to be migrated from the shared storage module, and connection migration is completed. According to the invention, connection dynamic rebalance can be realized, the resource utilization rate is improved, and message loss is prevented.

Description

Technical Field

[0001] This invention belongs to the field of computer business process management technology, and in particular relates to a WebSocket cluster connection scheduling method, system, device and storage medium. Background Technology

[0002] Current mainstream WebSocket cluster solutions typically employ an architecture of "load balancing + session stickiness + Redis shared state + message broadcasting". When a client connects, the request is forwarded to multiple backend WebSocket server nodes via Nginx or a cloud load balancer. To ensure that the same client always connects to the same server, the load balancer enables a session stickiness mechanism, routing based on cookies or IP addresses. Each server node stores user connection state in Redis to achieve state sharing. When a node needs to broadcast a message to all users, it publishes the message to all other nodes through Redis's Pub / Sub mechanism.

[0003] However, existing technologies have the following shortcomings: session stickiness leads to uneven load distribution. Once a connection is established, the client is fixed to a specific server, and even if the server is subsequently overloaded, the connection cannot be dynamically migrated to an idle node. Secondly, Redis Pub / Sub broadcasting is inefficient, as messages need to be broadcast to all nodes through Redis, resulting in a waste of network and CPU resources. In addition, fault recovery depends on client reconnection. If a server crashes, all connections on it are immediately interrupted, and the client must actively reconnect and re-establish the session, affecting the real-time experience. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the purpose of the invention is to provide a WebSocket cluster connection scheduling method, system, device and storage medium.

[0005] This invention provides a WebSocket cluster connection scheduling method, comprising:

[0006] S1: Write the service identification information and current connection mapping relationship of multiple WebSocket working services into the shared storage module, and collect the running status data of multiple working services to obtain the status dataset;

[0007] S2: The WebSocket management service performs load balancing analysis on the state dataset based on the weighted load scoring model, calculates the load score values ​​of multiple working services, and determines overloaded and idle working services according to the preset load threshold.

[0008] S3: When the overloaded work service is identified, the user identifier to be migrated is obtained by filtering from the user connections associated with the overloaded work service through the connection selection strategy, and a connection migration instruction is generated by combining the service address of the idle work service.

[0009] S4: The connection migration instruction is sent to the corresponding client via the original working service, triggering the client to initiate a reconnection request to the target working service. The target working service reads the session state information of the user to be migrated from the shared storage module, and updates the connection mapping relationship in the shared storage module after the connection migration is completed.

[0010] According to the WebSocket cluster connection scheduling method provided by the present invention, step S1, the step of collecting the running status data of multiple working services, further includes:

[0011] S11: Multiple work services construct status report data packets containing work service identifiers, current connection counts, processor utilization, and message queue latency at preset time intervals;

[0012] S12: Transmit the status report data packet to the WebSocket management service or write it to the status record area of ​​the shared storage module through the control channel to obtain the status dataset.

[0013] According to the WebSocket cluster connection scheduling method provided by the present invention, step S2 further includes:

[0014] S21: Normalize the number of connections in the state dataset, calculate the ratio of the normalized number of connections to the maximum connection capacity of the current working service, and obtain the connection ratio parameter.

[0015] S22: The resource utilization rate is smoothed over time using the exponentially weighted moving average algorithm to obtain the smoothed resource utilization rate parameter;

[0016] S23: Calculate the ratio of message processing delay to a preset delay baseline value and perform normalization transformation to obtain the delay ratio parameter;

[0017] S24: Perform a weighted calculation on the connection ratio parameter, the smooth resource utilization rate parameter, and the latency ratio parameter to obtain a load score value;

[0018] S25: Determine the overloaded work service and the idle work service based on the preset load threshold and the load score.

[0019] According to the WebSocket cluster connection scheduling method provided by the present invention, step S3 further includes:

[0020] S31: Extract the connection establishment timestamps of multiple users from the user connection list maintained by the overloaded work service;

[0021] S32: Sort the user connection list and select user connection identifiers as candidate migration objects;

[0022] S33: Combining the current load score and available connection capacity of the idle work service, select a preset number of user identifiers from the candidate migration objects as user identifiers to be migrated;

[0023] S34: Generate a connection migration instruction by combining the identifier of the user to be migrated and the service address of the idle working service.

[0024] According to the WebSocket cluster connection scheduling method provided by the present invention, step S4 further includes:

[0025] Shadow connection preheating mechanism; the shadow connection preheating mechanism further includes:

[0026] S41: Before the connection migration instruction is generated, the WebSocket management service sends a warm-up instruction to the target working service, and the warm-up instruction carries the identifier of the user to be migrated.

[0027] S42: The target job service loads the list of subscribed topics of the user to be migrated from the shared storage module according to the user identifier to be migrated, creates a shadow connection state machine in memory and starts a message listening thread;

[0028] S43: Before the user connection is disconnected, the original working service forwards the received messages belonging to the user to be migrated to the buffer of the target working service in the original frame format through the message queue.

[0029] S44: After the client completes the reconnection, the target service reads messages from the buffer in chronological order and replays them to the client. After the replay is complete, the buffer is cleared.

[0030] According to the WebSocket cluster connection scheduling method provided by the present invention, after step S4, the method further includes:

[0031] Failover steps; the failover steps further include:

[0032] S51: The WebSocket management service identifies abnormal working services through heartbeat timeout detection and health check mechanisms. When no status data is received from any working service or a health check request fails within multiple consecutive reporting cycles, the abnormal working service is marked.

[0033] S52: Query the list of all user identifiers associated with the abnormal work service from the shared storage module, and sort them in reverse order by connection establishment time to obtain the abnormal user list;

[0034] S53: Assign healthy target working services to multiple user identifiers in the abnormal user list, generate batch redirection instructions, and notify the corresponding clients through a backup channel;

[0035] S54: After receiving the redirection instruction, the client initiates a connection to the target job service. The target job service restores the session state information of the abnormal user from the shared storage module and removes the abnormal job service from the load balancer pool.

[0036] The WebSocket cluster connection scheduling method provided by the present invention further includes:

[0037] Elastic scaling prediction; the elastic scaling prediction step further includes:

[0038] S61: The WebSocket management service maintains a sliding time window and stores the average load score of the cluster over multiple consecutive periods;

[0039] S62: The average load score within the sliding time window is fitted and calculated using a linear regression algorithm to obtain the load growth slope;

[0040] S63: Predict the load score at future times based on the current average load score and the load growth slope. When the predicted value exceeds the preset expansion threshold and the current average load score is higher than the warning threshold, trigger the expansion operation.

[0041] S64: Create a brand new job service instance through the cloud platform interface, register it with the shared storage module and set the highest weight, and give priority to accepting new connection tasks and migration tasks.

[0042] A second aspect of the present invention provides a WebSocket cluster connection scheduling system, comprising:

[0043] The shared storage module is used to store service identification information, connection mapping relationships, and running status data of multiple WebSocket working services;

[0044] Multiple WebSocket service modules are provided, each of which includes a connection management unit, a status acquisition unit, and a message processing unit. The connection management unit is used to maintain a long WebSocket connection with the client and write the connection mapping relationship into the shared storage module. The status acquisition unit is used to collect status datasets at preset time intervals. The message processing unit is used to process client messages and execute connection migration instructions.

[0045] The WebSocket management service module includes a load analysis unit, a decision scheduling unit, and an instruction issuing unit. The load analysis unit is used to perform load balancing analysis on the status dataset based on a weighted load scoring model and calculate the load score values ​​of multiple working services. The decision scheduling unit is used to determine overloaded and idle working services according to a preset load threshold, obtain the user identifier to be migrated through a connection selection strategy, and generate a connection migration instruction in combination with the service address of the idle working service. The instruction issuing unit is used to issue the connection migration instruction to the corresponding client through the original working service module.

[0046] The control channel module is used to establish communication links between the WebSocket management service module and multiple working service modules, and to transmit status report data packets and connection migration instructions. Among them, after receiving a client reconnection request, the target working service module reads the user's session state information from the shared storage module, completes the connection migration, and updates the connection mapping relationship in the shared storage module.

[0047] A third aspect of the present invention provides a WebSocket cluster connection scheduling device, comprising:

[0048] A memory and at least one processor, wherein the memory stores instructions;

[0049] At least one of the processors invokes the instructions in the memory to cause a WebSocket cluster connection scheduling device to perform a WebSocket cluster connection scheduling method as described in any of the preceding claims.

[0050] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed by a processor, implement a WebSocket cluster connection scheduling method as described in any of the preceding claims.

[0051] This invention provides a WebSocket cluster connection scheduling method, system, device, and storage medium. Firstly, by introducing an architecture that separates management services from worker services, the service identification information and connection mapping relationships of each worker service are uniformly written into a shared storage module. A heartbeat reporting mechanism continuously collects operational status data, enabling the management service to obtain a global load view of the cluster, breaking through the limitation of fixed connections under traditional session stickiness architectures. Secondly, this invention performs load balancing analysis on the status dataset based on a weighted load scoring model. It comprehensively considers multiple dimensions such as connection quantity, resource utilization, and message processing latency, accurately identifying overloaded and idle worker services, avoiding resource waste caused by some nodes being overloaded while others are idle, and significantly improving the overall resource utilization of the cluster. Thirdly, by using a connection selection strategy to filter users to be migrated and generating connection migration instructions, it achieves... The dynamic connection rebalancing at runtime effectively alleviates single-point bottleneck issues and enhances system stability and throughput. Furthermore, this invention externalizes user session state information and stores it in a shared storage module, enabling the target service to quickly restore its session state after receiving a reconnection request. Compared to existing technologies that rely on the client to completely rebuild the session, this significantly shortens fault recovery time and reduces the risk of message loss. This invention also sets up a shadow connection preheating mechanism, which preloads subscribed topics and buffers messages to ensure message continuity during connection migration, avoiding the loss of critical messages in scenarios with extremely high real-time requirements, such as financial market data and online collaboration. In addition, the elastic scaling prediction step of this invention uses a linear regression algorithm to predict load trends, triggering scaling operations in advance before the cluster is overloaded. This achieves on-demand resource scaling, reduces manual intervention costs, and improves the level of operational automation. Attached Figure Description

[0052] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.

[0053] Figure 1 This is a schematic diagram of a WebSocket cluster connection scheduling method provided in an embodiment of the present invention;

[0054] Figure 2 This is a schematic diagram of a WebSocket cluster connection scheduling system provided in an embodiment of the present invention;

[0055] Figure 3 This is a schematic diagram of the WebSocket cluster system architecture provided in an embodiment of the present invention. Detailed Implementation

[0056] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0057] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.

[0058] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0059] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.

[0060] To better understand this invention, the technical terms appearing in the embodiments of this invention will be explained below.

[0061] WebSocket Management Service: Primarily used to monitor the business, performance, load, and connection switching of job services (modules).

[0062] WebSocket Worker Service: Primarily handles the distribution of management services (modules) and communicates with clients via WebSocket.

[0063] Shadow Connection: Simulates client heartbeat behavior by periodically sending virtual heartbeats to the management service to prevent the connection from being mistakenly identified as invalid.

[0064] Load testing: Detects the business processing rate, backlog, and other conditions of the working service (module).

[0065] Connection switching: When a working service (module) encounters an error, a switching mechanism is triggered to switch the WebSocket connection to the normal working service (module).

[0066] like Figure 1 As shown, the present invention provides a WebSocket cluster connection scheduling method, including:

[0067] S1: Write the service identification information and current connection mapping relationship of multiple WebSocket working services into the shared storage module, and collect the running status data of multiple working services to obtain the status dataset.

[0068] Specifically, step S1, which involves collecting runtime status data from multiple working services, further includes:

[0069] S11: Multiple work services construct status report data packets containing work service identifiers, current number of connections, processor utilization, and message queue latency at preset time intervals.

[0070] Furthermore, multiple worker services initiate scheduled tasks upon startup. These tasks trigger status collection operations at preset 5-second intervals. Each time a task is triggered, the worker service reads the CPU utilization of the current process from the operating system level, counts the number of currently active WebSocket connections from memory, and accesses the local message queue to obtain the queue length and the timestamp of the earliest message enqueued in the queue. Subsequently, this invention calculates the difference between the current system time and the earliest message enqueue time, divides this difference by the queue length, and obtains the average waiting time of the message queue latency. After processing the above data, this invention simultaneously encapsulates the four fields—worker service identifier (e.g., worker: 101), current connection count, processor utilization, and message queue latency—into a JSON-formatted status report data packet.

[0071] S12: Transmit the status report data packet to the WebSocket management service or write it to the status record area of ​​the shared storage module through the control channel to obtain the status dataset.

[0072] In step S12, this invention establishes a long-lived gRPC connection between the worker service and the WebSocket management service as a control channel. The worker service calls the ReportStatus() method of the control channel to serialize the status report data packet and stream it to the management service via gRPC. After receiving the data packet, the management service parses out the values ​​of each field and writes the data into a Redis hash table structure with worker_id as the key. The key name is status:worker:{worker_id}, and the stored content includes four fields: timestamp, conn_count, cpu_usage, and msg_queue_delay. Finally, the management service reads all key-value pairs prefixed with status:worker: from Redis in batches and summarizes them to form a status dataset.

[0073] S2: The WebSocket management service performs load balancing analysis on the state dataset based on the weighted load scoring model, calculates the load score values ​​of multiple working services, and determines overloaded and idle working services according to the preset load threshold.

[0074] Step S2 further includes:

[0075] S21: Normalize the number of connections in the state dataset, calculate the ratio of the normalized number of connections to the maximum connection capacity of the current working service, and obtain the connection ratio parameter.

[0076] In step S21, the present invention extracts the `conn_count` field value for each working service from the status dataset, and simultaneously reads the preset `max_conn` parameter for that working service instance from the configuration center. This parameter is calculated based on server memory capacity and file descriptor limits. Then, `conn_count` is divided by `max_conn` to obtain a connection percentage parameter between 0 and 1. For example, if a working service currently has 8000 connections and a maximum connection capacity of 10000, then the connection percentage parameter is 0.8.

[0077] S22: The resource utilization rate is smoothed over time using an exponentially weighted moving average algorithm to obtain the smoothed resource utilization rate parameter.

[0078] In step S22, the present invention reads the `cpu_usage` field reported by the working service from the status dataset. This field represents the average CPU utilization over the past minute. Subsequently, the present invention maintains a historical CPU utilization variable `cpu_previous` using an exponentially weighted moving average algorithm, with an initial value of 0. Each time new `cpu_usage` data is received, the calculation result is assigned to `cpu_previous`, achieving smoothing of the time-series data. After multiple iterative calculations, a smoothed resource utilization parameter is obtained, which effectively suppresses the interference of instantaneous CPU fluctuations on load assessment.

[0079] S23: Calculate the ratio of message processing delay to a preset delay baseline value and perform normalization transformation to obtain the delay ratio parameter.

[0080] In step S23, the present invention extracts the message processing delay field `msg_queue_delay` from the state dataset. Subsequently, the present invention reads a preset delay baseline value from the configuration file, which is set to 1000 milliseconds in one specific embodiment. Then, `msg_queue_delay` is divided by the preset delay baseline value to obtain a relative delay value. This relative value is then truncated; if the result is greater than 1, it is forcibly set to 1 to ensure that the delay percentage parameter is normalized to the range of 0 to 1.

[0081] S24: Perform a weighted calculation on the connection ratio parameter, the smooth resource utilization rate parameter, and the latency ratio parameter to obtain a load score value.

[0082] This invention reads three weight coefficients from the configuration module. The default values ​​for the connection number ratio parameter, the smooth resource utilization rate parameter, and the latency ratio parameter are 0.5, 0.3, and 0.2, respectively. Then, the corresponding parameter values ​​are multiplied by the corresponding weight coefficients, and the sum of the three products is used to obtain the load score value of the service.

[0083] S25: Determine the overloaded work service and the idle work service based on the preset load threshold and the load score.

[0084] In step S25, the present invention reads two load thresholds T1 and T2 from the configuration center, where T1 represents the overload threshold and T2 represents the idle threshold. After reading, the present invention iterates through the load score values ​​of all working services, adds the identifiers of working services with load scores greater than T1 to the overloaded working service list, and adds the identifiers of working services with load scores less than T2 to the idle working service list. If both the overloaded working service list and the idle working service list are not empty, the connection migration decision process is triggered.

[0085] S3: When the overloaded work service is identified, the user identifier to be migrated is obtained by filtering from the user connections associated with the overloaded work service through the connection selection strategy, and a connection migration instruction is generated by combining the service address of the idle work service.

[0086] Step S3 further includes:

[0087] S31: Extract the connection establishment timestamps of multiple users from the user connection list maintained by the overloaded work service.

[0088] In step S31, the present invention reads the user connection mapping table corresponding to the overloaded worker service from Redis. The key name is conn:worker:{worker_id}. This table is a hash structure with a field named user_id and a value of a JSON object containing the connection ID conn_id and the connection time connect_time. After traversing all fields of the hash table, the JSON object is parsed to extract the connect_time timestamp, and a list of tuples containing user_id and connect_time is constructed.

[0089] S32: Sort the user connection list and select user connection identifiers as candidate migration objects.

[0090] Furthermore, this invention sorts the list of binary pairs in ascending order of connect_time, with the earliest established connection at the top of the list. Following a least recent usage strategy, the user_ids of the top N users in the sorted list are extracted as candidate migration targets, where N is the difference between the current number of connections in the overloaded service and the available capacity of the idle service, divided by 2, ensuring that the load on the two services tends to be balanced after migration.

[0091] S33: Combining the current load score and available connection capacity of the idle working service, select a preset number of user identifiers from the candidate migration objects as user identifiers to be migrated.

[0092] Furthermore, the present invention iterates through the list of idle working services, reads the current load score and conn_count of each idle working service, then calculates the available connection capacity as max_conn minus conn_count, and selects the idle working service with the largest available connection capacity as the target working service. Finally, it extracts the number of user identifiers from the candidate migration objects that is equal to the smaller value between the available connection capacity of the target working service and the total number of candidate migration objects, forming a list of user identifiers to be migrated.

[0093] S34: Generate a connection migration instruction by combining the identifier of the user to be migrated and the service address of the idle working service.

[0094] In step S34, the present invention reads the service address from the registration information of the target working service, then iterates through the list of user identifiers to be migrated, constructs a JSON-formatted connection migration instruction for each user_id, including a cmd field with the value "redirect", a user_id field as the current user identifier, a new_url field as the target working service address, and a timestamp field as the current Unix timestamp. Finally, all connection migration instructions are encapsulated into an instruction batch and sent to the control channel of the original working service.

[0095] S4: The connection migration instruction is sent to the corresponding client via the original working service, triggering the client to initiate a reconnection request to the target working service. The target working service reads the session state information of the user to be migrated from the shared storage module, and updates the connection mapping relationship in the shared storage module after the connection migration is completed.

[0096] In step S4, after receiving the batch of connection migration instructions from the management service, the original service parses the user_id and new_url fields in each instruction. The original service then retrieves the corresponding WebSocket connection object from its local connection pool based on the user_id and sends a JSON-formatted redirection message to the client using the send() method of that connection object.

[0097] After receiving the redirect message, the client parses the new_url field to obtain the target working service address, calls the close() method of the WebSocket API to close the current connection, and then uses new WebSocket(new_url) to create a new WebSocket connection object and initiate a handshake request.

[0098] After receiving the handshake request, the target service extracts the user identity credentials from the HTTP request header and reads a hash table named session:{user_id} from Redis with user_id as the key. This table stores session state information such as the list of subscribed topics, session token, and heartbeat timeout.

[0099] Subsequently, the target worker service loads the read session state information into memory, establishes a mapping relationship between user_id and the new connection object, and then writes a string value with the key user_id_to_worker:{user_id} to Redis, containing the worker_id of the target worker service, thus completing the update operation of the connection mapping relationship.

[0100] Step S4 also includes:

[0101] Shadow connection preheating mechanism; the shadow connection preheating mechanism further includes:

[0102] S41: Before the connection migration instruction is generated, the WebSocket management service sends a warm-up instruction to the target job service, and the warm-up instruction carries the identifier of the user to be migrated.

[0103] Furthermore, before generating the connection migration instruction, the WebSocket management service sends a warm-up instruction to the gRPC control channel of the target worker service. This warm-up instruction includes the `cmd` field value `pre_warm` and the `user_id` field, which identifies the user to be migrated. Upon receiving the warm-up instruction, the target worker service parses the `user_id` field, reads the hash table with the key `session:{user_id}` from Redis, and extracts the `subscribed_topics` field, which is a list of subscribed topics stored in JSON array format.

[0104] S42: The target job service loads the list of subscribed topics of the user to be migrated from the shared storage module according to the user identifier to be migrated, creates a shadow connection state machine in memory and starts a message listening thread.

[0105] In step S42, the target service first creates a ShadowConnection object in memory. This object contains four attributes: user_id, subscribed_topics, buffer, and status. The buffer attribute is initialized to a blocking queue with a maximum capacity of 1000, and the status attribute is initially set to WARMING.

[0106] Subsequently, the target worker service starts a separate thread as a message listening thread. This thread subscribes to message streams in Kafka labeled with user_id. After receiving a message, the listening thread checks if the message's topic field exists in the subscribed_topics list. If it does, the message object is added to the buffer queue, and the ShadowConnection's status is updated to READY.

[0107] S43: Before the user connection is disconnected, the original working service forwards the received messages belonging to the user to be migrated to the buffer of the target working service in the original frame format through the message queue.

[0108] In step S43, when the origin service receives a downlink message, it extracts the target user_id field from the message header. The origin service queries the locally maintained migration user tag table to determine whether the user_id is in a migration state. If it is in a migration state, the origin service does not parse the message content, but directly reads the binary data of the WebSocket raw frame, including the opcode, payload length, and payload data in the frame header.

[0109] Subsequently, the original worker service serializes the complete frame data into a byte array and sends it via the Kafka producer API to a message queue with the topic `shadow_msg:{target_worker_id}`, setting the message key to `user_id`. Finally, the target worker service's message listening thread consumes the message from Kafka, deserializes it to obtain the original frame byte array, wraps the byte array into a frame object, and places it into the `ShadowConnection`'s buffer queue.

[0110] S44: After the client completes the reconnection, the target service reads messages from the buffer in chronological order and replays them to the client. After the replay is complete, the buffer is cleared.

[0111] Furthermore, after the client completes the reconnection handshake, the target server retrieves the ShadowConnection object corresponding to the user_id from memory. The target server then retrieves frame objects one by one from the buffer queue in FIFO order, reads the byte array of each frame object, and sends the byte array back to the client using the sendBinary() method of the newly established WebSocket connection object. When the buffer queue is empty, the target server calls buffer.clear() to clear the queue, sets the status of the ShadowConnection object to CLOSED, and then deletes the ShadowConnection object from memory, releasing the occupied memory resources.

[0112] After step S4, the following is also included:

[0113] Failover steps; the failover steps further include:

[0114] S51: The WebSocket management service identifies abnormal working services through heartbeat timeout detection and health check mechanisms. When no status data is received from any working service or a health check request fails within multiple consecutive reporting cycles, the abnormal working service is marked.

[0115] Further, in step S51, the WebSocket management service maintains a heartbeat timer, recording the timestamp of the most recent status report, `last_heartbeat`, for each worker service. The management service checks the difference between the current time and `last_heartbeat` at fixed intervals; if the difference exceeds 15 seconds, the worker service's heartbeat has timed out. Simultaneously, the management service sends an HTTP GET request to the ` / health` endpoint to each worker service every 5 seconds, setting a timeout of 3 seconds. If the request times out or returns a status code other than the preset 200, the management service sets the `health_status` field of that worker service to `FAILED`. When a worker service simultaneously meets both the heartbeat timeout and health check failure conditions, the management service writes its `worker_id` to the Redis set key `abnormal_workers` and marks the worker service as abnormal in memory.

[0116] S52: Query the list of all user identifiers associated with the abnormal working service from the shared storage module, and sort them in reverse order by connection establishment time to obtain the abnormal user list.

[0117] In step S52, the management service reads the key name conn:worker: from Redis.

[0118] The system uses a hash table named {abnormal_worker_id} to iterate through all fields of the hash table to obtain a list of user_ids. For each user_id, it reads a hash table from Redis with the key name session:{user_id} and extracts the connect_time field value. Finally, the management service constructs a list of tuples containing user_id and connect_time, sorts them in descending order of connect_time, and places the most recently established connection at the top of the list to form a list of abnormal users.

[0119] S53: Assign healthy target working services to multiple user identifiers in the abnormal user list, generate batch redirection instructions, and notify the corresponding clients through a backup channel.

[0120] In step S53, the management service filters service instances with a health_status of HEALTHY from the status dataset and calculates the available connection capacity of each healthy service. Specifically, the management service uses a round-robin algorithm to traverse the list of abnormal users, assigning the healthy service with the largest available connection capacity as the target service for each user_id. Subsequently, the management service generates a redirection instruction for each user_id, containing the cmd field "redirect", the user_id, and the new_url field, and encapsulates all instructions into a batch redirection instruction array. Finally, the management service publishes the redirection instruction to the channel client_notify:{user_id} through Redis's publish-subscribe functionality, and the client subscribes to this channel to receive the notification.

[0121] S54: After receiving the redirection instruction, the client initiates a connection to the target job service. The target job service restores the session state information of the abnormal user from the shared storage module and removes the abnormal job service from the load balancer pool.

[0122] Furthermore, after receiving the redirection instruction from the Redis subscription channel, the client parses the `new_url` field, closes the current connection, and initiates a WebSocket handshake to the target worker service address. Upon receiving the handshake request, the target worker service reads the `session:{user_id}` hash table from Redis, loads the values ​​of fields such as `subscribed_topics`, `session_token`, and `last_ping_time` into memory, and reconstructs the user session state. Subsequently, the target worker service writes the `user_id_to_worker:{user_id}` key-value pair to Redis, with the value being the target worker_id. The management service removes the abnormal worker_id from the `worker_pool` collection key in Redis, removes the worker service from the load balancing pool, and will no longer allocate new connections to it.

[0123] This also includes:

[0124] Elastic scaling prediction; the elastic scaling prediction step further includes:

[0125] S61: The WebSocket management service maintains a sliding time window and stores the average load score of the cluster over multiple consecutive periods.

[0126] In step S61, the WebSocket management service maintains a circular array `sliding_window` of length 6 in memory. The array elements are floating-point numbers. The management service calculates the cluster average load score at fixed intervals, sums the load scores of all healthy working services, and divides the sum by the number of healthy working services to obtain the average load score `avg_score` for the current period. Subsequently, the management service appends `avg_score` to the end of the `sliding_window` array. If the array is full, it overwrites the oldest element, maintaining a constant array length of 6, corresponding to historical data from the past 60 seconds.

[0127] S62: The average load score within the sliding time window is fitted and calculated using a linear regression algorithm to obtain the load growth slope.

[0128] In step S62, the present invention performs linear regression fitting on the 6 data points in the sliding_window array. Specifically, array indices 0 to 5 are used as independent variables x, and the corresponding avg_scores are used as dependent variables y. Subsequently, the present invention calculates the mean x_mean and the mean y_mean of x, iterates through the array to calculate the covariance and the variance of x, and then divides the covariance by the variance to obtain the slope of the regression line. This slope value represents the growth rate of the average load score.

[0129] S63: Predict the load score at future times based on the current average load score and the load growth slope. When the predicted value exceeds the preset expansion threshold and the current average load score is higher than the warning threshold, trigger the expansion operation.

[0130] In step S63, this invention reads the last element of the sliding_window array as the current average load score value current_avg_score. Then, this invention reads the warning threshold and expansion threshold from the configuration center. Subsequently, this invention calculates the predicted load score value for the next 6 periods, i.e., 60 seconds, using the formula predict_score = current_avg_score + slope × 6. After calculating the score, this invention determines whether predict_score is greater than the expansion threshold and whether current_avg_score is greater than the warning threshold. If both conditions are met, this invention checks the timestamp of the Redis key name last_scale_time. If the difference between the current time and this timestamp is greater than 300 seconds, then an expansion operation is triggered and last_scale_time is updated to the current timestamp.

[0131] S64: Create a brand new job service instance through the cloud platform interface, register it with the shared storage module and set the highest weight, and give priority to accepting new connection tasks and migration tasks.

[0132] In step S64, this invention calls the cloud platform's RESTful API and sends a POST request to the / instances endpoint. The request body includes the fields instance_type, image_id, and count. The cloud platform returns response data containing the new instance ID and IP address. This invention polls the cloud platform's / instances / {instance_id} / status interface, querying the instance status every 5 seconds. When the status changes to RUNNING, configuration parameters are sent to the new instance's initialization interface.

[0133] After a new worker service instance starts, a hash table with the key `worker:{new_worker_id}` is written to Redis, containing fields for IP, port, and `max_conn`. Finally, this invention adds a member `new_worker_id` to the sorted set `worker_weights` in Redis, setting its score to 100, significantly higher than the default score of 50 for existing worker services, thus causing the load balancer to prioritize allocating new connections to the new instance.

[0134] like Figure 2 As shown, the present invention also provides a WebSocket cluster connection scheduling system, comprising:

[0135] The shared storage module 100 is used to store service identification information, connection mapping relationships, and running status data of multiple WebSocket working services;

[0136] Multiple WebSocket service modules 2000, wherein each service module 200 includes a connection management unit, a status acquisition unit, and a message processing unit. The connection management unit is used to maintain a long WebSocket connection with the client and write the connection mapping relationship into the shared storage module 100. The status acquisition unit is used to collect status datasets at preset time intervals. The message processing unit is used to process client messages and execute connection migration instructions.

[0137] The WebSocket management service module 300 includes a load analysis unit, a decision scheduling unit, and an instruction issuing unit. The load analysis unit is used to perform load balancing analysis on the state dataset based on a weighted load scoring model and calculate the load score values ​​of multiple working services. The decision scheduling unit is used to determine overloaded and idle working services according to a preset load threshold, obtain the user identifier to be migrated through a connection selection strategy, and generate a connection migration instruction in combination with the service address of the idle working service. The instruction issuing unit is used to issue the connection migration instruction to the corresponding client through the original working service module.

[0138] The control channel module 400 is used to establish a communication link between the WebSocket management service module 300 and multiple working service modules 200, and to transmit status report data packets and connection migration instructions. Among them, after receiving a client reconnection request, the target working service module reads the user's session status information from the shared storage module 100, completes the connection migration, and updates the connection mapping relationship in the shared storage module.

[0139] The present invention also provides a WebSocket cluster connection scheduling device, comprising:

[0140] A memory and at least one processor, wherein the memory stores instructions;

[0141] At least one of the processors invokes the instructions in the memory to cause a WebSocket cluster connection scheduling device to perform a WebSocket cluster connection scheduling method as described in any of the preceding claims.

[0142] The present invention also provides a computer-readable storage medium storing instructions that, when executed by a processor, implement a WebSocket cluster connection scheduling method as described in any of the preceding claims.

[0143] The following section, in conjunction with specific implementation details, introduces the network element devices and their functions used to support the WebSocket cluster connection scheduling method of this invention.

[0144] Client. Function: Initiates WebSocket connection requests and communicates with the WebSocket cluster in real time; Form / Type: Can be a browser, mobile application, desktop application, etc. Accesses the WebSocket service via the Internet or internal network; Communication connection relationship: Establishes a WebSocket connection directly with the WebSocket worker service, and disconnects the current connection and reconnects to the specified worker service as needed according to the instructions of the management service.

[0145] Load Balancer. Function: Used to initially distribute client requests to different WebSocket worker service nodes. It does not participate in ongoing connection migration decisions; Form / Type: Hardware or software load balancers, such as Nginx, HAProxy, or load balancing services provided by cloud service providers; Communication Connection Relationship: Receives new connection requests from clients and forwards them to backend WebSocket worker services according to policies.

[0146] WebSocket Worker Service. Functions: Handles specific business logic and client interactions, including message sending, receiving, and state maintenance. It periodically reports its own status to the management service. Form / Type: Typically deployed as a containerized application or virtual machine instance, supporting horizontal scaling. Communication Connections: Maintains a long-lived WebSocket connection with clients, exchanges user session information with Redis, and sends heartbeats and status reports to the management service.

[0147] WebSocket Management Service. Functions: As a control plane, it monitors the status of all worker services, performs load analysis, fault detection, and connection scheduling decisions. It can also act as a message routing hub, receiving downlink messages from Kafka, HTTP interfaces, etc., and distributing them to appropriate worker services. Form / Type: An independent service within a microservice architecture, possibly implemented using technologies such as Spring Boot and Node.js. Communication Connections: It frequently interacts with Redis to obtain and update the global state, maintains heartbeat and command channels with worker services, and interfaces with external data sources (such as Kafka and APIs).

[0148] Redis. Function: Stores globally shared state information, including the mapping relationship between users and worker services, the health status of each worker service, etc.; Format / Type: In-memory database, which can be deployed in master-slave replication or cluster mode to improve availability and performance; Communication connection relationship: Used by worker services to read and write user session state; Queryed by management services to make scheduling decisions.

[0149] Kafka / HTTP API data source. Function: Provides a source for downstream messages, such as system notifications and push messages; Format / Type: Distributed message queue (Kafka) or RESTful API service; Communication connection: Communicates only directly with the management service, which directs messages to the corresponding worker services according to business rules.

[0150] The microservice architecture design adopted by the technical solution of this invention is described below. The microservice architecture provided by this invention not only improves the flexibility and scalability of the system, but also allows each module to be developed, tested, and deployed independently, which is beneficial for rapid iteration and responding to changing needs. The core components include:

[0151] Front-end layer: Client application, responsible for UI display and interaction with the WebSocket server.

[0152] Access layer: Composed of load balancers, responsible for distributing initial connections.

[0153] Business logic layer:

[0154] WebSocket worker service: Performs specific business operations, such as message sending and receiving, event triggering, etc.

[0155] WebSocket Management Service: Responsible for cluster management, such as load monitoring, fault recovery, and connection scheduling.

[0156] Data persistence layer: Redis is used to store session state and other critical information, ensuring consistency across nodes.

[0157] Message middleware layer: Kafka or HTTP API serves as an external message source for management services to consume and push messages to appropriate business processing units.

[0158] like Figure 3 The diagram shown is a schematic of the WebSocket cluster system architecture provided by the present invention. Figure 3 In this context, DataSources are the data sources, WebSocket Management Service is the control plane, Redis is the shared state store, Message Routing is the message routing service, WebSocket Worker Service is the data plane, Clients are the clients, and Load Balancer is the load balancer.

[0159] First, this invention employs an architecture that separates management services from work services, externalizing connection mapping relationships and session states within a shared storage module, thus overcoming the limitation of fixed connections in traditional sticky session architectures. Second, based on a weighted load scoring model, it performs load balancing analysis on multi-dimensional runtime status data, accurately identifying overloaded and idle work services. Through a connection selection strategy, it dynamically filters users to be migrated and generates migration instructions, achieving runtime connection rebalancing and significantly improving cluster resource utilization. Third, the invention's shadow connection preheating mechanism ensures message continuity during connection migration by preloading subscribed topics and buffering messages in raw frame format, preventing the loss of critical messages. Fourth, the elastic scaling prediction step uses a linear regression algorithm to predict load trends, triggering scaling operations in advance and reducing manual intervention costs.

[0160] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended 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. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A WebSocket cluster connection scheduling method, characterized in that, include: S1: Write the service identification information and current connection mapping relationship of multiple WebSocket working services into the shared storage module, and collect the running status data of multiple working services to obtain the status dataset; S2: The WebSocket management service performs load balancing analysis on the state dataset based on the weighted load scoring model, calculates the load score values ​​of multiple working services, and determines overloaded and idle working services according to the preset load threshold. S3: When the overloaded work service is identified, the user identifier to be migrated is obtained by filtering from the user connections associated with the overloaded work service through the connection selection strategy, and a connection migration instruction is generated by combining the service address of the idle work service. S4: The connection migration instruction is sent to the corresponding client via the original working service, triggering the client to initiate a reconnection request to the target working service. The target working service reads the session state information of the user to be migrated from the shared storage module, and updates the connection mapping relationship in the shared storage module after the connection migration is completed.

2. The WebSocket cluster connection scheduling method according to claim 1, characterized in that, Step S1, the step of collecting runtime status data of multiple working services, further includes: S11: Multiple work services construct status report data packets containing work service identifiers, current connection counts, processor utilization, and message queue latency at preset time intervals; S12: Transmit the status report data packet to the WebSocket management service or write it to the status record area of ​​the shared storage module through the control channel to obtain the status dataset.

3. The WebSocket cluster connection scheduling method according to claim 1, characterized in that, Step S2 further includes: S21: Normalize the number of connections in the state dataset, calculate the ratio of the normalized number of connections to the maximum connection capacity of the current working service, and obtain the connection ratio parameter. S22: The resource utilization rate is smoothed over time using the exponentially weighted moving average algorithm to obtain the smoothed resource utilization rate parameter; S23: Calculate the ratio of message processing delay to a preset delay baseline value and perform normalization transformation to obtain the delay ratio parameter; S24: Perform a weighted calculation on the connection ratio parameter, the smooth resource utilization rate parameter, and the latency ratio parameter to obtain a load score value; S25: Determine the overloaded work service and the idle work service based on the preset load threshold and the load score.

4. The WebSocket cluster connection scheduling method according to claim 1, characterized in that, Step S3 further includes: S31: Extract the connection establishment timestamps of multiple users from the user connection list maintained by the overloaded work service; S32: Sort the user connection list and select user connection identifiers as candidate migration objects; S33: Combining the current load score and available connection capacity of the idle work service, select a preset number of user identifiers from the candidate migration objects as user identifiers to be migrated; S34: Generate a connection migration instruction by combining the identifier of the user to be migrated and the service address of the idle working service.

5. The WebSocket cluster connection scheduling method according to claim 1, characterized in that, Step S4 also includes: Shadow connection preheating mechanism; the shadow connection preheating mechanism further includes: S41: Before the connection migration instruction is generated, the WebSocket management service sends a warm-up instruction to the target job service, and the warm-up instruction carries the identifier of the user to be migrated. S42: The target job service loads the list of subscribed topics of the user to be migrated from the shared storage module according to the user identifier to be migrated, creates a shadow connection state machine in memory and starts a message listening thread; S43: Before the user connection is disconnected, the original working service forwards the received messages belonging to the user to be migrated to the buffer of the target working service in the original frame format through the message queue. S44: After the client completes the reconnection, the target service reads messages from the buffer in chronological order and replays them to the client. After the replay is complete, the buffer is cleared.

6. The WebSocket cluster connection scheduling method according to claim 1, characterized in that, After step S4, the following is also included: Failover steps; the failover steps further include: S51: The WebSocket management service identifies abnormal working services through heartbeat timeout detection and health check mechanisms. When no status data is received from any working service or a health check request fails within multiple consecutive reporting cycles, the abnormal working service is marked. S52: Query the list of all user identifiers associated with the abnormal work service from the shared storage module, and sort them in reverse order by connection establishment time to obtain the abnormal user list; S53: Assign healthy target working services to multiple user identifiers in the abnormal user list, generate batch redirection instructions, and notify the corresponding clients through a backup channel; S54: After receiving the redirection instruction, the client initiates a connection to the target job service. The target job service restores the session state information of the abnormal user from the shared storage module and removes the abnormal job service from the load balancer pool.

7. The WebSocket cluster connection scheduling method according to claim 1, characterized in that, Also includes: Predicting flexible capacity expansion; The elastic scaling prediction step further includes: S61: The WebSocket management service maintains a sliding time window and stores the average load score of the cluster over multiple consecutive periods; S62: The average load score within the sliding time window is fitted and calculated using a linear regression algorithm to obtain the load growth slope; S63: Predict the load score at future times based on the current average load score and the load growth slope. When the predicted value exceeds the preset expansion threshold and the current average load score is higher than the warning threshold, trigger the expansion operation. S64: Create a brand new job service instance through the cloud platform interface, register it with the shared storage module and set the highest weight, and give priority to accepting new connection tasks and migration tasks.

8. A WebSocket cluster connection scheduling system, characterized in that, include: The shared storage module is used to store service identification information, connection mapping relationships, and running status data of multiple WebSocket working services; Multiple WebSocket service modules are provided, each of which includes a connection management unit, a status acquisition unit, and a message processing unit. The connection management unit is used to maintain a long WebSocket connection with the client and write the connection mapping relationship into the shared storage module. The status acquisition unit is used to collect status datasets at preset time intervals. The message processing unit is used to process client messages and execute connection migration instructions. The WebSocket management service module includes a load analysis unit, a decision scheduling unit, and an instruction issuing unit. The load analysis unit is used to perform load balancing analysis on the status dataset based on a weighted load scoring model and calculate the load score values ​​of multiple working services. The decision scheduling unit is used to determine overloaded and idle working services according to a preset load threshold, obtain the user identifier to be migrated through a connection selection strategy, and generate a connection migration instruction in combination with the service address of the idle working service. The instruction issuing unit is used to issue the connection migration instruction to the corresponding client through the original working service module. The control channel module is used to establish communication links between the WebSocket management service module and multiple working service modules, and to transmit status report data packets and connection migration instructions. Among them, after receiving a client reconnection request, the target working service module reads the user's session state information from the shared storage module, completes the connection migration, and updates the connection mapping relationship in the shared storage module.

9. A WebSocket cluster connection scheduling device, characterized in that, include: A memory and at least one processor, wherein the memory stores instructions; At least one of the processors invokes the instructions in the memory to cause a WebSocket cluster connection scheduling device to perform a WebSocket cluster connection scheduling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed by a processor, implement a WebSocket cluster connection scheduling method as described in any one of claims 1 to 7.

Images