CN116260707A - Block chain node disaster recovery method, device and equipment based on consensus and storage medium - Google Patents
Block chain node disaster recovery method, device and equipment based on consensus and storage medium Download PDFInfo
- Publication number
- CN116260707A CN116260707A CN202310542193.2A CN202310542193A CN116260707A CN 116260707 A CN116260707 A CN 116260707A CN 202310542193 A CN202310542193 A CN 202310542193A CN 116260707 A CN116260707 A CN 116260707A
- Authority
- CN
- China
- Prior art keywords
- node
- important
- target
- standby
- nodes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
- Y02A10/00—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE at coastal zones; at river basins
- Y02A10/40—Controlling or monitoring, e.g. of flood or hurricane; Forecasting, e.g. risk assessment or mapping
Abstract
The invention relates to the technical field of blockchains and discloses a method, a device, equipment and a storage medium for disaster recovery of blockchain nodes based on consensus, wherein the method comprises the following steps: when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node; selecting standby important nodes according to the node rotation request through a preset consensus strategy; if the standby important node is detected to execute the target correct operation in the preset time, the target important node is rotated to be the standby important node; according to the method, when the target important node needs to be switched, the standby important node is selected by using the preset consensus strategy, whether the target correct operation is executed by the standby important node in the preset time is judged, if yes, the standby important node is switched, the online service quality is continuously ensured by the standby important node, and therefore the stability, the decentralization characteristic and the disaster recovery capability of the blockchain system can be effectively improved.
Description
Technical Field
The present invention relates to the field of blockchain technologies, and in particular, to a blockchain node disaster recovery method, device, equipment and storage medium based on consensus.
Background
The important node in the existing blockchain has extremely high effect on the blockchain operation, for example, the execution of a service needs to be confirmed by the important node, meanwhile, the important node still needs to ensure the online service quality of the node in a disaster recovery mode, for example, when accidents (such as downtime and disconnection, etc.) occur on the important node or nodes similar to a main maintenance chain in a master-slave chain, the standby node is needed to replace the original important node to continue to execute, the related technology of the disaster recovery node is the self-selection of the mechanism to which the important node belongs, but when the important node is down, the standby node can cause the situation that multiple important nodes or the nodes cannot be connected with other important nodes, and finally, the defects of poor stability, decentralization characteristic and disaster recovery capability of a blockchain system occur in the disaster recovery node.
The foregoing is provided merely for the purpose of facilitating understanding of the technical solutions of the present invention and is not intended to represent an admission that the foregoing is prior art.
Disclosure of Invention
The invention mainly aims to provide a block chain node disaster recovery method, device, equipment and storage medium based on consensus, which aim to solve the technical problems of poor system stability, decentralization characteristic and disaster recovery capability caused by disaster recovery of block chain nodes in the prior art.
In order to achieve the above object, the present invention provides a block chain node disaster recovery method based on consensus, which includes the following steps:
when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node;
selecting standby important nodes according to the node rotation request through a preset consensus strategy;
and if the standby important node is detected to execute the target correct operation in the preset time, the target important node is rotated to be the standby important node.
Optionally, when the quality of service value of the target important node is smaller than the preset quality of service threshold, sending, by the target node, a node rotation request to other important nodes, including:
detecting the target important node through a standby node to obtain the current online time length and the service processing speed;
calculating the service quality value of the target important node according to the current online time length and the service processing speed;
and when the service quality value of the target important node is smaller than a preset service quality threshold value, sending a node rotation request to other important nodes through the target node.
Optionally, the selecting the standby important node according to the node rotation request through a preset consensus strategy includes:
judging whether the selected information which is not transmitted by a certain important node or other important nodes according to the node rotation request can not be received within a set time;
if not, acquiring the voted quantity of any node in the selected nodes through a preset consensus strategy;
when the voted number of any node is larger than a preset voting number threshold value, performing winning broadcast to other nodes in the participating nodes;
and when the selection information of the nodes larger than the voted number is not received in the target time, taking any node as a standby important node.
Optionally, when the voted number of any node is greater than a preset voting number threshold, after performing the broadcast to other nodes in the participating nodes, the method further includes:
when the selection information of the nodes with the number larger than the voted number is received in the target time, the types of the nodes are acquired;
when the type of the node is a voting type, taking any node as a standby important node;
when the type of the node is a reference type, the current voting number is obtained according to the selection information of the node;
and comparing the current voting number with the voted number of any node, and determining a standby important node according to the voting number comparison result.
Optionally, if the standby important node is detected to execute the target correct operation within the preset time, the step of rotating the target important node to be the standby important node includes:
when the standby important node normally operates, detecting whether the standby important node executes target correct operation in preset time;
if yes, the target important node is rotated to be a standby important node.
Optionally, after the target important node is rotated to the standby important node if the target important node is the standby important node, the method further includes:
monitoring all nodes in the block chain to obtain a current node monitoring result;
when abnormal information exists in the current node monitoring result, determining the node with the abnormality;
removing the abnormal nodes to obtain target reference nodes;
and executing the election of the standby important node again according to the target participating node.
Optionally, when the standby important node operates normally, detecting whether the standby important node performs the target correct operation within a preset time, and then further includes:
if not, the standby important node is removed from the selected nodes.
In addition, in order to achieve the above object, the present invention further provides a blockchain node disaster recovery device based on consensus, where the blockchain node disaster recovery device based on consensus includes:
the sending module is used for sending node rotation requests to other important nodes through the target node when the service quality value of the target important node is smaller than a preset service quality threshold value;
the election module is used for electing standby important nodes according to the node rotation request through a preset consensus strategy;
and the detection module is used for taking the standby important node as a node for guaranteeing the online service quality in the block chain if the standby important node is detected to execute the target correct operation in the preset time.
In addition, in order to achieve the above object, the present invention further provides a blockchain node disaster recovery device based on a consensus, where the blockchain node disaster recovery device based on the consensus includes: the system comprises a memory, a processor, and a consensus-based blockchain node disaster recovery program stored on the memory and executable on the processor, the consensus-based blockchain node disaster recovery program configured to implement the consensus-based blockchain node disaster recovery method as described above.
In addition, in order to achieve the above objective, the present invention further provides a storage medium, where a blockchain node disaster recovery program based on a consensus is stored on the storage medium, where the blockchain node disaster recovery program based on the consensus implements the blockchain node disaster recovery method based on the consensus as described above when executed by a processor.
According to the block chain node disaster recovery method based on consensus, when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node; selecting standby important nodes according to the node rotation request through a preset consensus strategy; if the standby important node is detected to execute the target correct operation in the preset time, the target important node is rotated to be the standby important node; according to the method, when the target important node needs to be switched, the standby important node is selected by using the preset consensus strategy, whether the target correct operation is executed by the standby important node in the preset time is judged, if yes, the standby important node is switched, the online service quality is continuously ensured by the standby important node, and therefore the stability, the decentralization characteristic and the disaster recovery capability of the blockchain system can be effectively improved.
Drawings
FIG. 1 is a schematic diagram of a block chain node disaster recovery device based on a consensus of a hardware operating environment according to an embodiment of the present invention;
FIG. 2 is a schematic flow chart of a first embodiment of a disaster recovery method for blockchain nodes based on consensus in accordance with the present invention;
FIG. 3 is a flowchart illustrating a second embodiment of a method for disaster recovery for blockchain nodes based on consensus in accordance with the present invention;
FIG. 4 is a schematic diagram illustrating an internal election rotation of an embodiment of a method for disaster recovery for blockchain nodes based on consensus in accordance with the present invention;
FIG. 5 is a schematic diagram illustrating significant node consensus and rotation of an embodiment of a method for disaster recovery for blockchain nodes according to the present disclosure;
FIG. 6 is a schematic diagram of functional modules of a first embodiment of a device for disaster recovery for blockchain nodes based on consensus.
The achievement of the objects, functional features and advantages of the present invention will be further described with reference to the accompanying drawings, in conjunction with the embodiments.
Detailed Description
It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
Referring to fig. 1, fig. 1 is a schematic diagram of a block chain node disaster recovery device based on consensus in a hardware operating environment according to an embodiment of the present invention.
As shown in fig. 1, the block chain node disaster recovery device based on consensus may include: a processor 1001, such as a central processing unit (Central Processing Unit, CPU), a communication bus 1002, a user interface 1003, a network interface 1004, a memory 1005. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display, an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a Wireless interface (e.g., a Wireless-Fidelity (Wi-Fi) interface). The Memory 1005 may be a high-speed random access Memory (Random Access Memory, RAM) Memory or a stable nonvolatile Memory (NVM), such as a disk Memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above.
Those skilled in the art will appreciate that the architecture shown in fig. 1 is not limiting of a common-knowledge-based blockchain node disaster recovery device, and may include more or fewer components than shown, or may combine certain components, or may be a different arrangement of components.
As shown in fig. 1, an operating system, a network communication module, a user interface module, and a blockchain node disaster recovery procedure based on consensus may be included in the memory 1005 as one storage medium.
In the blockchain node disaster recovery device based on consensus shown in fig. 1, the network interface 1004 is mainly used for performing data communication with a network integration platform workstation; the user interface 1003 is mainly used for data interaction with a user; the processor 1001 and the memory 1005 in the block chain node disaster recovery equipment based on the consensus can be arranged in the block chain node disaster recovery equipment based on the consensus, and the block chain node disaster recovery equipment based on the consensus calls the block chain node disaster recovery program based on the consensus stored in the memory 1005 through the processor 1001 and executes the block chain node disaster recovery method based on the consensus.
Based on the hardware structure, the embodiment of the block chain node disaster recovery method based on consensus is provided.
Referring to fig. 2, fig. 2 is a flowchart illustrating a first embodiment of a block chain node disaster recovery method based on consensus according to the present invention.
In a first embodiment, the block chain node disaster recovery method based on consensus comprises the following steps:
and step S10, when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node.
It should be noted that, the execution body of the embodiment is a block chain node disaster recovery device based on a common knowledge, and may be other devices that can implement the same or similar functions, for example, a node disaster recovery controller, etc., which is not limited in this embodiment, and in this embodiment, the node disaster recovery controller is taken as an example for explanation.
It should be understood that, the service quality value refers to a quality score value of service performed by the target important node, the higher the score is, the better the service quality of the target important node is indicated, otherwise, the worse the service quality of the target important node is indicated, after the service quality value of the target important node is obtained, whether the service quality value of the target important node is smaller than a preset service quality threshold value is judged, if yes, the service capability of the target important node is indicated to be too bad or faulty, at this time, a node rotation request is sent to other important nodes through the target node, the target node may be a former important node or a selected node, the node rotation request refers to a request for notifying other important nodes to start node rotation, and under normal conditions, rotation of external communication nodes is performed by oneself in an organization to which the important node requiring disaster recovery belongs, and the target node and the target important node belong to the same class.
It can be understood that an organization to which an important node belongs communicates the important node and its disaster recovery node with other important nodes to complete initialization, the disaster recovery node which is not communicated by other important nodes cannot be elected in an important node consensus election module, during the operation of the important node, the disaster recovery node needs to monitor the important node, including sending heartbeat information to confirm whether the important node is operated, whether the processing information rate is reduced, etc., and the disaster recovery node and the important node should have almost the same service capability (including storage, calculation, etc.).
Step S20, selecting standby important nodes according to the node rotation request through a preset consensus strategy.
It is to be understood that the preset consensus strategy refers to a strategy that each important node commonly elects a specific node, the preset consensus strategy may be voting, the standby important node refers to a node for replacing a target important node, the standby important node is elected according to a node rotation request through the preset consensus strategy, and in addition, the standby important node may be an node which is elected in the interior represented by the target important node, rather than an node which elects an important node level.
Further, step S20 includes: judging whether the selected information which is not transmitted by a certain important node or other important nodes according to the node rotation request can not be received within a set time; if not, acquiring the voted quantity of any node in the selected nodes through a preset consensus strategy; when the voted number of any node is larger than a preset voting number threshold value, performing winning broadcast to other nodes in the participating nodes; and when the selection information of the nodes larger than the voted number is not received in the target time, taking any node as a standby important node.
It should be understood that the winning information refers to information that each node performs winning, where the winning information includes, but is not limited to, the number of votes, node ids, and the like, if it is determined that the winning information cannot be sent to a certain important node or received by other important nodes according to the node rotation request within a specified time, the number of votes of any node in the participating nodes is obtained through a preset consensus policy, for example, when the nodes meet the BFT assumption, the node participating in the election initiates a winning proposal first, then the node not participating in the current election counts the number of votes of itself to a certain participating node, and then continues to determine whether the number of votes of any node is greater than a preset voting number threshold, if yes, the any node starts to perform winning broadcast, if no winning information of a node greater than the number of votes is received within a target time, the node starts to send the winning information to other important nodes, and any node at this time is a standby important node.
Further, when the voted number of any node is greater than the preset voting number threshold, after performing the broadcast to other nodes in the participating nodes, the method further includes: when the selection information of the nodes with the number larger than the voted number is received in the target time, the types of the nodes are acquired; when the type of the node is a voting type, taking any node as a standby important node; when the type of the node is a reference type, the current voting number is obtained according to the selection information of the node; and comparing the current voting number with the voted number of any node, and determining a standby important node according to the voting number comparison result.
It can be understood that when the winning information of the node greater than the voted number is received in the target time, the type of the node greater than the voted number needs to be judged, when the type of the node is the voting type, the role of the node is only voting, the node does not participate in the voting, when the type of the node is the participation type, the id and the vote number of the node with the maximum vote number are recorded, when the type of the node is the participation type, the node needs to participate in the voting, the current voting number is compared with the voted number of any node, if the current voting number is greater than the voted number of any node, the node is taken as a standby important node, the id and the current voting number of the node are recorded, and the voting node is updated, otherwise, any node is taken as a standby important node, and the winning information of the node is discarded.
It should be appreciated that it is possible to know on the chain which node is elected, and other important nodes inform the node of the address of the voting intelligent contract, which node broadcasts it internally, and starts to perform the role of the important node.
When the message of the selected node is not received, the down important node is removed from the node set to be selected, then the standby important node of the fault node is selected, when one important node monitors that the target node is faulty, other important nodes are notified to confirm the authenticity, if the reply of the other important nodes can be received, the intelligent contract is used for starting the voting of the node to be selected, and if the reply of the other nodes is not received, whether the network or other reasons of the node need to be checked.
Step S30, if the standby important node is detected to execute the target correct operation in the preset time,
the target significant node is rotated to a standby significant node.
It should be understood that the target correct operation refers to an operation that needs to be performed by the important node to guarantee the online service quality, and when the standby important node is detected to perform the target correct operation within a preset time, the target important node is rotated to the standby important node.
Further, step S30 includes: when the standby important node normally operates, detecting whether the standby important node executes target correct operation in preset time; if yes, the target important node is rotated to be a standby important node.
It can be understood that before detecting whether the standby important node performs the target correct operation within the preset time, whether the standby important node operates normally needs to be monitored, if yes, the state of the node is monitored according to the communication of the node, so as to judge whether the standby important node performs the target correct operation within the preset time, and if yes, the target important node is rotated to be the standby important node.
Further, when the standby important node operates normally, detecting whether the standby important node performs the target correct operation within a preset time, and then further includes: if not, the standby important node is removed from the selected nodes.
It should be appreciated that when it is determined that the standby important node does not perform the target correct operation within the preset time, the objective of updating the reference node is achieved by removing the standby important node from the reference node.
Further, after step S30, the method further includes: monitoring all nodes in the block chain to obtain a current node monitoring result; when abnormal information exists in the current node monitoring result, determining the node with the abnormality; removing the abnormal nodes to obtain target reference nodes; and executing the election of the standby important node again according to the target participating node.
It should be understood that the current node monitoring result refers to a monitoring result of all nodes of the blockchain, when it is determined that abnormal information exists in the current node monitoring result, the abnormal node is determined at the moment, then the abnormal node is removed, and after the removal is completed, the standby important node is selected again according to a list formed by the target selected nodes.
In the embodiment, when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node; selecting standby important nodes according to the node rotation request through a preset consensus strategy; if the standby important node is detected to execute the target correct operation in the preset time, the target important node is rotated to be the standby important node; according to the method, when the target important node needs to be switched, the standby important node is selected by using the preset consensus strategy, whether the target correct operation is executed by the standby important node in the preset time is judged, if yes, the standby important node is switched, the online service quality is continuously ensured by the standby important node, and therefore the stability, the decentralization characteristic and the disaster recovery capability of the blockchain system can be effectively improved.
In an embodiment, as shown in fig. 3, a second embodiment of the blockchain node disaster recovery method based on consensus according to the present invention is provided based on the first embodiment, and the step S10 includes:
step S101, detecting the target important node through a standby node to obtain the current online time length and the service processing speed.
It should be understood that the current online time length refers to the online time length when the target important node performs service, and the service processing speed refers to the speed of the target important node for processing each service, and the current online time length and the service processing speed are both obtained through detection of the standby node.
Step S102, calculating the service quality value of the target important node according to the current online time length and the service processing speed.
It can be understood that the parameters for calculating the service quality value of the target important node include other parameters, such as downtime duration, disconnection duration, etc., besides the current online duration and service processing speed, and the embodiment is not limited thereto, and after the current online duration and service processing speed are obtained, the service quality value of the target important node is calculated by combining weights corresponding to the current online duration and service processing speed.
Step S103, when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node.
It should be understood that after the quality of service value of the target important node is obtained, it is determined whether the quality of service value of the target important node is smaller than a preset quality of service threshold, if yes, it indicates that the service capability of the target important node is too poor or fails, and at this time, a node rotation request is sent to other important nodes by the target node to notify the other important nodes that the node rotation needs to be started at this time.
It will be appreciated that, referring to fig. 4, fig. 4 is an internal election rotation schematic diagram, specifically: when the important node D1 fails, because some processes have to participate in the node D, the importance of the node D increases, and the stability of the node D has to be ensured, and at this time, the internal disaster-backup node selects the backup important node, that is, the backup important node, to replace the original important node D by voting.
It should be understood that, referring to fig. 5, fig. 5 is a schematic diagram of important node consensus and rotation, specifically: when the number of tickets of the disaster recovery nodes D1 and D2 is the same in the internal rotation, the disaster recovery nodes are either in a waiting state or send messages to the node A, B, C in a short time, if an important node A, B, C randomly selects one node, the network partition can be caused, at this time, important node consensus is adopted, an important node A, B, C commonly recognizes one disaster recovery node and notifies the disaster recovery node, if the selected node is D1, the node D1 sends the disaster recovery node to the node D2 after receiving the notification, so that the node D2 is ensured to know the current important node, namely the standby important node.
In the embodiment, the standby node detects the target important node to obtain the current online time length and the service processing speed; calculating the service quality value of the target important node according to the current online time length and the service processing speed; when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node; by the method, the service quality value of the target important node is calculated by using the detected current online time length and the service processing speed, whether the service quality value of the target important node is smaller than a preset service quality threshold value or not is judged, if yes, a node rotation request is sent to other important nodes through the target node, and therefore accuracy and fairness of important node rotation can be improved.
In addition, the embodiment of the invention also provides a storage medium, wherein the storage medium is stored with a block chain node disaster recovery program based on the consensus, and the block chain node disaster recovery program based on the consensus realizes the steps of the block chain node disaster recovery method based on the consensus when being executed by a processor.
Because the storage medium adopts all the technical schemes of all the embodiments, the storage medium has at least all the beneficial effects brought by the technical schemes of the embodiments, and the description is omitted here.
In addition, referring to fig. 6, the embodiment of the invention further provides a blockchain node disaster recovery device based on consensus, where the blockchain node disaster recovery device based on consensus includes:
and the sending module 10 is configured to send a node rotation request to other important nodes through the target node when the quality of service value of the target important node is less than the preset quality of service threshold.
And the election module 20 is used for electing the standby important nodes according to the node rotation request through a preset consensus strategy.
And the detection module 30 is configured to, if it is detected that the standby important node performs the target correct operation within the preset time, take the standby important node as a node for guaranteeing online service quality in the blockchain.
In the embodiment, when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node; selecting standby important nodes according to the node rotation request through a preset consensus strategy; if the standby important node is detected to execute the target correct operation in the preset time, the target important node is rotated to be the standby important node; according to the method, when the target important node needs to be switched, the standby important node is selected by using the preset consensus strategy, whether the target correct operation is executed by the standby important node in the preset time is judged, if yes, the standby important node is switched, the online service quality is continuously ensured by the standby important node, and therefore the stability, the decentralization characteristic and the disaster recovery capability of the blockchain system can be effectively improved.
It should be noted that the above-described working procedure is merely illustrative, and does not limit the scope of the present invention, and in practical application, a person skilled in the art may select part or all of them according to actual needs to achieve the purpose of the embodiment, which is not limited herein.
In addition, technical details not described in detail in this embodiment may refer to the block chain node disaster recovery method based on consensus provided in any embodiment of the present invention, which is not described herein.
Furthermore, it should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.
From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. Read Only Memory)/RAM, magnetic disk, optical disk) and including several instructions for causing a terminal device (which may be a mobile phone, a computer, an integrated platform workstation, or a network device, etc.) to perform the method according to the embodiments of the present invention.
The foregoing description is only of the preferred embodiments of the present invention, and is not intended to limit the scope of the invention, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.
Claims (10)
1. The block chain node disaster recovery method based on the consensus is characterized by comprising the following steps of:
when the service quality value of the target important node is smaller than a preset service quality threshold value, a node rotation request is sent to other important nodes through the target node;
selecting standby important nodes according to the node rotation request through a preset consensus strategy;
and if the standby important node is detected to execute the target correct operation in the preset time, the target important node is rotated to be the standby important node.
2. The method for disaster recovery of blockchain nodes based on consensus as in claim 1, wherein when the quality of service value of the target important node is less than the preset quality of service threshold, sending a node rotation request to other important nodes by the target node comprises:
detecting the target important node through a standby node to obtain the current online time length and the service processing speed;
calculating the service quality value of the target important node according to the current online time length and the service processing speed;
and when the service quality value of the target important node is smaller than a preset service quality threshold value, sending a node rotation request to other important nodes through the target node.
3. The method for disaster recovery of blockchain nodes based on consensus as in claim 1, wherein the electing the standby important nodes according to the node rotation request through a preset consensus strategy comprises:
judging whether the selected information which is not transmitted by a certain important node or other important nodes according to the node rotation request can not be received within a set time;
if not, acquiring the voted quantity of any node in the selected nodes through a preset consensus strategy;
when the voted number of any node is larger than a preset voting number threshold value, performing winning broadcast to other nodes in the participating nodes;
and when the selection information of the nodes larger than the voted number is not received in the target time, taking any node as a standby important node.
4. The method for disaster recovery for blockchain nodes based on consensus as in claim 3, wherein when the voted number of any node is greater than a preset vote number threshold, after performing a winning broadcast to other nodes in the participating nodes, further comprising:
when the selection information of the nodes with the number larger than the voted number is received in the target time, the types of the nodes are acquired;
when the type of the node is a voting type, taking any node as a standby important node;
when the type of the node is a reference type, the current voting number is obtained according to the selection information of the node;
and comparing the current voting number with the voted number of any node, and determining a standby important node according to the voting number comparison result.
5. The method of claim 1, wherein if the standby important node is detected to perform the target correct operation within a preset time, the rotating the target important node to the standby important node comprises:
when the standby important node normally operates, detecting whether the standby important node executes target correct operation in preset time;
if yes, the target important node is rotated to be a standby important node.
6. The method of claim 5, wherein if yes, after rotating the target significant node to a standby significant node, further comprising:
monitoring all nodes in the block chain to obtain a current node monitoring result;
when abnormal information exists in the current node monitoring result, determining the node with the abnormality;
removing the abnormal nodes to obtain target reference nodes;
and executing the election of the standby important node again according to the target participating node.
7. The method for disaster recovery of a blockchain node based on consensus as in claim 5, wherein detecting whether the standby inode performs a target correct operation within a preset time when the standby inode is operating normally further comprises:
if not, the standby important node is removed from the selected nodes.
8. The utility model provides a block chain node disaster recovery device based on consensus which characterized in that, block chain node disaster recovery device based on consensus includes:
the sending module is used for sending node rotation requests to other important nodes through the target node when the service quality value of the target important node is smaller than a preset service quality threshold value;
the election module is used for electing standby important nodes according to the node rotation request through a preset consensus strategy;
and the detection module is used for taking the standby important node as a node for guaranteeing the online service quality in the block chain if the standby important node is detected to execute the target correct operation in the preset time.
9. The utility model provides a block chain node disaster recovery equipment based on consensus, its characterized in that, block chain node disaster recovery equipment based on consensus includes: memory, a processor and a consensus-based blockchain node disaster recovery procedure stored on the memory and executable on the processor, the consensus-based blockchain node disaster recovery procedure configured to implement the consensus-based blockchain node disaster recovery method of any of claims 1-7.
10. A storage medium having stored thereon a co-based blockchain node disaster recovery procedure that when executed by a processor implements the co-based blockchain node disaster recovery method of any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310542193.2A CN116260707B (en) | 2023-05-15 | 2023-05-15 | Block chain node disaster recovery method, device and equipment based on consensus and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310542193.2A CN116260707B (en) | 2023-05-15 | 2023-05-15 | Block chain node disaster recovery method, device and equipment based on consensus and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116260707A true CN116260707A (en) | 2023-06-13 |
| CN116260707B CN116260707B (en) | 2023-10-10 |
Family
ID=86686464
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310542193.2A Active CN116260707B (en) | 2023-05-15 | 2023-05-15 | Block chain node disaster recovery method, device and equipment based on consensus and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116260707B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116932278A (en) * | 2023-06-21 | 2023-10-24 | 天云融创数据科技（北京）有限公司 | Database disaster recovery method, device and storage medium |
Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108134706A (en) * | 2018-01-02 | 2018-06-08 | 中国工商银行股份有限公司 | Block chain high-availability system mostly living, computer equipment and method |
| WO2018177239A1 (en) * | 2017-03-28 | 2018-10-04 | 阿里巴巴集团控股有限公司 | Service processing and consensus method and device |
| CN109685504A (en) * | 2018-12-20 | 2019-04-26 | 北京比新科技有限公司 | It is a kind of that economic bookkeeping methods is shared based on block chain |
| CN110009316A (en) * | 2018-12-14 | 2019-07-12 | 阿里巴巴集团控股有限公司 | Event-handling method and device, electronic equipment based on block chain |
| WO2019213867A1 (en) * | 2018-05-09 | 2019-11-14 | 合肥达朴汇联科技有限公司 | Method and device for reaching consensus in blockchain |
| CN111866106A (en) * | 2020-07-09 | 2020-10-30 | 中汇信息技术（上海）有限公司 | Consensus method, consensus device, electronic equipment and readable storage medium |
| WO2020224237A1 (en) * | 2019-05-06 | 2020-11-12 | 深圳壹账通智能科技有限公司 | Blockchain consensus method, apparatus, device and storage medium |
| CN113220483A (en) * | 2021-05-06 | 2021-08-06 | 邢国政 | Switching method and system for block chain consensus main node |
| WO2021184877A1 (en) * | 2020-03-16 | 2021-09-23 | 支付宝(杭州)信息技术有限公司 | Node management method for blockchain system, nodes and computing device |
| WO2021217849A1 (en) * | 2020-04-30 | 2021-11-04 | 平安科技（深圳）有限公司 | Blockchain node synchronization method, apparatus and device, and storage medium |
| CN113645074A (en) * | 2021-08-11 | 2021-11-12 | 永旗(北京)科技有限公司 | Consensus method based on block chain |
| CN113708968A (en) * | 2021-08-27 | 2021-11-26 | 中国互联网络信息中心 | Node election control method and device for block chain |
| CN113726758A (en) * | 2021-08-25 | 2021-11-30 | 百保(上海)科技有限公司 | Data privacy calculation method and system based on block chain |
| WO2021253761A1 (en) * | 2020-06-16 | 2021-12-23 | 杭州溪塔科技有限公司 | Blockchain consensus node state monitoring method and apparatus |
-
2023
- 2023-05-15 CN CN202310542193.2A patent/CN116260707B/en active Active
Patent Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018177239A1 (en) * | 2017-03-28 | 2018-10-04 | 阿里巴巴集团控股有限公司 | Service processing and consensus method and device |
| CN108134706A (en) * | 2018-01-02 | 2018-06-08 | 中国工商银行股份有限公司 | Block chain high-availability system mostly living, computer equipment and method |
| WO2019213867A1 (en) * | 2018-05-09 | 2019-11-14 | 合肥达朴汇联科技有限公司 | Method and device for reaching consensus in blockchain |
| CN110009316A (en) * | 2018-12-14 | 2019-07-12 | 阿里巴巴集团控股有限公司 | Event-handling method and device, electronic equipment based on block chain |
| CN109685504A (en) * | 2018-12-20 | 2019-04-26 | 北京比新科技有限公司 | It is a kind of that economic bookkeeping methods is shared based on block chain |
| WO2020224237A1 (en) * | 2019-05-06 | 2020-11-12 | 深圳壹账通智能科技有限公司 | Blockchain consensus method, apparatus, device and storage medium |
| WO2021184877A1 (en) * | 2020-03-16 | 2021-09-23 | 支付宝(杭州)信息技术有限公司 | Node management method for blockchain system, nodes and computing device |
| WO2021217849A1 (en) * | 2020-04-30 | 2021-11-04 | 平安科技（深圳）有限公司 | Blockchain node synchronization method, apparatus and device, and storage medium |
| WO2021253761A1 (en) * | 2020-06-16 | 2021-12-23 | 杭州溪塔科技有限公司 | Blockchain consensus node state monitoring method and apparatus |
| CN111866106A (en) * | 2020-07-09 | 2020-10-30 | 中汇信息技术（上海）有限公司 | Consensus method, consensus device, electronic equipment and readable storage medium |
| CN113220483A (en) * | 2021-05-06 | 2021-08-06 | 邢国政 | Switching method and system for block chain consensus main node |
| CN113645074A (en) * | 2021-08-11 | 2021-11-12 | 永旗(北京)科技有限公司 | Consensus method based on block chain |
| CN113726758A (en) * | 2021-08-25 | 2021-11-30 | 百保(上海)科技有限公司 | Data privacy calculation method and system based on block chain |
| CN113708968A (en) * | 2021-08-27 | 2021-11-26 | 中国互联网络信息中心 | Node election control method and device for block chain |
Non-Patent Citations (1)
| Title |
|---|
| 宋焘谊;赵运磊;: "区块链共识算法的比较研究", 计算机应用与软件, no. 08 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116932278A (en) * | 2023-06-21 | 2023-10-24 | 天云融创数据科技（北京）有限公司 | Database disaster recovery method, device and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116260707B (en) | 2023-10-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113014634B (en) | Cluster election processing method, device, equipment and storage medium | |
| US20050132154A1 (en) | Reliable leader election in storage area network | |
| EP1550036B1 (en) | Method of solving a split-brain condition in a cluster computer system | |
| CN116260707B (en) | Block chain node disaster recovery method, device and equipment based on consensus and storage medium | |
| CN114866365B (en) | Arbitration machine election method, device, intelligent equipment and computer readable storage medium | |
| CN111901422A (en) | Method, system and device for managing nodes in cluster | |
| CN112579356B (en) | Fault processing method and server | |
| CN115102841B (en) | Network fault recovery method, device, equipment and storage medium | |
| CN106155826B (en) | For the method and system of mistake to be detected and handled in bus structures | |
| CN113391902B (en) | Task scheduling method and device and storage medium | |
| JP2023547782A (en) | ECU management method in a vehicle, ECU and readable storage medium | |
| CN114118991A (en) | Third-party system monitoring system, method, device, equipment and storage medium | |
| CN110781039B (en) | Sentinel process election method and device | |
| CN110322671B (en) | Alarm information processing method and device | |
| CN113055203B (en) | Method and device for recovering exception of SDN control plane | |
| CN110224872B (en) | Communication method, device and storage medium | |
| CN116455830A (en) | Method for realizing high-availability distributed QOS of storage gateway | |
| CN111135585A (en) | Game matching system | |
| CN112367386B (en) | Ignite-based automatic operation and maintenance method and device and computer equipment | |
| CN109218464B (en) | Method, system, equipment and storage medium for reporting address conflict of parallel modules | |
| CN111934909A (en) | Method and device for switching IP (Internet protocol) resources of host and standby machine, computer equipment and storage medium | |
| CN110519098A (en) | A kind of processing method and processing device of abnormal single-board | |
| CN114465879B (en) | Management node election method and device, storage medium and electronic equipment | |
| CN116980346B (en) | Container management method and device based on cloud platform | |
| CN115640109B (en) | Task scheduling method, system and client |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |