A websocket-based distributed message dynamic response method

Abstract

The present application relates to the technical field of distributed response, and particularly relates to a websocket-based distributed message dynamic response method.The method comprises the following steps: constructing a distributed message service cluster, configuring a websocket communication module, a message middleware and a client for each service node, providing a unified service access point to the outside through an Nginx load balancer, automatically registering and subscribing to a global control theme to the message middleware, and forming a hierarchical theme subscription structure; when the client initiates a connection request, the connection is allocated and a secure channel is established; the client sends a business request message and encapsulates it into a standardized message format, and associates a session message of the client; after receiving the session message, intelligent filtering is performed and a response result is generated, which is pushed to the client in real time.The present application can realize efficient processing and real-time response of messages in a distributed environment.

Description

Technical Field

[0001] This invention relates to the field of distributed response technology, and in particular to a distributed message dynamic response method based on WebSocket. Background Technology

[0002] WebSocket is a network protocol based on full-duplex communication. By establishing a persistent connection, it allows for bidirectional real-time communication between clients and servers. Compared to the traditional HTTP protocol, WebSocket can maintain a long-term connection between the client and server, avoiding the overhead of re-establishing a connection for each request, thus greatly improving communication efficiency and response speed. Therefore, WebSocket is widely used in scenarios such as real-time chat, online collaboration, stock market updates, and multiplayer online games, effectively solving message passing and dynamic response problems in large-scale distributed systems.

[0003] In addition, similar patents such as CN110062055A disclose a method for distributed push notifications for single-user multi-location login based on WebSockets, belonging to the field of information push technology. This invention solves the shortcomings of current message push processes and the inability to be applied to some special needs scenarios. Its key technical points are: utilizing message queues and caching servers for user data; when the application pushes messages in the background, if it is a group message, a pre-declared broadcast exchange and a common group message routing key are used to push the message to all group message queues; all WebSocket servers listen for the group message and then send the message to all clients connected to their own WebSocket servers. This invention satisfies distributed deployment, supports the currently popular containerized one-click deployment, making deployment more convenient, and also meets the needs of all clients for push messages after the same user logs in from different locations. Although it can rely on WebSocket servers for message transmission and connection management to solve the shortcomings of push notifications, it cannot meet the message connection response requirements under high concurrency. When the message volume in the system increases sharply, the server will experience a performance bottleneck due to the excessive number of connections, resulting in delayed message response. Summary of the Invention

[0004] To address the aforementioned technical problems in existing distributed push processes for WebSocket messages, this invention provides a WebSocket-based distributed message dynamic response method. This method achieves efficient client request processing and ensures optimized request allocation and maximized resource utilization by constructing a distributed message service cluster combined with Nginx load balancing, WebSocket communication, and message middleware, thereby reducing distributed message response latency. The method includes the following steps:

[0005] A distributed message service cluster is constructed, wherein each service node in the distributed message service cluster is configured with a websocket communication module, message middleware and client, and provides a unified service access point to the outside world through an Nginx load balancer;

[0006] When the service access point starts, it automatically registers with the message middleware and subscribes to the global control topic. At the same time, it creates a dedicated response topic based on the node identifier in the message middleware, forming a hierarchical topic subscription structure.

[0007] When the client initiates a WebSocket connection request, the Nginx load balancer allocates the connection to the optimal service node based on a preset dynamic load algorithm. The optimal service node generates a unique session identifier for the client and establishes a secure channel.

[0008] The client sends a business request message through the secure channel. The business request message includes a request type, a target service identifier, and business parameters. After receiving the message, the optimal service node parses the message content and encapsulates it into a standardized message format.

[0009] The optimal service node publishes the standardized message format to the corresponding business topic queue through the message middleware according to the target service identifier in the message, and at the same time associates it with the client's session message;

[0010] After receiving the session message, all service nodes subscribing to the corresponding business topic within the hierarchical topic subscription structure perform intelligent filtering based on the load balancing factor in the session message and their own resource status, and select nodes that meet the processing conditions as processing nodes to execute message processing logic and generate response results.

[0011] The processing node publishes the response result to the dedicated response topic of the requesting service node through the message middleware, and after obtaining the response result from the dedicated response topic, pushes the response result to the client in real time through the secure channel according to the session message.

[0012] This invention achieves efficient resource management and request processing by constructing a distributed message service cluster. Each service node is configured with a WebSocket communication module, message middleware, and client. An Nginx load balancer provides a unified service access point, ensuring system scalability and high availability. A dynamic load balancing algorithm allocates the optimal service node based on client requests, reducing server overload and latency, and improving response speed and system throughput. Upon startup, service nodes automatically register and subscribe to control topics through the message middleware, forming a hierarchical topic subscription structure that ensures efficient message delivery and flexible expansion. After a client initiates a connection, the optimal service node generates a unique session identifier and establishes a secure channel, guaranteeing data transmission. In terms of security, during business request processing, standardized message formats and intelligent filtering mechanisms ensure that messages are accurately published to the corresponding business topic queues based on the target service identifier. Service nodes subscribed to the topic are filtered according to load balancing factors and resource status to ensure the reasonable allocation of message processing node resources, thereby avoiding resource waste and improving processing efficiency. After the processing node generates the response result, it is promptly fed back to the client through message middleware to ensure the real-time nature of the response. This design not only optimizes system performance and improves resource utilization, but also enhances the security of distributed message data transmission and the stability of the system, providing reliable support for large-scale, high-concurrency distributed message responses, thereby better reducing the response latency of distributed messages.

[0013] Preferably, the Nginx load balancer uses a dynamic load algorithm that combines multi-dimensional indicators such as real-time CPU utilization, memory usage, number of WebSocket connections, message processing queue length, and network I / O throughput of the service nodes. It calculates the node load index through a weighted scoring model and selects and allocates the service nodes to the optimal service nodes based on the node load index, updating the load status every 250-500 milliseconds.

[0014] The dynamic load balancing algorithm used in this invention employs Nginx load balancer. By comprehensively considering multi-dimensional indicators (such as CPU utilization, memory usage, number of WebSocket connections, message processing queue length, and network I / O throughput), it can calculate the load index of each service node in real time and optimize resource allocation based on a weighted scoring model. By updating the load status every 250-500 milliseconds, the load balancer can quickly respond to changes in system load and ensure that requests are accurately allocated to the optimal service node. This refined load allocation mechanism effectively reduces latency and bottleneck problems caused by insufficient node resources, while improving system response speed and scalability. Especially in high-concurrency scenarios, it can achieve more efficient resource utilization and more stable service performance.

[0015] Preferably, when the number of WebSocket connections corresponding to the service node exceeds 8000 concurrent connections, the connection migration mechanism within the Nginx load balancer is automatically triggered to achieve a smooth transfer through the TCP slow start protocol and ensure that the migration packet loss rate is ≤0.1%.

[0016] In this invention, when the number of WebSocket connections on a service node exceeds 8,000 concurrent connections, an automatically triggered connection migration mechanism can smoothly transfer traffic through the TCP slow start protocol, ensuring stability and a low packet loss rate (≤0.1%) during the migration process. This mechanism effectively avoids connection interruptions or response delays caused by service node overload under high concurrency. The TCP slow start protocol ensures that traffic gradually and smoothly transitions during the migration process, preventing data packet loss and client connection anomalies. This smooth migration scheme improves the system's fault tolerance and service availability, thereby ensuring the stability of client connections and the consistency of user experience.

[0017] Preferably, the establishment of the secure passage includes the following steps:

[0018] The optimal service node generates a temporary key pair based on elliptic curve encryption, and the client is authenticated using a pre-shared root certificate.

[0019] A cryptographic transport layer is established using the TLS 1.3 protocol, and a session key is generated using the ECDHE key exchange algorithm to achieve forward security.

