A full-duplex communication push method under cluster deployment

Abstract

The present invention provides a full-duplex communication push method under cluster deployment, which belongs to the field of data communication technology. The method comprises: according to the business layer in the client, using the business system to operate the Notebook instance, obtain instance status information, and call the service layer interface to judge the execution conditions of related tasks, and asynchronously execute the related tasks through the service layer; if the instance status changes, the instance status change is sent to ActiveMQ; cluster deployment of the business layer and addition of Redis middleware, in response to any business layer node consuming information, using the preset channel in Redis to publish information and notifying the remaining nodes in the business layer; in response to the business layer accepting the Redis message, calling the WebSocket sending interface to transmit the instance status change to the client; the present invention realizes real-time synchronization of the Notebook instance status.

Description

Technical Field

[0001] The present invention belongs to the field of data communication technology, and in particular relates to a full-duplex communication push method under cluster deployment. Background Art

[0002] Creating a Notebook instance at the service layer is a time-consuming operation due to the numerous steps involved, including image download, data volume creation, container creation, network configuration, user data configuration, and starting the Notebook service. Therefore, it is an asynchronous process. After successful creation, the service layer sends the database instance status to the messaging middleware ActiveMQ. The business layer consumer receives the status change, consumes the modified database instance status, and promptly pushes it to the client via WebSocket. However, WebSocket is a persistent connection, and through the nginx reverse proxy, only one client receives the message.

[0003] Currently, in the case of business layer cluster deployment, most existing technologies use a polling method to query the business layer for instance status changes through short HTTP connections. The disadvantage is that when there are many clients, regular polling increases the pressure on the business layer and causes delays.

[0004] The existing technology uses 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 single-node 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 of multi-node cluster deployment of the business layer, the client can receive the status changes of the Notebook instance; however, it has disadvantages. The time for scheduled polling is short, and multiple clients continuously request the server, resulting in excessive concurrency, which can easily lead to reduced performance of the overall service. 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 can cause some operations to be temporarily unavailable. Summary of the Invention

[0005] In response to 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 objectives, the technical solution adopted by the present invention is: a full-duplex communication push method under cluster deployment, comprising the following steps:

[0007] S1. Based on 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, determine 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 the 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 the business layer and add Redis middleware. When any business layer node consumes ActiveMQ information, it uses the NotebookRedisTopic channel in Redis to publish information and notify nodes other than those 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, completing the WebSocket push.

[0011] The beneficial effects of the present invention are as follows: based on WebSocket persistent connection, the present invention saves the time for 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 business layer multi-node cluster deployment solution, improves 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 includes the following steps:

[0013] Said S1 comprises the following steps:

[0014] S101. Based on 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 without being blocked and ensures timely transmission of messages by calling the asynchronous service layer interface to execute the response operation;

[0017] Furthermore, the S3 includes 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 the nodes consuming active message queue information.

[0019] S302: Utilize 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, which solves the consumption notification of the business layer in cluster mode and realizes the 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 call; adopts Redis's subscription and publishing mode to realize consumption notification in the cluster mode of the business layer. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 Flow chart of the method of the present invention.

[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 how the business layer in this embodiment subscribes to Redis and notifies the client of status changes. DETAILED DESCRIPTION

[0026] The specific embodiments of the present invention are described below to facilitate understanding of the present invention by those skilled in the art. However, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the appended claims, these changes are obvious, and all inventions and creations utilizing the concepts 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 for 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. Based on 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, determine the execution conditions of related tasks, and execute related tasks asynchronously through the service layer in the client. The specific steps are as follows:

[0037] S101. Based on 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 Notebook instance status information. The business system then calls the asynchronous service layer interface to perform the response operation. After the asynchronous interface call is successful, an asynchronous thread is created to execute the relevant 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 of the 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. 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 is sent to ActiveMQ.

[0043] S3. Cluster 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 the nodes consuming 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 the nodes consuming active message queue information.

[0045] S302: Utilize 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 of each business layer in the client is performed to generate Figure 4 In the cluster deployment structure shown, 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 that consumes it is unpredictable. Therefore, nodes other than the node that consumes ActiveMQ information cannot perceive changes in the Notebook instance status; 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 nodes that consume active message queue information. In response to the publish-subscribe function of Redis, all business layer nodes can perceive changes in the Notebook instance status, and all business layer nodes receive Redis messages by subscribing to 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, completing the WebSocket push.

[0048] In this embodiment, Figure 5 As shown in the figure, the business layer subscribes to Redis to notify the client of status changes. In response to receiving the Redis message, the business layer writes the Notebook instance status change to the database and calls the WebSocket sending interface to send the database containing the Notebook instance status change to the client in real time, completing the WebSocket push.

Claims

1. A full-duplex communication push method under cluster deployment, characterized in that: The following steps are involved: S1. Based on 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, determine 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 the 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 the business layer and add Redis middleware. When any business layer node consumes ActiveMQ information, it uses the NotebookRedisTopic channel in Redis to publish information and notify nodes other than those 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, completing the WebSocket push.

2. The full-duplex communication push method under cluster deployment according to claim 1, characterized in that: Said S1 comprises the following steps: S101. Based on 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 includes 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 the nodes consuming active message queue information. S302: Utilize 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.

Images