Disaster recovery method for coping with large-scale long connection and disconnection based on monitoring component
By using monitoring components and distributed algorithms to detect disconnect events on the long-connection server, using redis and zookeeper architectures for data persistence, the connection disconnection problem caused by burst network exceptions is solved, and normal recovery of business processes and data is achieved. The correct implementation.
Patent Information
- Application Number
- CN202411502794.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-25
- Publication Date
- 2025-01-03
AI Technical Summary
In the event of a burst network exception or a container service crash, the existing technology cannot effectively monitor the disconnection of the long connection, resulting in the failure to trigger the disconnection logic, the service is stopped and the data cannot be recovered.
Using a listening component-based method, data persistence is carried out through Redis, tcp connection monitoring is established, and disconnection events are detected using zookeeper architecture and distributed algorithms (such as raft, Paxos, ZAB) to ensure business data calculation and persistence.
The business process continues normally after service downtime, avoids data loss, increases the reliability and accuracy of connection disconnection detection, and ensures orderly processing of large-scale connection disconnection and disaster recovery data recovery.
Smart Images
Figure CN119254865A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of remote service technology, and in particular to a disaster recovery method for coping with large-scale long connection disconnections based on a monitoring component. Background Art
[0002] In RayLink's remote control, the server uses Netty to implement network communication and maintain a large number of websocket long connections. When the connection is closed, the corresponding event triggers the normal disconnection logic to ensure the normal calculation and persistent storage of business data. However, under force majeure factors such as sudden network anomalies and sudden crash of container services, a large number of connections will be directly disconnected, and the service will be directly avalanched and stopped. At this time, the event cannot be triggered, and there is no service to execute the normal disconnection logic. Even if the service is restarted later, the data cannot be restored to normal.
[0003] Therefore, the prior art has defects and needs to be improved. Summary of the invention
[0004] The technical problem to be solved by the present invention is: to provide a disaster recovery method based on a monitoring component to cope with large-scale long connection disconnections, monitor the connection disconnections at the network level through technical means, and store the corresponding data externally, and take over the normal calculation and persistence of the original data after the monitoring disconnection event.
[0005] The technical solution of the present invention is as follows: a disaster recovery method for coping with large-scale long connection disconnection based on a monitoring component is provided, comprising the following steps.
[0006] S1: At the entrance of the persistent connection server, the handshake event is processed. After the handshake between the client and the persistent connection server is successful, redis is used to persist the connection-related data and record the current data state.
[0007] S2: Build the corresponding monitoring component and open the corresponding monitoring port. Every time a connection is successfully established between the persistent server and the client, the persistent server and the monitoring component also establish a corresponding TCP connection. This creates a monitoring connection relationship. When the service crashes and the network connection is disconnected, the monitoring component can sense it.
[0008] S3: Redis persistence of the listening component connection, that is, associating the long connection server-client connection data state of step S1 with the corresponding long connection server-listening component relationship for subsequent mapping.
[0009] S4: The listening component sets up callback rules, that is, the processing of the original disconnection logic, and processes the event when it senses that the connection is disconnected.
[0010] S5: The listening component detects a disconnection event and triggers a judgment. The cluster algorithm determines whether it is a disconnection. If it is a disconnection, the disconnection service callback is triggered, and the server-client connection information of the current event server-listening component connection mapping in redis is read to obtain the corresponding business data and perform business data calculation. If it is not a disconnection, the long connection server-client is reconnected.
[0011] Furthermore, in step S5, the business data calculation includes: returning the number of connections, marking the connection disconnection, persisting the results into the business data in MySQL, and completing the normal disconnection logic operation.
[0012] Furthermore, the monitoring component adopts a distributed component, and its single responsibility is only to monitor the connection disconnection and disconnection processing. A distributed algorithm is adopted internally to vote to decide whether to actually disconnect, so as to avoid the server-component connection being accidentally disconnected due to network problems, and misjudge the server-client disconnection situation, thereby increasing reliability and accuracy.
[0013] Furthermore, the monitoring component adopts the zookeeper architecture.
[0014] Furthermore, the connection between the client and the persistent connection server is a websocket persistent connection.
[0015] Furthermore, the distributed algorithm is one of: raft algorithm, Paxos algorithm, ZAB algorithm, and Gossip algorithm.
[0016] By adopting the above scheme, the present invention provides a disaster recovery method for coping with large-scale long connection disconnection based on a monitoring component, which has the following technical effects:
[0017] 1. By adopting the TCP connection monitoring component of the Zookeeper architecture, it is ensured that the business process continues normally after the service goes down and lands in the database correctly.
[0018] 2. Compared with the original scenario, the connection status is persisted to redis in advance, which avoids the situation where the service stops, data is lost, and the system cannot continue to run after the connection is disconnected.
[0019] 3. Distributed monitoring components are used to increase reliability and reduce the possibility of misjudgment of disconnections, so that large-scale batch disconnections can be handled in an orderly manner and disaster recovery data can be restored. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] Figure 1 It is a schematic diagram of the process of the present invention. DETAILED DESCRIPTION
[0021] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments.
[0022] See also Figure 1 The present invention provides a disaster recovery method for coping with large-scale long connection disconnection based on a monitoring component, comprising the following steps.
[0023] S1: At the entrance of the persistent connection server, the handshake event is processed. After the handshake between the client and the persistent connection server is successful, redis is used to persist the connection-related data and record the current data state.
[0024] S2: Build the corresponding monitoring component and open the corresponding monitoring port. Every time a connection is successfully established between the persistent server and the client, the persistent server and the monitoring component also establish a corresponding TCP connection. This creates a monitoring connection relationship. When the service crashes and the network connection is disconnected, the monitoring component can sense it.
[0025] S3: Redis persistence of the listening component connection, that is, associating the long connection server-client connection data state of step S1 with the corresponding long connection server-listening component relationship for subsequent mapping.
[0026] S4: The listening component sets up callback rules, that is, the processing of the original disconnection logic, and processes the event when it senses that the connection is disconnected.
[0027] S5: The listening component detects a disconnection event and triggers a judgment. The cluster algorithm determines whether it is a disconnection. If it is a disconnection, the disconnection service callback is triggered, and the server-client connection information of the current event server-listening component connection mapping in redis is read to obtain the corresponding business data and perform business data calculation. If it is not a disconnection, the long connection server-client is reconnected.
[0028] In this embodiment, in step S5, the business data calculation includes: returning the number of connections, marking the connection disconnection, persisting the result into the business data in MySQL, and completing the normal disconnection logic operation.
[0029] In this embodiment, the monitoring component adopts a distributed component and has a single responsibility of only monitoring the connection disconnection and disconnection processing. A distributed algorithm is internally adopted to vote to decide whether to actually disconnect, so as to avoid the server-component connection being accidentally disconnected due to network problems, thereby misjudging the server-client disconnection situation, thereby increasing reliability and accuracy.
[0030] In this embodiment, the monitoring component adopts the zookeeper architecture.
[0031] In this embodiment, the connection between the client and the persistent connection server is a websocket persistent connection.
[0032] In this embodiment, the distributed algorithm is one of the following: raft algorithm, Paxos algorithm, ZAB algorithm, and Gossip algorithm.
[0033] In summary, the present invention provides a disaster recovery method for coping with large-scale long connection disconnection based on a monitoring component, which has the following technical effects:
[0034] 1. By adopting the TCP connection monitoring component of the Zookeeper architecture, it is ensured that the business process continues normally after the service goes down and lands in the database correctly.
[0035] 2. Compared with the original scenario, the connection status is persisted to redis in advance, which avoids the situation where the service stops, data is lost, and the system cannot continue to run after the connection is disconnected.
[0036] 3. Distributed monitoring components are used to increase reliability and reduce the possibility of misjudgment of disconnections, so that large-scale batch disconnections can be handled in an orderly manner and disaster recovery data can be restored.
[0037] The above are only preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.
Claims
1. A disaster recovery method for coping with large-scale long connection disconnection based on a monitoring component, characterized in that: The following steps are involved: S1: At the entrance of the persistent connection server, the handshake event is processed. After the handshake between the client and the persistent connection server is successful, redis is used to persist the connection-related data and record the current data state. S2: Build the corresponding monitoring component and open the corresponding monitoring port. Every time a connection is successfully established between the persistent connection server and the client, the persistent connection server and the monitoring component also establish a corresponding TCP connection. This creates a monitoring connection relationship. When the service fails and the network connection is disconnected, the monitoring component can sense it. S3: Redis persistence of the listening component connection, that is, associating the persistent connection server-client connection data state of step S1 with the corresponding persistent connection server-listening component relationship for subsequent mapping; S4: The monitoring component sets up callback rules, that is, the processing of the original disconnection logic, and processes the event when it senses that the connection is disconnected; S5: The monitoring component detects a disconnection event, triggers a judgment, and the cluster algorithm determines whether it is a disconnection; If the connection is disconnected, the callback disconnection service is triggered, the server-client connection information of the current event server-listener component connection mapping in redis is read, the corresponding business data is obtained, and the business data is calculated; If it is not disconnected, the long connection server-client reconnects.
2. According to claim 1, a method for disaster recovery based on a monitoring component to cope with large-scale long connection disconnection is characterized in that: In step S5, the business data calculation includes: returning the number of connections, marking the connection disconnection, persisting the results into the business data in MySQL, and completing the normal disconnection logic operation.
3. According to claim 1, a method for disaster recovery based on a monitoring component to cope with large-scale long connection disconnection is characterized in that: The monitoring component adopts a distributed component, and its single responsibility is only to monitor the connection disconnection and disconnection processing. In addition, a distributed algorithm is adopted internally to vote to decide whether the connection is actually disconnected, so as to avoid the server-component connection being accidentally disconnected due to network problems, and misjudging the server-client disconnection situation, thereby increasing reliability and accuracy.
4. According to claim 1, a method for disaster recovery based on a monitoring component to cope with large-scale long connection disconnection is characterized in that: The monitoring component adopts the zookeeper architecture.
5. According to claim 1, a method for disaster recovery based on a monitoring component to cope with large-scale long connection disconnection is characterized in that: The connection between the client and the persistent connection server is a websocket persistent connection.
6. According to claim 3, a method for disaster recovery based on a monitoring component to cope with large-scale long connection disconnection is characterized in that: The distributed algorithm is one of the following: raft algorithm, Paxos algorithm, ZAB algorithm, and Gossip algorithm.