[0020] WebSocket frame data is processed using a three-level process: compression, encryption, and signature. First, the data is compressed using the Brotli algorithm, then encrypted using AES-256-GCM, and finally an HMAC-SHA256 message authentication code is appended to ensure data integrity and prevent tampering.

[0021] In this invention, the establishment of a secure channel utilizes elliptic curve cryptography to generate temporary key pairs, combined with the TLS 1.3 protocol and the ECDHE key exchange algorithm. This provides robust security for data transmission. Elliptic curve cryptography offers an efficient and secure key management method, while the TLS 1.3 protocol ensures high security and forward security at the encrypted transport layer, avoiding long-term risks associated with key leakage. Furthermore, by performing compression, encryption, and signing on WebSocket frame data, data transmission becomes more efficient and ensures data integrity and tamper resistance during transmission. The Brotli compression algorithm improves data transmission speed, AES-256-GCM encryption ensures data privacy, and HMAC-SHA256 message authentication code prevents message tampering. This multi-layered security approach makes the entire communication process more secure and reliable, effectively resisting man-in-the-middle attacks and data leakage risks.

[0022] Preferably, the standardized message format is encapsulated using JSON Web Token, which includes the following fields:

[0023] Message header: contains message ID, timestamp, version number, signature algorithm, and compression flag;

[0024] Message body: includes request type, target service identifier, business parameters, load balancing factor, and priority flag;

[0025] Message footer: Includes the message source node identifier, encryption key fingerprint, and response topic address.

[0026] This invention uses JSON Web Token (JWT) as a standardized message format for encapsulation. This not only provides structured information for messages but also enhances message security and scalability. By dividing messages into headers, bodies, and trailers, data can be transmitted and processed efficiently while ensuring clarity and unambiguity in each part. The header, containing fields such as message ID, timestamp, and version number, ensures message uniqueness, traceability, and compatibility. The request type, target service identifier, load balancing factor, and priority flag in the message body facilitate precise scheduling and priority handling, optimizing system resource allocation. The trailer strengthens data security and reliability through cryptographic key fingerprints and response topic addresses. Overall, JWT encapsulation not only enhances message security and flexibility but also improves system scalability and maintainability, helping developers easily handle different business needs and optimize message transmission processes.

[0027] Preferably, the method for generating the load balancing factor is as follows:

[0028] Extract key feature values ​​from the business parameters, including user ID, business type, and data volume;

[0029] The key feature values ​​are input into a pre-trained neural network model, which uses the historical performance data corresponding to the optimal service node as a training set and outputs a load balancing factor in the range of 0-1.

[0030] The load balancing factor is weighted and adjusted to dynamically allocate weights based on the current load status.

[0031] The load balancing factor generation method in this invention is based on the extraction of key feature values ​​and the training of a neural network model, making load allocation more intelligent and accurate. By extracting key features such as user ID, business type, and data volume, more suitable load allocation can be made according to different business scenarios. The pre-trained neural network model uses historical performance data of the optimal service node for analysis to generate an accurate load balancing factor. The generation of this factor not only considers historical performance but also dynamically adapts to the current load state and adjusts it with weights. This method significantly improves the intelligence level of load balancing, enabling flexible adjustment of resource allocation according to real-time load conditions, effectively avoiding overload or resource waste, and improving the overall performance and reliability of the system.

[0032] Preferably, the intelligent filtering process includes the following steps:

[0033] After receiving the session message, the service node first verifies the message signature and encryption integrity, and then parses the load balancing factor.

[0034] The self-resource status is compared with the load balancing factor to calculate the matching score;

[0035] If the matching score exceeds 75%, then further check whether the local business processing module supports this request type;

[0036] For supported request types, check if the current processing queue length exceeds 80% of the maximum capacity. If it does not exceed this limit, receive the session message and process it.

[0037] In this invention, the intelligent filtering process ensures data security and integrity during transmission by verifying message signatures and encryption integrity, thereby avoiding the risk of tampering or malicious attacks. Upon receiving a session message, the service node calculates a matching score based on a comparison of the load balancing factor and its own resource status to ensure the rationality of resource allocation. Only when the matching score exceeds 75% will it further check whether the request can be processed, avoiding receiving unnecessary requests when resources are overloaded, thus optimizing service stability and response speed. In addition, by checking the local business processing module and the length of the processing queue, it further ensures that the service node can still operate efficiently under high load, reducing system crashes or processing delays caused by excessive requests. This intelligent filtering mechanism improves the system's adaptability and fault tolerance, enabling it to maintain efficient operation even in complex and high-concurrency environments.

[0038] Preferably, a distributed session management mechanism is also included, which includes:

[0039] The session messages are stored in a distributed key-value store based on the Raft consensus algorithm to ensure strong consistency of the session messages among the distributed message service cluster.

[0040] Set dual expiration times for each session message, including the WebSocket connection timeout and the session message retention time, which are set to 15-30 minutes and 12-24 hours by default, respectively.

[0041] When the client's WebSocket connection is disconnected, the session migration logic is automatically triggered to migrate the unfinished session messages to other available service nodes and notify the relevant business modules through the message middleware.

[0042] When the client reconnects, it is preferentially assigned to the original service node. If the original service node is unavailable, the session state is quickly restored based on the session message.

[0043] The distributed session management mechanism in this invention ensures strong consistency of session messages across multiple service nodes by storing them in a distributed key-value store based on the Raft consensus algorithm. This significantly improves the system's fault tolerance and stability. Even if some nodes in the system fail, other nodes can take over the session promptly, avoiding data loss or inconsistent session messages due to service interruption. Furthermore, setting dual expiration times and session migration logic effectively prevents session message expiration and loss. When a client disconnects, the session automatically migrates to an available service node, ensuring rapid recovery of the session state regardless of whether the client reconnects, thus optimizing the user experience. Through these mechanisms, high fault tolerance and seamless user service are achieved, guaranteeing high availability of session messages in the distributed cluster.

[0044] Preferably, the execution message processing logic processes the corresponding session messages through a message priority scheduling mechanism, which includes:

[0045] The session messages are divided into four levels, including real-time messages, high-priority messages, normal messages, and low-priority messages. The real-time messages include transaction instructions and alarm information, the high-priority messages include status updates and user operations, the normal messages include notifications and announcements, and the low-priority messages include statistical data and batch synchronization.

[0046] At the same time, independent processing threads and queues are allocated for session messages of different priorities. The queues adopt a lock-free queue structure to reduce processing latency.

[0047] The reduction in processing latency is achieved through flow control based on the token bucket algorithm to ensure that the processing latency of real-time messages is ≤5ms, 5ms < the processing latency of high-priority messages is ≤10ms, 10ms < the processing latency of ordinary messages is ≤15ms, and 15ms < the processing latency of low-priority messages is ≤20ms, while simultaneously preventing starvation of session messages of different priorities.

[0048] The message priority scheduling mechanism in this invention divides session messages into different priorities and assigns an independent processing thread and queue to each priority level. This effectively avoids the impact of low-priority messages on the processing delay of high-priority messages. A lock-free queue structure and token bucket algorithm are used to control traffic, ensuring that the processing latency of real-time messages is minimized (≤5ms). Simultaneously, the processing latency of other message types is also effectively controlled within an acceptable range. This mechanism ensures that the system will not experience delays due to the accumulation of low-priority messages when processing high-priority transaction instructions or alarm information, thus improving message processing efficiency and system response speed. Through reasonable scheduling and traffic control, it can maintain efficient message processing even under high load, avoiding system congestion and message starvation. This ensures that users can receive high-priority information in a timely manner at critical moments, thereby improving the reliability of the overall distributed response process and user experience.

[0049] Preferably, the message processing logic further includes an intelligent message retry and compensation mechanism, which includes:

[0050] Implement an exponential backoff retry strategy for failed session messages, by setting the initial retry interval to 50-100ms, doubling the retry interval each time, and retrying a maximum of more than 5 times.

[0051] At the same time, a replay prevention mechanism based on a unique message ID is used to ensure the idempotency of message processing;

[0052] If the message retry fails after reaching the maximum number of attempts, a compensation process is automatically triggered, routing the session message to a dedicated exception handling queue.

[0053] The exception handling queue adopts a combination of dead letter queue and manual intervention to classify and store session messages that still fail to retry and then notify the operation and maintenance personnel.

[0054] The intelligent message retry and compensation mechanism in this invention provides the system with strong fault tolerance. When processing failed session messages, the exponential backoff retry strategy ensures that multiple retries are automatically performed in the event of temporary network failures or service delays, improving the message processing success rate. The unique message ID anti-replay mechanism guarantees the idempotency of message processing and avoids data redundancy and errors caused by repeated processing. The compensation mechanism ensures that even if a message fails to complete the maximum number of retries, these abnormal messages are automatically transferred to a dedicated exception handling queue, and maintenance personnel are notified for manual intervention to ensure that the problem is handled in a timely manner. The combination of dead-letter queues and manual intervention enables the system to flexibly respond to abnormal situations, reduce the potential risks caused by message loss or processing failures, and improve the robustness and maintainability of the system. These mechanisms ensure the high reliability and continuous stable operation of distributed message response processing.

[0055] The present invention has the following specific beneficial effects:

[0056] (1) Construct a high-efficiency distributed message service cluster, in which each service node is equipped with a websocket communication module, message middleware and client. The websocket communication module is used to establish a real-time connection with the client to ensure that messages can be transmitted with low latency and high efficiency. The message middleware, as the message transmission and storage center, provides a reliable message transmission mechanism and avoids the risk of system crash due to single point of failure. The load balancer Nginx provides a unified access point at the front end and can intelligently distribute traffic to different service nodes according to the client's request, thereby realizing the load balance of the system, reducing the load pressure of a single node, and improving the overall system response speed and stability. Through these mechanisms, it can be expanded into a large-scale cluster architecture with high availability and fault tolerance, thereby ensuring that it can still maintain high efficiency when facing massive user requests and avoiding performance bottlenecks caused by hardware failure or traffic fluctuations. This step constructs a highly elastic and fault-tolerant distributed message service architecture.

[0057] (2) Upon startup, the service access point automatically registers with the message middleware and subscribes to global control topics. Simultaneously, it creates a dedicated response topic for each service node within the message middleware. This mechanism ensures that each node receives timely control information upon accessing the system, guaranteeing that all nodes remain synchronized with the system's global control logic. By creating dedicated response topics, the system can finely manage message processing for each node, preventing message conflicts or interference between different nodes. Furthermore, the hierarchical topic subscription structure optimizes the message routing mechanism, enabling service nodes to quickly identify and process relevant tasks based on message type, source, and purpose. This flexible topic management not only simplifies the message processing flow but also supports multi-level control and management, enhancing the system's scalability and flexibility.

[0058] (3) When the client initiates a WebSocket connection request, the Nginx load balancer intelligently distributes the request to the optimal service node through a preset dynamic load algorithm. In this way, Nginx can make the optimal allocation decision dynamically based on the current load of each node, network bandwidth and other factors, thereby ensuring the overall performance of the system is optimized. The optimal service node will generate a unique session identifier for the client and establish a connection with the client through a secure encrypted channel to ensure data transmission security and privacy protection during the communication process. This step can not only effectively distribute the system pressure, but also provide the client with a stable, secure and fast service experience, while enhancing the system's fault tolerance and load balancing capabilities, and avoiding the risks caused by single point of failure.

[0059] (4) The client sends a business request message through a secure channel, which includes the request type, target service identifier and business parameters. After receiving the message, the optimal service node will parse the message and encapsulate it into a standardized message format. This process ensures that requests from different sources can be transmitted in a unified format, making the subsequent processing logic simpler and more efficient. The standardized message format not only facilitates subsequent system processing and expansion, but also avoids processing errors or inconsistent responses caused by inconsistent message formats. In addition, through standardized processing, it can be better integrated with different service modules, thereby improving the maintainability and scalability of the system.

[0060] (5) The optimal service node publishes the standardized message format to the business topic queue in the message middleware according to the target service identifier in the business request. The role of the message middleware is to ensure the efficient and reliable delivery of messages, ensuring that each message arrives at its destination accurately and in a timely manner. During the publishing process, the service node also associates the client's session messages, thereby ensuring that the system can track the source of each request and correctly match it with the client in the final response. This mechanism effectively reduces the risk of message loss during message processing and improves the reliability of the system. At the same time, the topic queue structure of the message middleware enables the system to classify and process messages according to business modules, improving the efficiency and accuracy of distributed message processing, thereby better meeting the message connection and response process under high concurrency.

[0061] (6) Service nodes that subscribe to the corresponding business topic will perform intelligent filtering based on the load balancing factor in the received session message and their own resource status, select nodes that meet the processing conditions, and use them as actual processing nodes to execute message processing logic. The intelligent filtering mechanism enables dynamic evaluation of the processing capacity of each node, avoiding performance degradation due to the participation of overloaded nodes. This intelligent decision-making mechanism can make the optimal choice based on the real-time load, resource usage and service capacity of each node, ensuring the efficiency and stability of the system. In this way, adaptive load adjustment and dynamic optimization can be achieved, effectively improving resource utilization and reducing invalid or duplicate message processing, thus improving overall performance.

[0062] (7) The processing node generates the response result and publishes it to the dedicated response topic of the service node that initiated the request through the message middleware. The service node that initiated the request will obtain the response result from the dedicated response topic and push the result to the client in real time through the secure channel. This process ensures that the client can obtain the response result in a timely manner and at the same time ensures the security of data transmission. Real-time response can significantly improve the user experience, especially in scenarios that require real-time data interaction. This mechanism greatly improves the system's response speed and processing efficiency. Through the association of session messages, it can ensure that each client's request receives an accurate and fast response, thereby avoiding delays in distributed message response. Attached Figure Description

[0063] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0064] Figure 1 This is a flowchart illustrating the steps of the distributed message dynamic response method based on WebSocket of the present invention.

[0065] Figure 2 This is a schematic diagram illustrating the steps involved in establishing a secure channel according to the present invention. Detailed Implementation

[0066] The present invention will be further described below with reference to the accompanying drawings and embodiments, but this should not be construed as limiting the present invention.

[0067] To achieve the above objectives, please refer to Figures 1 to 2 This invention provides a distributed message dynamic response method based on WebSocket, such as... Figure 1 As shown, it includes the following steps:

[0068] S1: Construct a distributed message service cluster. Each service node in the distributed message service cluster is configured with a websocket communication module, message middleware, and client, and provides a unified service access point to the outside world through an Nginx load balancer.

[0069] In this embodiment of the invention, each service node is configured in a standardized manner when building the distributed message service cluster. Hardware-wise, a server equipped with a 48-core CPU, 256GB of memory, and a 10GbE network card is used as the hardware carrier for the service nodes. Each service node is equipped with a WebSocket communication module, which is implemented based on the RFC 6455 standard, supports full-duplex communication, and transmits data through TCP port 8080. Apache Kafka is deployed as the message middleware, using a 3-node cluster mode. Zookeeper version 3.6.3 is used for cluster management and metadata storage. The client-side is a customized application module developed according to business needs, with functions such as data encryption and message serialization. The Nginx load balancer uses four physical servers to build a high-availability cluster and is configured with a stream module for TCP / UDP load balancing. External services are uniformly provided through port 80 to ensure that external clients can access the service through the standard HTTP protocol port.

[0070] S2: When the service access point starts, it automatically registers with the message middleware and subscribes to the global control topic. At the same time, it creates a dedicated response topic based on the node identifier in the message middleware, forming a hierarchical topic subscription structure.

[0071] In this embodiment of the invention, when the service access point starts, it performs a series of strict initialization operations. After the service access point program, implemented in Java, starts, it registers with the Apache Kafka message middleware through the Kafka client API. During the registration process, the SASL / SCRAM-SHA-256 authentication mechanism is used to send the service access point's identity credentials (including username and password hash value) to the message middleware for verification. After successful registration, it automatically subscribes to the global control topic "global_control_topic", which is used to receive global commands from the cluster management system, such as configuration updates and node management. Simultaneously, based on the service node's UUID as the node identifier, a dedicated response topic is created in the message middleware, such as "node_ <uuid>When creating a topic, the number of partitions is set to 8 and the replication factor to 3 to ensure the reliability of message storage and read performance. This forms a hierarchical subscription structure of "global topic - node-specific topic" to achieve accurate message distribution and processing.

[0072] S3: When the client initiates a WebSocket connection request, the Nginx load balancer allocates the connection to the optimal service node based on a preset dynamic load algorithm. The optimal service node generates a unique session identifier for the client and establishes a secure channel.

[0073] In this embodiment of the invention, when a client initiates a WebSocket connection request, the Nginx load balancer allocates connections according to a preset dynamic load algorithm. Nginx monitors the connection count, CPU utilization, memory utilization, and other indicators of each service node in real time, collecting data every 500 milliseconds. A weighted minimum connection count algorithm is used, with connection count accounting for 40%, CPU utilization accounting for 30%, and memory utilization accounting for 30%. For example, when a client initiates a connection request to Nginx's port 80, Nginx calculates the comprehensive load value of each service node and allocates the connection to the service node with the lowest load value. After receiving the connection request, the service node generates a unique 32-bit UUID format session identifier for the client through Java's WebSocket API. At the same time, a secure channel is established based on the TLS 1.3 protocol, and the transmitted data is encrypted using the AES-256-GCM symmetric encryption algorithm to ensure data transmission security.

[0074] S4: The client sends a business request message through the secure channel. The business request message includes a request type, a target service identifier, and business parameters. After receiving the message, the optimal service node parses the message content and encapsulates it into a standardized message format.

[0075] In this embodiment of the invention, the client sends a business request message through an established secure channel. The message content is serialized in JSON format. For example, an order query request message has the format {"request_type": "order_query", "target_service_identifier": "order_service_001", "business_parameters": {"order_id": "123456"}}. After receiving the message, the optimal service node parses the message content into a Java object using the Jackson JSON parsing library, extracting information such as the request type, target service identifier, and business parameters. Subsequently, the parsed message is encapsulated according to a predefined Protobuf format, adding a message header (containing message version number, message ID, and timestamp) and a message body to form a standardized message format. This facilitates efficient transmission and processing in a distributed system, while ensuring consistency and compatibility of message interaction between different service nodes.

[0076] S5: The optimal service node publishes the standardized message format to the corresponding business topic queue through the message middleware according to the target service identifier in the message, and at the same time associates it with the client's session message;

[0077] In this embodiment of the invention, after the optimal service node receives the standardized business message from the client, it performs topic routing based on the target service identifier. The message middleware uses the Apache Kafka producer API to publish the message to the corresponding business topic queue. For example, if the target service identifier is "order_service", the message is published to the "order_topic" queue. Each business topic is configured with 16 partitions. The storage partition is determined by taking the modulo of the number of partitions with the hash value of the message ID. At the same time, the client's session messages (such as session ID, connection node IP, etc.) are appended to the Kafka message as extended fields in the message header and serialized using the Protobuf format. The producer is configured with acks=all to ensure that the message is written to the logs of at least all replicas before returning a success response, thus ensuring the reliability of the message.

[0078] S6: After receiving the session message, all service nodes subscribing to the corresponding business topic within the hierarchical topic subscription structure perform intelligent filtering based on the load balancing factor in the session message and their own resource status, and select nodes that meet the processing conditions as processing nodes to execute message processing logic and generate response results.

[0079] In this embodiment of the invention, service nodes subscribing to the corresponding business topics receive messages through the Kafka consumer group mechanism. Each service node maintains a local resource status table, updating metrics such as CPU utilization, memory utilization, and thread pool activity every 200 milliseconds. When a session message is received, the load balancing factor in the message header is first parsed (this factor is set by the client according to the request priority, ranging from 0 to 1), and then filtered in combination with its own resource status. For example, when the load balancing factor is 0.8, only service nodes with CPU utilization below 30% and more than 10 idle threads in the thread pool will process the message. This intelligent filtering mechanism is implemented through Java's CompletableFuture asynchronous framework, ensuring that the decision is completed within 50 milliseconds. The processing nodes that meet the conditions call the corresponding business logic processing method through reflection and encapsulate the processing result into a standardized response object.

[0080] S7: The processing node publishes the response result to the dedicated response topic of the requesting service node through the message middleware, and after obtaining the response result from the dedicated response topic, pushes the response result to the client in real time through the secure channel according to the session message.

[0081] In this embodiment of the invention, the processing node publishes the response result to the dedicated response topic of the requesting service node through a Kafka producer. The response message includes information such as session ID, processing result, and timestamp, and is serialized using Avro format to improve transmission efficiency. The requesting service node subscribes to its own dedicated topic through a Kafka consumer, employing a long polling mechanism (poll timeout set to 30 seconds) to ensure timely response retrieval. When a response message is received, the corresponding WebSocket connection is looked up using the session ID, and the response result is sent to the client in text frame form using the Java WebSocket API. The entire process is encrypted using TLS, and data transmission security is ensured by using the corresponding ECDHE-RSA-AES256-GCM-SHA384 cipher suite. For large data responses exceeding 1MB, a fragmented transmission mechanism is used, with each fragment being 64KB in size, and the fragments are reassembled on the client side. Furthermore, in point-to-point communication, if the receiving WebSocket connection is on the same service node, the message is pushed directly through the local session; if they are on different service nodes, the message is encapsulated in an MQ (Message Queued). For queued messages, the service node pushes the message to the designated queue. Once the service node where the recipient is located receives the queued message, it sends the message to the recipient. For broadcast messages, the service node encapsulates the message into an MQ TOPIC message and sends it to the corresponding TOPIC channel. Service nodes that subscribe to the TOPIC receive the message, determine whether there is a matching receiving client in the service node, and if so, push the message to the corresponding client via WebSocket.

[0082] Furthermore, the Nginx load balancer employs a dynamic load algorithm that combines multi-dimensional metrics such as real-time CPU utilization, memory usage, number of WebSocket connections, message processing queue length, and network I / O throughput of service nodes. It calculates the node load index using a weighted scoring model and then selects and assigns the service to the optimal node based on the node load index, updating the load status every 250-500 milliseconds.

