Full-duplex communication pushing method under cluster deployment
By adopting full-duplex communication push method and Redis middleware in service layer cluster deployment, real-time synchronization of Notebook instance status is achieved, performance reduction and real-time delay problems caused by rotation training methods in the prior art are solved, and system reliability and user experience are improved.
Patent Information
- Application Number
- CN202510243230.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-03
- Publication Date
- 2025-05-13
- Estimated Expiration
- 2045-03-03
AI Technical Summary
In the case of service-level cluster deployment, the prior art adopts rotation training to perform state query, resulting in many clients and high concurrency, resulting in reduced server performance, and the inability to realize real-time synchronization of Notebook instance status.
The full-duplex communication push method is adopted to actively push messages through long connections of WebSocket, and combined with Redis middleware to achieve state synchronization in the multi-node cluster deployment of the service layer, avoiding HTTP rotation training and reducing the performance pressure on the server side.
Real-time synchronization of Notebook instance status is realized, the reliability and accuracy of the business layer is improved, the user experience is enhanced, and the performance pressure on the server side is reduced.
Smart Images

Figure CN119996507A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of data communication, and in particular relates to a full-duplex communication push method under cluster deployment. Background Art
[0002] The creation of a Notebook instance based on the service layer is a time-consuming operation because it involves many steps, including image download, data volume creation, container creation, network configuration, user data configuration, and starting the Notebook service. Therefore, it is an asynchronous operation process. After successful creation, the service layer sends the status of the database instance to the message middleware ActiveMQ. The business layer consumer receives the status change, consumes and modifies the status of the database instance and pushes it to the client through WebSocket in a timely manner. However, WebSocket is a long connection. After the reverse proxy of nginx, only one client receives the message.
[0003] At present, in the case of cluster deployment at the business layer, most existing technologies use a polling method to request the business layer to inquire about the status changes of instances through short HTTP connections. The disadvantage is that when there are many clients, the scheduled polling increases the pressure on the business layer and there is a delay.
[0004] The existing technology adopts a polling method and a separate WebSocket method. Only the node server that consumes ActiveMQ messages can perceive the status changes of the database instance and push them to the client connected to the node. The other clients cannot perceive the status changes of the database instance in time. Therefore, the above solution is only suitable for the single-machine deployment of the business layer, and cannot solve the high availability and load balancing of the business layer. Although the polling method solves the problem that the client can receive the status changes of the Notebook instance in the case of multi-node cluster deployment of the business layer, it has disadvantages. The time for scheduled polling is short, and multiple clients continuously request the server, resulting in excessive concurrency, which easily leads to the reduction of the overall service performance; the time for scheduled polling is long, resulting in a delay in the real-time status of the Notebook instance, a poor user experience, and the non-real-time nature of the instance status will cause some operations to be temporarily unavailable. Summary of the invention
[0005] In view of the above-mentioned deficiencies in the prior art, the present invention provides a full-duplex communication push method under cluster deployment, which solves the problem of real-time synchronization of Notebook instance status.
[0006] In order to achieve the above purpose, the technical solution adopted by the present invention is: a full-duplex communication push method under cluster deployment, comprising the following steps:
[0007] S1. According to the business layer in the client, use the business system to operate the Notebook instance, obtain the Notebook instance status information, call the service layer interface, judge the execution conditions of related tasks, and asynchronously execute related tasks through the service layer in the client;
[0008] S2. In response to the completion of the asynchronous execution of related tasks, determine whether the status of the Notebook instance has changed. If not, end the push and return to S1. If so, send the Notebook instance status change to ActiveMQ and enter S3.
[0009] S3. Cluster deployment of the business layer and adding Redis middleware. In response to any business layer node consuming ActiveMQ information, use the NotebookRedisTopic channel in Redis to publish information and notify nodes other than nodes consuming active message queue information to receive Redis messages.
[0010] S4. In response to the business layer receiving the Redis message, the Notebook instance status change is written to the database, and the WebSocket sending interface is called to send the database to the client to complete the WebSocket push.
[0011] The beneficial effects of the present invention are as follows: the present invention is based on WebSocket long connection, which saves the time of disconnecting and reconnecting three-way handshake, realizes full-duplex communication in which the business layer server can actively push messages to the client, and avoids the slow start of the transmission control protocol; and by adding Redis middleware and combining the solution of multi-node cluster deployment of the business layer, the reliability and accuracy of the business layer, as well as the timeliness of messages, enhances the user experience, abandons the HTTP polling method, reduces the performance pressure on the server side, improves the timeliness of messages, and realizes real-time synchronization of Notebook instance status.
[0012] Furthermore, the S1 comprises the following steps:
[0013] The S1 comprises the following steps:
[0014] S101, according to the business layer in the client, use the business system to operate the Notebook instance to obtain the Notebook instance status information;
[0015] S102. Use the business system to call the asynchronous service layer interface to execute the response operation and determine whether the execution conditions are met. If not, output the operation failure information and return to S101. If so, output the operation success information and asynchronously execute related tasks through the service layer in the client.
[0016] The beneficial effects of the above further solution are: the present invention implements the service layer interface is not blocked and ensures the timely transmission of messages by calling the asynchronous service layer interface to execute the response operation;
[0017] Furthermore, the S3 comprises the following steps:
[0018] S301. Use nginx reverse proxy technology to cluster the business layer and add Redis middleware. In response to any business layer node consuming ActiveMQ information, publish the information to the NotebookRedisTopic channel in Redis, and use Redis's publish-subscribe function to notify nodes in the business layer except for nodes that consume active message queue information.
[0019] S302: Use all nodes in the business layer to perceive changes in the status of the Notebook instance and receive Redis messages by subscribing to the NotebookRedisTopic channel.
[0020] The beneficial effects of the above further scheme are as follows: the present invention achieves state synchronization by clustering the business layer and introduces Redis middleware, thereby solving the consumption notification of the business layer in cluster mode and realizing real-time push of the changes in the status of the Notebook instance to all clients in the case of multiple copies of the cluster; adopts nginx reverse proxy technology to prevent the overall client service from being affected by the failure of some business layers, thereby improving the availability of business layer services; adopts ActiveMQ message notification to realize the notification of the execution result of asynchronous interface calls; adopts the subscription and publishing mode of Redis to realize consumption notification in the cluster mode of the business layer. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Figure 1 The present invention is a flow chart of the method.
[0022] Figure 2 This is a flowchart of the business layer calling the service layer in this embodiment.
[0023] Figure 3 This is a flowchart of the service layer pushing status notification to the business layer in this embodiment.
[0024] Figure 4 This is a structural diagram of the business layer cluster deployment in this embodiment.
[0025] Figure 5 This is a flowchart of the business layer subscribing to Redis to notify the client of status changes in this embodiment. DETAILED DESCRIPTION
[0026] The specific implementation modes of the present invention are described below so that those skilled in the art can understand the present invention. However, it should be clear that the present invention is not limited to the scope of the specific implementation modes. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the attached claims, these changes are obvious, and all inventions and creations utilizing the concept of the present invention are protected.
[0027] Before describing the present invention, the following terms are explained:
[0028] Notebook instance: An interactive programming environment commonly used in data science, machine learning, and AI development;
[0029] WebSocket: A protocol for full-duplex communication over a single TCP connection;
[0030] nginx - a high-performance HTTP and reverse proxy web server;
[0031] Redis - high-performance key-value database.
[0032] NotebookRedisTopic: channel name in Redis publish-subscribe mode;
[0033] ActiveMQ: A high-performance, scalable messaging middleware that provides a reliable messaging mechanism suitable for distributed systems that require efficient and reliable message communication.
[0034] Example
[0035] like Figure 1 As shown, the present invention provides a full-duplex communication protocol push method under cluster deployment, and its implementation method is as follows:
[0036] S1. According to the business layer in the client, use the business system to operate the Notebook instance, obtain the Notebook instance status information, call the service layer interface, judge the execution conditions of related tasks, and asynchronously execute related tasks through the service layer in the client. The specific steps are as follows:
[0037] S101, according to the business layer in the client, use the business system to operate the Notebook instance to obtain the Notebook instance status information;
[0038] S102. Use the business system to call the asynchronous service layer interface to execute the response operation and determine whether the execution conditions are met. If not, output the operation failure information and return to S101. If so, output the operation success information and asynchronously execute related tasks through the service layer in the client.
[0039] In this embodiment, Figure 2 As shown in the figure, according to the business layer in the client, the business system is used to operate the Notebook instance, such as creating, starting, stopping and deleting, to obtain the status information of the Notebook instance, and the business system is used to call the asynchronous service layer interface to perform the response operation. After the asynchronous interface call is successful, an asynchronous thread is created to perform related operations of the Notebook instance to ensure that the asynchronous interface is not blocked;
[0040] And determine whether the execution conditions are met. If not, output the operation failure information and call the business layer again to operate the Notebook instance. If so, output the operation success information and asynchronously execute related tasks through the service layer in the client.
[0041] S2. In response to the completion of the asynchronous execution related tasks, determine whether the status of the Notebook instance has changed. If not, end the push and return to S1. If so, send the Notebook instance status change to ActiveMQ and enter S3.
[0042] In this embodiment, Figure 3 As shown, the service layer pushes the status notification to the business layer, and in response to the completion of the asynchronous execution of related tasks, it is determined whether the status of the Notebook instance has changed. If not, the push is terminated. If so, the status change of the Notebook instance status is sent to ActiveMQ.
[0043] S3. Cluster deployment of the business layer and add Redis middleware. In response to any business layer node consuming ActiveMQ information, use the NotebookRedisTopic channel in Redis to publish information and notify nodes other than nodes that consume active message queue information to receive Redis messages. The specific steps are as follows:
[0044] S301. Use nginx reverse proxy technology to cluster the business layer and add Redis middleware. In response to any business layer node consuming ActiveMQ information, publish the information to the NotebookRedisTopic channel in Redis, and use Redis's publish-subscribe function to notify nodes in the business layer except for nodes that consume active message queue information.
[0045] S302: Use all nodes in the business layer to perceive changes in the status of the Notebook instance and receive Redis messages by subscribing to the NotebookRedisTopic channel.
[0046] In this embodiment, Figure 3As shown, using nginx reverse proxy technology, cluster deployment is performed on each business layer in the client to generate Figure 4 In the cluster deployment structure shown in the figure, when a business layer fails or stops running, the nginx reverse proxy technology is used to prevent the situation from affecting the normal functional use of the client's overall service, thereby ensuring the high availability of the business layer service. A message in ActiveMQ can only be consumed by one node, and the specific node for consumption is unpredictable. Therefore, nodes other than the node that consumes the ActiveMQ information cannot perceive the change in the status of the Notebook instance. In response to any business layer node consuming ActiveMQ information, the information is published to the NotebookRedisTopic channel in Redis, and the publish-subscribe function of Redis is used to notify the remaining nodes in the business layer except the node that consumes the active message queue information. In response to the use of the publish-subscribe function of Redis, all business layer nodes can perceive the change in the status of the Notebook instance, and all business layer nodes receive the Redis message by subscribing to the notebookRedisTopic.
[0047] S4. In response to the business layer receiving the Redis message, the Notebook instance status change is written to the database, and the WebSocket sending interface is called to send the database to the client to complete the WebSocket push.
[0048] In this embodiment, Figure 5 As shown, the business layer subscribes to Redis to notify the client of the status change. In response to the business layer receiving the Redis message, the Notebook instance status change is written to the database, and the WebSocket sending interface is called to send the database containing the Notebook instance status change to the client in real time to complete the WebSocket push.
Claims
1. A full-duplex communication push method under cluster deployment, characterized in that: The following steps are involved: S1. According to the business layer in the client, use the business system to operate the Notebook instance, obtain the Notebook instance status information, call the service layer interface, judge the execution conditions of related tasks, and asynchronously execute related tasks through the service layer in the client; S2. In response to the completion of the asynchronous execution of related tasks, determine whether the status of the Notebook instance has changed. If not, end the push and return to S1. If so, send the Notebook instance status change to ActiveMQ and enter S3. S3. Cluster deployment of the business layer and adding Redis middleware. In response to any business layer node consuming ActiveMQ information, use the NotebookRedisTopic channel in Redis to publish information and notify nodes other than nodes consuming active message queue information to receive Redis messages. S4. In response to the business layer receiving the Redis message, the Notebook instance status change is written to the database, and the WebSocket sending interface is called to send the database to the client to complete the WebSocket push.
2. The full-duplex communication push method under cluster deployment according to claim 1, characterized in that: The S1 comprises the following steps: S101, according to the business layer in the client, use the business system to operate the Notebook instance to obtain the Notebook instance status information; S102. Use the business system to call the asynchronous service layer interface to execute the response operation and determine whether the execution conditions are met. If not, output the operation failure information and return to S101. If so, output the operation success information and asynchronously execute related tasks through the service layer in the client.
3. The full-duplex communication push method under cluster deployment according to claim 1, characterized in that: The S3 comprises the following steps: S301. Use nginx reverse proxy technology to cluster the business layer and add Redis middleware. In response to any business layer node consuming ActiveMQ information, publish the information to the NotebookRedisTopic channel in Redis, and use Redis's publish-subscribe function to notify nodes in the business layer except for nodes that consume active message queue information. S302: Use all nodes in the business layer to perceive changes in the status of the Notebook instance and receive Redis messages by subscribing to the NotebookRedisTopic channel.
Citation Information
Patent Citations
Distributed server cluster interaction method and device based on WebSocket
CN111031058A
Message pushing method and device, equipment and storage medium
CN113452774A
Data visualization method and device, computer system and readable storage medium
CN113760252A
Distributed training system based on containerization and construction method thereof
CN115344356A
Real-time communication method, proxy device, client and server
CN117395217A