[0083] In this embodiment of the invention, the Nginx load balancer implements a dynamic load algorithm through Lua scripts. Every 250-500 milliseconds, Nginx sends an HTTP request to the monitoring API (exposed on port 9100) of each service node to obtain real-time CPU utilization (calculated via / proc / stat), memory usage (read from / proc / meminfo), number of websocket connections (netstat statistics of TCP 8080 port connections), message processing queue length (Kafka's Consumer Lag metric), and network I / O throughput (ifconfig statistics of eth0 interface traffic). Each metric is normalized to a value of 0-100. A node load index is calculated through a weighted scoring model: CPU accounts for 30%, memory accounts for 20%, number of connections accounts for 25%, queue length accounts for 15%, and network throughput accounts for 10%. The Lua script stores the load index of each node in a shared memory area (shm zone). When a new connection request arrives, the node with the lowest load index is selected. If multiple nodes have the same index, the node with the shortest response time is selected first.

[0084] Furthermore, when the number of WebSocket connections corresponding to the service node exceeds 8000 concurrent connections, the connection migration mechanism within the Nginx load balancer is automatically triggered to achieve a smooth transfer through the TCP slow start protocol, and to ensure that the migration packet loss rate is ≤0.1%.

[0085] In this embodiment of the invention, the connection migration mechanism is implemented by Nginx's stream module and a custom Lua script. When the number of WebSocket connections on a service node reaches 8000, the monitoring system sends a migration command to Nginx. Nginx first marks the node as "draining" and stops allocating new connections. Then, it gradually migrates existing connections to other nodes using the TCP slow start protocol (with an initial congestion window set to 2 MSS). During the migration process, Nginx maintains two connections: the old connection receives client data, and the new connection sends data to the target node. The old connection is closed only when no data is transmitted within 10 seconds. The entire migration process uses Netfilter's CONNMARK mechanism to mark the connection status, ensuring that the packet loss rate is controlled within 0.1%. After the migration is complete, Nginx updates the node status information in the shared memory area.

[0086] Furthermore, such as Figure 2 As shown, the establishment of the secure passage includes the following steps:

[0087] S301: Generate a temporary key pair based on elliptic curve cryptography through the optimal service node, and authenticate the client through a pre-shared root certificate;

[0088] In this embodiment of the invention, the optimal service node uses the Bouncy Castle library to generate a temporary key pair based on the secp384r1 curve. When the client connects, the service node sends a pre-shared root certificate (stored in the / etc / ssl / certs directory of Nginx). The client uses a built-in certificate verification module (such as OpenSSL) to verify the identity of the service node. After successful verification, the client sends its own certificate (issued by an enterprise CA). The service node uses the public key of the root certificate to verify the signature and validity period of the client certificate. If the certificate chain verification fails, the connection is terminated immediately.

[0089] S302: The TLS 1.3 protocol is used to establish an encrypted transport layer, and the ECDHE key exchange algorithm is used to generate session keys to achieve forward security;

[0090] In this embodiment of the invention, an encrypted transport layer is established using the TLS 1.3 protocol. The service node and the client generate a shared key using the ECDHE key exchange algorithm (using the x25519 curve). During the handshake process, both parties negotiate to use the TLS_AES_256_GCM_SHA384 cipher suite to achieve forward security. The service node is configured with OCSP Stapling to include certificate status information (obtained by periodically querying the CA's OCSP server) in the TLS handshake message, reducing client verification latency. The entire handshake process is completed within 3 RTTs, and a session ticket mechanism is used to achieve 0-RTT recovery.

[0091] S303: WebSocket frame data is processed using a three-level compression-encryption-signature process. First, the data is compressed using the Brotli algorithm, then encrypted using AES-256-GCM, and finally an HMAC-SHA256 message authentication code is attached to ensure data integrity and prevent tampering.

[0092] In this embodiment of the invention, the WebSocket frame data is processed in three levels. Before data is sent, it is compressed using the Brotli algorithm (compression level set to 5) to reduce the size of a typical JSON message by more than 60%. The compressed data is then encrypted using AES-256-GCM. Each WebSocket session uses an independent encryption key (derived from HKDF). The encrypted data is appended with an HMAC-SHA256 message authentication code, which is the same as the AES key. The receiving end processes the data in reverse order: first verifying the HMAC, then decrypting the data, and finally decompressing it. The entire processing flow is implemented through the OpenSSL EVP interface, and hardware acceleration (such as the Intel AES-NI instruction set) is used to ensure that the performance overhead is less than 5%.

[0093] Furthermore, the standardized message format is encapsulated using JSON Web Token, which includes the following fields:

[0094] Message header: contains message ID, timestamp, version number, signature algorithm, and compression flag;

[0095] Message body: includes request type, target service identifier, business parameters, load balancing factor, and priority flag;

[0096] Message footer: Includes the message source node identifier, encryption key fingerprint, and response topic address.

[0097] In this embodiment of the invention, the standardized message format encapsulation is implemented based on the JSON Web Token (JWT) specification. In the message header, the message ID uses a 128-bit UUID. The v4 standard is generated by the service node's hardware random number generator (HRNG) combined with timestamp information to ensure global uniqueness. The timestamp is accurate to milliseconds and uses the Unix timestamp format to record the message generation time. The version number is fixed at "v1.0" to identify the message format specification. The signature algorithm uses RS256, and the service node's private key is used to sign the message body and message header. The compression flag is a boolean value, which is set to "true" when the business parameters exceed 1024 bytes to enable the Brotli compression algorithm. In the message body, the request type uses a predefined enumeration value (such as "order_query" "user_update"), the target service identifier corresponds to the business topic name, the business parameters are serialized in JSON format, the load balancing factor is initialized to 0, and the priority flag is divided into three types: "urgent", "norma", and "low" according to the business scenario. In the message tail, the message source node identifier is the unique identifier of the service node, the encryption key fingerprint is the SHA-256 hash value of the session key, and the response topic address points to the exclusive response topic of the service node that initiated the request.

[0098] Furthermore, the method for generating the load balancing factor is as follows:

[0099] Extract key feature values ​​from the business parameters, including user ID, business type, and data volume;

[0100] In this embodiment of the invention, key feature values ​​are extracted by parsing business parameters. Taking a user order query request as an example, the business parameters are {"user_id": "U123456", "order_type": "online", "order_num": 10}. Using regular expression matching rules, the user ID (U123456), business type (online), and data size (estimated by the order quantity of 10) are extracted from the business parameters. For complex business parameters, such as JSON data containing nested structures, a recursive parsing algorithm is used to traverse all levels to ensure that no key feature values ​​are missed. The extraction process is completed in the memory of the service node, using a high-performance JSON parsing library (such as Jackson) to ensure parsing efficiency.

[0101] Furthermore, the key feature values ​​are input into a pre-trained neural network model, which uses the historical performance data corresponding to the optimal service node as a training set and outputs a load balancing factor in the range of 0-1.

[0102] In this embodiment of the invention, the pre-trained neural network model adopts a multilayer perceptron (MLP) structure, containing three hidden layers with 64, 32, and 16 neurons in each layer, respectively. The activation function is ReLU. The training set consists of 100,000 historical messages processed by the best service node in the past 30 days. Each message contains key feature values ​​(user ID, business type, data size) and performance metrics of the service node when processing the message (CPU utilization, memory usage, processing time). The model is trained using the Adam optimizer with a learning rate of 0.001 and a training period of [missing information]. The process consists of 50 rounds. When a new business request arrives, the extracted key feature values ​​are normalized and then input into the model. The model outputs a value between 0 and 1 as a load balancing factor. Specifically, the user ID is mapped to a 64-bit integer using the MurmurHash3 algorithm, and then Z-score normalization is performed to scale it to the [0, 1] interval. For example, the user ID "U123456" is hashed to 0x9a3d7e5f2b1c4d6, and after normalization, it yields 0.783. A business type dictionary is also established, such as {"online": 0.2, "offline": 0.5, "batch":}. 0.8}, directly mapping the business type to the corresponding value, estimating the data volume through the number of orders or the length of the data field, and using Min-Max normalization to convert it to a value in the range [0, 1]. For example, 10 orders correspond to a normalized value of 0.35. Training data collection involves collecting historical messages processed by service nodes for 30 consecutive days. Each record includes: input features: user ID hash value, business type code, and data volume normalized value; target labels: node load indicators (CPU utilization, memory usage, response time, etc.) when processing the message. Model The model structure and training employed TensorFlow 2.8 to construct an MLP model. The input layer had 3 neurons, the hidden layer structure was 64-32-16, and the output layer had 1 neuron. Mean Squared Error (MSE) was used as the loss function, and Adam was selected as the optimizer (learning rate 0.001). The training cycle was 50 epochs with a batch size of 128. Early stopping was used to prevent overfitting. Preprocessed feature vectors were input into the trained model, and the initial load balancing factor L0 (range 0-1) was output. For example, for an input vector [0.783, 0.2, 0.35]... Output L0=0.32. Collect real-time node metrics every 500 milliseconds: CPU utilization (C), memory usage (M), number of connections (N), and queue length (Q). Calculate the comprehensive load index: L = 0.4C + 0.3M + 0.2N + 0.1Q (all metrics have been normalized). Classify node status based on L value: Low load: L < 0.3 → weighting coefficient α = 0.8; Medium load: 0.3 ≤ L < 0.7 → weighting coefficient α = 1.0; High load: L ≥ 0.7 → weighting coefficient α = 1.2. Therefore, the corresponding factor adjustment formula is: L1 = L0 × α × (1 + β), where β is the network congestion compensation factor, dynamically adjusted based on the current network bandwidth utilization (range -0.1 to 0.1). For example, inputting the normalized vector corresponding to the user ID, service type, and data size, the model outputs 0.3, indicating that the load level of the request is relatively low.

[0103] Furthermore, the load balancing factor is weighted and adjusted to dynamically allocate weights based on the current load status.

[0104] In this embodiment of the invention, the load balancing factor is dynamically adjusted based on the current load status. Each service node collects its own load data every 500 milliseconds, including CPU utilization, memory usage, WebSocket connections, and message processing queue length. Based on these metrics, the load status of the service node is divided into three levels: "low load," "medium load," and "high load." When a service node is under low load, the load balancing factor is multiplied by a weight of 0.8; under medium load, the weight is 1.0; and under high load, the weight is 1.2. For example, if the model outputs a load balancing factor of 0.3, and the current service node is under high load, the adjusted load balancing factor is 0.3 × 1.2 = 0.36. This makes the load distribution more reasonable, avoids over-distributing requests to high-load nodes, and ensures the overall performance and stability of the distributed system.

[0105] Furthermore, the intelligent filtering process includes the following steps:

[0106] After receiving the session message, the service node first verifies the message signature and encryption integrity, and then parses the load balancing factor.

[0107] In this embodiment of the invention, after receiving a session message, the service node performs message verification based on the JWT specification. The message signature verification uses the RS256 algorithm. The service node uses a pre-shared public key to perform hash calculations on the message header and message body, and compares them with the signature carried in the message tail. If the signatures do not match, the message is discarded directly. If the signature verification passes, the encrypted key fingerprint in the message tail is checked. By performing SHA-256 hash calculations with the locally stored session key and comparing them, it is ensured that the message has not been tampered with during transmission. After verification, the service node uses a JSON parser to extract the load balancing factor in the message body. For example, the load balancing factor of 0.36 is obtained from the message body {"request_type": "order_query", "target_service_identifier": "order_service", "business_parameters": {"user_id": "U123456", "order_num": 10}, "load_balance_factor": 0.36, "priority_mark": "normal"}.

[0108] Furthermore, the self-resource status is compared with the load balancing factor to calculate the matching score;

[0109] In this embodiment of the invention, the service node compares its own resource status with the load balancing factor to calculate a matching score. The service node collects its own resource status data every 200 milliseconds, including CPU utilization, memory usage, number of WebSocket connections, and message processing queue length. Each indicator is normalized to the range [0-1]. For example, a service node currently has a CPU utilization of 0.2 (20%), a memory usage of 0.3 (30%), and a number of WebSocket connections of 5000 (maximum number of connections is 8000, corresponding to a value of 0). The values ​​are 0.625 and 80 (maximum queue length 100, corresponding to a value of 0.8). These values ​​are compared with the load balancing factor of 0.36. A weighted calculation method is used, with CPU utilization accounting for 30%, memory utilization accounting for 20%, WebSocket connection count accounting for 25%, and message processing queue length accounting for 25%. The matching score is calculated as follows: (0.2×0.3+0.3×0.2+0.625×0.25+0.8×0.25) / 0.36×100%=78.47%.

[0110] Furthermore, if the matching score exceeds 75%, the local business processing module is further checked to see if it supports the request type.

[0111] In this embodiment of the invention, when the matching score exceeds 75%, the service node further checks whether the local business processing module supports the request type. The service node has a built-in business type registry that records all supported request types, such as {"order_query": true, "user_update": true, "payment_process": false}. Taking the received "order_query" request type as an example, the service node checks the registry to confirm that the local business processing module supports the request type before continuing the subsequent process; if it does not support it, the session message is directly rejected.

[0112] Furthermore, for supported request types, check if the current processing queue length exceeds 80% of the maximum capacity; if not, receive the session message and process it.

[0113] In this embodiment of the invention, for supported request types, the service node checks whether the current processing queue length exceeds 80% of the maximum capacity. For example, if the maximum capacity of the message processing queue is 100 and the current queue length is 70, which does not exceed 80 (100 × 80%), the service node receives the session message and adds it to the processing queue for processing. If the current queue length is 85, which exceeds 80, the service node refuses to receive the session message to avoid queue overload causing message processing delays or loss, and to ensure the stable operation of the service node.

[0114] Furthermore, it also includes a distributed session management mechanism, which includes:

[0115] The session messages are stored in a distributed key-value store based on the Raft consensus algorithm to ensure strong consistency of the session messages among the distributed message service cluster.

[0116] In this embodiment of the invention, session messages are stored in a distributed key-value storage system based on the Raft consensus algorithm. This system consists of three independent storage servers running etcd version 3.5 software. Each server is configured with a RAID10 disk array to ensure data reliability. Session messages are stored in key-value pairs. The key is the client's unique session identifier (32-bit UUID format), and the value contains session status, connection node information, incomplete message queues, etc. Protocol Buffers are used for serialization. The Raft algorithm elects a leader node to handle write operations. When a new session message is written, the client first sends the data to the leader node. The leader node synchronizes the data to the follower nodes via AppendEntries RPC. Only after receiving confirmation from more than half of the nodes (two or more) will the data be committed and a success response returned, ensuring strong consistency of data across all nodes.

[0117] Furthermore, set dual expiration times for each session message, including the websocket connection timeout and the session message retention time, which are set to 15-30 minutes and 12-24 hours by default, respectively.

[0118] In this embodiment of the invention, the dual expiration time mechanism is implemented in the session management module of the service node. The default timeout for the WebSocket connection is set to 20 minutes (15-30 minutes), and the default retention time for session messages is set to 18 hours (12-24 hours). These time parameters can be dynamically adjusted through the configuration file. When each session is created, the service node starts two independent timers: one timer is used to monitor the WebSocket connection status. If no heartbeat packet or data frame is received from the client within 20 minutes, the connection is determined to have timed out; the other timer is used to control the storage duration of session messages. It starts counting from the end of the session and automatically deletes the corresponding storage record after 18 hours. The timers are implemented using a high-precision time wheel algorithm to reduce system resource consumption and ensure efficient operation in large-scale session management scenarios.

[0119] Furthermore, when the client's WebSocket connection is disconnected, the session migration logic is automatically triggered to migrate the unfinished session messages to other available service nodes and notify the relevant business modules through the message middleware;

[0120] In this embodiment of the invention, when the client's WebSocket connection is disconnected, the network listener module of the service node immediately detects the TCP connection closure event. The service node first queries the information of the session in the distributed key-value store. If there are unfinished message processing tasks (such as order submissions that have not yet returned results), the session migration logic is initiated. The list of currently available service nodes is obtained through the Nginx load balancer, and the node with the lowest load is selected as the target node. The producer of the message middleware (Apache Kafka) serializes the unfinished session messages into Avro format and sends them to the dedicated topic corresponding to the target node. After the consumer of the target node listens for the message, it restores the session messages to its local memory and notifies the relevant business modules (such as the order processing module) through an RPC call. The business modules continue to process the unfinished tasks according to the session status.

[0121] Furthermore, when the client reconnects, it is preferentially assigned to the original service node. If the original service node is unavailable, the session state is quickly restored based on the session message.

[0122] In this embodiment of the invention, when a client re-initiates a WebSocket connection request, the Nginx load balancer first checks the status of the original service node corresponding to the client's session identifier. If the original service node is online and under normal load, the connection is directly allocated to the original node. If the original node is unavailable (e.g., due to hardware failure or software crash), Nginx reads the complete information of the session from the distributed key-value store, including unfinished message queues, session parameters, etc. After receiving the connection, the newly allocated service node reconstructs the session state based on the read session messages and resumes the unfinished message processing tasks. For example, if the client was previously performing a payment operation, after reconnecting, the new service node can obtain parameters such as the payment order number and amount from the session messages and continue to call the payment interface to complete the transaction process, ensuring that the client is unaware of the state recovery process.

[0123] Furthermore, the execution message processing logic processes the corresponding session messages through a message priority scheduling mechanism, which includes:

[0124] The session messages are divided into four levels, including real-time messages, high-priority messages, normal messages, and low-priority messages. The real-time messages include transaction instructions and alarm information, the high-priority messages include status updates and user operations, the normal messages include notifications and announcements, and the low-priority messages include statistical data and batch synchronization.

[0125] In this embodiment of the invention, the session message classification is achieved through the priority marker field in the message header. When the service node receives a message, it first parses the priority_mark field in the message body. If the value of this field is "real_time", it is determined to be a real-time message, including transaction instructions (such as stock trading instructions) and alarm information (such as system anomaly alarms). If it is "high", it is classified as a high-priority message, covering status updates (such as order payment status changes) and user operations (such as account balance inquiries). "normal" corresponds to ordinary messages, including notifications (such as activity reminders) and announcements (such as system upgrade notifications). "low" is a low-priority message, including statistical data (such as daily transaction reports) and batch synchronization (such as periodic data synchronization between data centers). Each message type has a corresponding topic queue in the distributed message service cluster. For example, real-time messages are sent to realtime_topic, and high-priority messages are sent to high_priority_topic, etc.

[0126] Furthermore, separate processing threads and queues are allocated to session messages of different priorities, and the queues adopt a lock-free queue structure to reduce processing latency.

[0127] In this embodiment of the invention, session messages of different priorities are managed by independent processing threads and lock-free queues. The service node creates a dedicated thread pool for each priority: the real-time message thread pool is configured with 8 core threads, 4 for high priority, 2 for normal priority, and 1 for low priority. Each thread pool corresponds to a lock-free queue, which is implemented using Java's ConcurrentLinkedQueue to avoid the context switching overhead caused by traditional lock mechanisms. For example, the real-time message queue receives messages from realtime_topic, and the threads in the thread pool continuously retrieve messages from the queue for processing. When a new message arrives, it is routed to the corresponding queue according to its priority. For example, transaction instructions directly enter the real-time message queue and are processed by the real-time thread pool, ensuring that critical business is not blocked by low-priority tasks.

[0128] Furthermore, the reduction in processing latency is achieved through flow control based on the token bucket algorithm to ensure that the processing latency of real-time messages is ≤5ms, 5ms < the processing latency of high-priority messages is ≤10ms, 10ms < the processing latency of ordinary messages is ≤15ms, and 15ms < the processing latency of low-priority messages is ≤20ms, while simultaneously preventing starvation of session messages of different priorities.

[0129] In this embodiment of the invention, flow control is implemented using a token bucket algorithm, allocating an independent token bucket for each priority level: the real-time message bucket has a capacity of 1000 tokens and a generation rate of 100 tokens / millisecond; the high-priority bucket has a capacity of 500 tokens and a generation rate of 50 tokens / millisecond; the normal bucket has a capacity of 300 tokens and a generation rate of 30 tokens / millisecond; and the low-priority bucket has a capacity of 100 tokens and a generation rate of 10 tokens / millisecond. When a message arrives at the queue, it needs to acquire a token from the corresponding token bucket before it can be processed. If a real-time message cannot acquire a token, it discards messages in the low-priority queue to free up resources. High-priority messages can preempt resources from the normal queue when there are insufficient tokens, but this does not affect the real-time queue. The normal and low-priority queues are processed strictly according to the token rate. Through this mechanism, it is ensured that the processing latency of real-time messages is always ≤5ms (the time from receiving the response), high-priority messages ≤10ms, normal messages ≤15ms, and low-priority messages ≤20ms. At the same time, each queue is set with a minimum processing threshold, such as the low-priority queue processing at least one message every 500ms to prevent starvation.

[0130] Furthermore, the execution message processing logic also includes an intelligent message retry and compensation mechanism, which includes:

[0131] Implement an exponential backoff retry strategy for failed session messages, by setting the initial retry interval to 50-100ms, doubling the retry interval each time, and retrying a maximum of more than 5 times.

[0132] In this embodiment of the invention, if a service node encounters a processing failure (such as network interruption or business logic exception) while processing session messages, it immediately initiates an exponential backoff retry strategy. Taking Java implementation as an example, the service node uses the TimerTask class to create a scheduled task, with an initial retry interval set to 80ms. When the first processing fails, the system records the failure timestamp and triggers the first retry after 80ms. If the retry still fails, the interval is doubled to 160ms, and the retry operation is performed again. This process is repeated up to 5 times. Before each retry, the current system load status is checked. If the CPU utilization exceeds 80%, the retry operation is paused and resumed after the load decreases. For example, if a real-time transaction instruction fails to process due to a brief failure of the target service node, the system will attempt to reprocess it sequentially after 80ms, 160ms, 320ms, 640ms, and 1280ms according to the exponential backoff strategy, ensuring that the task is completed in a timely manner when the fault is recovered.

[0133] Furthermore, a replay prevention mechanism based on a unique message ID is implemented to ensure the idempotency of message processing.

[0134] In this embodiment of the invention, the anti-replay mechanism achieves idempotency in message processing based on message IDs. Each session message is assigned a unique 32-bit UUID format message ID upon generation and stored in the message header. After receiving a message, the service node first queries the Redis distributed cache system to see if the message ID has already been processed. Redis uses a single-threaded model to quickly retrieve the message ID in memory. If a record with the same ID exists, the message is discarded directly; otherwise, the message ID is written to Redis as a key-value pair, and the expiration time is set to the message processing lifecycle (e.g., 1 hour). Simultaneously, the message processing logic is executed. For example, if a user sends the same account balance query request twice consecutively, and the message ID carried in the second request already exists in Redis, the service node directly returns the processing result of the first request, avoiding data inconsistency caused by duplicate processing.

[0135] Furthermore, if the message retry fails after reaching the maximum number of attempts, a compensation process is automatically triggered to route the session message to a dedicated exception handling queue.

[0136] In this embodiment of the invention, when a session message fails to be processed after more than 5 retries, the service node automatically triggers a compensation process. The system routes the message to a dedicated exception handling queue, exception_topic, through the producer of a message middleware (such as Apache Kafka). Before sending, additional failure metadata is added to the message, including the failure time, error logs for each retry (such as HTTP status codes and business exception information), and the message format is converted to JSON for easy subsequent analysis. For example, if a batch synchronization task fails after more than 5 retries due to an incorrect data source format, the message is encapsulated in JSON format containing detailed error information and sent to the exception handling queue for further processing.

[0137] Furthermore, the exception handling queue adopts a combination of dead letter queue and manual intervention to classify and store session messages that still fail to retry and then notify the operation and maintenance personnel.

[0138] In this embodiment of the invention, an exception handling queue employs a combination of dead-letter queues and manual intervention. The dead-letter queue is constructed using RabbitMQ, with the parameters `x-dead-letter-exchange` and `x-dead-letter-routing-key` set. Failed messages are automatically forwarded to the dead-letter queue (`dead_letter_queue`). Messages in the dead-letter queue are stored according to failure type (e.g., network error, data error, business logic error), with each category corresponding to a sub-queue. Simultaneously, the system sends alarm emails to operations and maintenance personnel via an email server (e.g., SendGrid). The email content includes the message ID, failure reason, and the complete message content. Operations and maintenance personnel can log in to the monitoring and management platform to manually process messages in the dead-letter queue, such as correcting data and resending, or marking them as processed, ensuring that all failed messages are properly resolved.

[0139] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0140] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.< / uuid>

Claims

1. A distributed message dynamic response method based on WebSocket, characterized by: Includes the following steps: A distributed message service cluster is constructed, wherein each service node in the distributed message service cluster is configured with a websocket communication module, message middleware and client, and provides a unified service access point to the outside world through an Nginx load balancer; When the service access point starts, it automatically registers with the message middleware and subscribes to the global control topic. At the same time, it creates a dedicated response topic based on the node identifier in the message middleware, forming a hierarchical topic subscription structure. When the client initiates a WebSocket connection request, the Nginx load balancer allocates the connection to the optimal service node based on a preset dynamic load balancing algorithm. The optimal service node generates a unique session identifier for the client and establishes a secure channel. The establishment of the secure channel includes the following steps: The optimal service node generates a temporary key pair based on elliptic curve encryption, and the client is authenticated using a pre-shared root certificate. A cryptographic transport layer is established using the TLS 1.3 protocol, and a session key is generated using the ECDHE key exchange algorithm to achieve forward security. WebSocket frame data is processed using a three-level process of compression, encryption, and signature. First, the data is compressed using the Brotli algorithm, then encrypted using AES-256-GCM, and finally an HMAC-SHA256 message authentication code is added to ensure data integrity and prevent tampering. The client sends a business request message through the secure channel. The business request message includes a request type, a target service identifier, and business parameters. After receiving the message, the optimal service node parses the message content and encapsulates it into a standardized message format. The optimal service node publishes the standardized message format to the corresponding business topic queue through the message middleware according to the target service identifier in the message, and at the same time associates it with the client's session message; After receiving the session message, all service nodes subscribing to the corresponding business topic within the hierarchical topic subscription structure perform intelligent filtering based on the load balancing factor in the session message and their own resource status, and select nodes that meet the processing conditions as processing nodes to execute message processing logic and generate response results. The processing node publishes the response result to the dedicated response topic of the requesting service node through the message middleware, and after obtaining the response result from the dedicated response topic, pushes the response result to the client in real time through the secure channel according to the session message.

2. The distributed message dynamic response method based on WebSocket according to claim 1, characterized in that: The Nginx load balancer uses a dynamic load algorithm that combines multi-dimensional metrics such as real-time CPU utilization, memory usage, number of WebSocket connections, message processing queue length, and network I / O throughput of service nodes. It calculates the node load index through a weighted scoring model and selects and assigns the service to the optimal node based on the node load index, updating the load status every 250-500 milliseconds.

3. The distributed message dynamic response method based on WebSocket according to claim 2, characterized in that: When the number of WebSocket connections corresponding to the service node exceeds 8000 concurrent connections, the connection migration mechanism in the Nginx load balancer is automatically triggered to achieve a smooth transfer through the TCP slow start protocol and ensure that the migration packet loss rate is ≤0.1%.

4. The distributed message dynamic response method based on WebSocket according to claim 1, characterized in that: The standardized message format is encapsulated using JSON Web Token, which includes the following fields: Message header: contains message ID, timestamp, version number, signature algorithm, and compression flag; Message body: includes request type, target service identifier, business parameters, load balancing factor, and priority flag; Message footer: Includes the message source node identifier, encryption key fingerprint, and response topic address.

5. The distributed message dynamic response method based on WebSocket according to claim 4, characterized in that: The method for generating the load balancing factor is as follows: Extract key feature values ​​from the business parameters, including user ID, business type, and data volume; The key feature values ​​are input into a pre-trained neural network model, which uses the historical performance data corresponding to the optimal service node as a training set and outputs a load balancing factor in the range of 0-1. The load balancing factor is weighted and adjusted to dynamically allocate weights based on the current load status.

6. The distributed message dynamic response method based on WebSocket according to claim 1, characterized in that: The intelligent filtering process includes the following steps: After receiving the session message, the service node first verifies the message signature and encryption integrity, and then parses the load balancing factor. The self-resource status is compared with the load balancing factor to calculate the matching score; If the matching score exceeds 75%, then further check whether the local business processing module supports this request type; For supported request types, check if the current processing queue length exceeds 80% of the maximum capacity. If it does not exceed this limit, receive the session message and process it.

7. The distributed message dynamic response method based on WebSocket according to claim 1, characterized in that: It also includes a distributed session management mechanism, which includes: The session messages are stored in a distributed key-value store based on the Raft consensus algorithm to ensure strong consistency of the session messages among the distributed message service cluster. Set dual expiration times for each session message, including the WebSocket connection timeout and the session message retention time, which are set to 15-30 minutes and 12-24 hours by default, respectively. When the client's WebSocket connection is disconnected, the session migration logic is automatically triggered to migrate the unfinished session messages to other available service nodes and notify the relevant business modules through the message middleware. When the client reconnects, it is preferentially assigned to the original service node. If the original service node is unavailable, the session state is quickly restored based on the session message.

8. The distributed message dynamic response method based on WebSocket according to claim 1, characterized in that: The execution message processing logic processes the corresponding session messages through a message priority scheduling mechanism, which includes: The session messages are divided into four levels, including real-time messages, high-priority messages, normal messages, and low-priority messages. The real-time messages include transaction instructions and alarm information, the high-priority messages include status updates and user operations, the normal messages include notifications and announcements, and the low-priority messages include statistical data and batch synchronization. At the same time, independent processing threads and queues are allocated for session messages of different priorities. The queues adopt a lock-free queue structure to reduce processing latency. The reduction in processing latency is achieved through flow control based on the token bucket algorithm to ensure that the processing latency of real-time messages is ≤5ms, 5ms < the processing latency of high-priority messages is ≤10ms, 10ms < the processing latency of ordinary messages is ≤15ms, and 15ms < the processing latency of low-priority messages is ≤20ms, while simultaneously preventing starvation of session messages of different priorities.

9. The distributed message dynamic response method based on WebSocket according to claim 8, characterized in that: The execution message processing logic also includes an intelligent message retry and compensation mechanism, which includes: Implement an exponential backoff retry strategy for failed session messages, by setting the initial retry interval to 50-100ms, doubling the retry interval each time, and retrying a maximum of 5 times or more. At the same time, a replay prevention mechanism based on a unique message ID is used to ensure the idempotency of message processing; If the message retry fails after reaching the maximum number of attempts, a compensation process is automatically triggered, routing the session message to a dedicated exception handling queue. The exception handling queue adopts a combination of dead letter queue and manual intervention to classify and store session messages that still fail to retry and then notify the operation and maintenance personnel.

Images