CN110572287B - Data disaster tolerance method and device, computer equipment and storage medium - Google Patents
Data disaster tolerance method and device, computer equipment and storage medium Download PDFInfo
- Publication number
- CN110572287B CN110572287B CN201910838460.4A CN201910838460A CN110572287B CN 110572287 B CN110572287 B CN 110572287B CN 201910838460 A CN201910838460 A CN 201910838460A CN 110572287 B CN110572287 B CN 110572287B
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- block
- blocks
- layer number
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- 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
Abstract
The application relates to a data disaster tolerance method, a data disaster tolerance device, computer equipment and a storage medium. The method comprises the following steps: acquiring a replacement instruction triggered when a locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network; determining the observation layer number corresponding to the block locally stored by the observer node according to the replacement instruction; from the number of observation layers, sequentially pulling blocks with the number of layers higher than the number of observation layers from the block chain network; performing consensus on the pulled blocks in the block chain network, and storing the pulled blocks after the consensus is completed until the number of layers of the locally stored blocks reaches the current highest number of layers; and replacing the failed consensus node into a new consensus node. By adopting the method, the disaster tolerance performance of the block chain network can be improved.
Description
Technical Field
The present application relates to the field of block chain technologies, and in particular, to a data disaster recovery method and apparatus, a computer device, and a storage medium.
Background
With the development of computer technology, blockchain technology has emerged. The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm. The block chain network is a decentralized network, and when a common node in the block chain network fails and a new common node needs to be added, the data cannot be directly copied from a certain common node as the data of the new common node because which common node is completely reliable cannot be guaranteed.
In the conventional technology, once a common node in a blockchain network fails, data needs to be acquired from any common node layer by layer from zero level (zeroth block, i.e., creation block) for calculation, and after calculation, common knowledge is achieved with other common nodes, so that a local block can be formed.
Thus, when the consensus node in the blockchain network fails, the newly added consensus node needs to take a long time to backup the generated blocks in order to participate in the consensus operation, thereby resulting in a low disaster tolerance performance of the blockchain network.
Disclosure of Invention
In view of the foregoing, it is desirable to provide a data disaster recovery method, an apparatus, a computer device, and a storage medium, which can improve the disaster recovery performance of a blockchain network.
A data disaster tolerance method is applied to an observer node in a block chain network, and the method comprises the following steps:
acquiring a replacement instruction triggered when a locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network;
determining the observation layer number corresponding to the block locally stored by the observer node according to the replacement instruction;
sequentially pulling blocks with the layer number higher than the observation layer number from the block chain network from the observation layer number;
performing consensus on the pulled blocks in the block chain network, and storing the pulled blocks after the consensus is completed until the number of layers of the locally stored blocks reaches the current highest number of layers;
and replacing the failed consensus node into a new consensus node.
A data disaster recovery apparatus, the apparatus comprising:
the acquisition module is used for acquiring a replacement instruction triggered when the locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network;
the determining module is used for determining the observation layer number corresponding to the block locally stored by the observer node according to the replacing instruction;
the pulling module is used for pulling blocks with the layer number higher than the observation layer number from the block chain network in sequence from the observation layer number;
the storage module is used for carrying out consensus on the pulled blocks in the block chain network, and storing the pulled blocks after the consensus is finished until the layer number of the locally stored blocks reaches the current highest layer number;
and the replacing module is used for replacing the failed consensus node into a new consensus node.
A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the following steps when executing the computer program:
acquiring a replacement instruction triggered when a locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network;
determining the observation layer number corresponding to the block locally stored by the observer node according to the replacement instruction;
sequentially pulling blocks with the layer number higher than the observation layer number from the block chain network from the observation layer number;
performing consensus on the pulled blocks in the block chain network, and storing the pulled blocks after the consensus is completed until the number of layers of the locally stored blocks reaches the current highest number of layers;
and replacing the failed consensus node into a new consensus node.
A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, carries out the steps of:
acquiring a replacement instruction triggered when a locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network;
determining the observation layer number corresponding to the block locally stored by the observer node according to the replacement instruction;
sequentially pulling blocks with the layer number higher than the observation layer number from the block chain network from the observation layer number;
performing consensus on the pulled blocks in the block chain network, and storing the pulled blocks after the consensus is completed until the number of layers of the locally stored blocks reaches the current highest number of layers;
and replacing the failed consensus node into a new consensus node.
According to the data disaster recovery method, the data disaster recovery device, the computer equipment and the storage medium, when the common node in the blockchain network fails, the observer node in the same blockchain network can directly pull the blocks with the layer number higher than the observation layer number from the observation layer number corresponding to the locally stored block in the blockchain network in sequence. And after the consensus is completed, the legality of the data of the pulled block can be determined, so that the pulled block can be stored. When the number of layers of the block stored by the observer node reaches the highest number of layers of the current block chain network, the observer node can replace the failed consensus node as a new consensus node. Therefore, the observer node is arranged in the block chain network, blocks with a certain number of layers are stored in the observer node, and when the consensus node in the block chain network fails, the observer node can rapidly pull the blocks from the original number of layers to perform consensus processing without starting from zero. Therefore, the observer node can be quickly replaced with the fault consensus node to participate in consensus, and the disaster tolerance performance of the block chain network is obviously improved.
Drawings
Fig. 1 is an application scenario diagram of a data disaster recovery method in an embodiment;
FIG. 2 is a flow chart illustrating a data disaster recovery method according to an embodiment;
FIG. 3 is a block diagram of an embodiment of a viewer node pull block;
FIG. 4 is a distribution diagram of consensus nodes and observer nodes in a blockchain network in one embodiment;
FIG. 5 is a flowchart illustrating the steps performed by the observer node in backing up blocks in the consensus node in one embodiment;
FIG. 6 is a flow diagram of an embodiment of a viewer node performing a consistency check on a pulled block;
FIG. 7 is a flowchart illustrating the step of a watcher node pulling a higher number of layers than the number of watching layers from the blockchain network in one embodiment;
FIG. 8 is a flow diagram illustrating a process by which an observer node performs a consensus on a pulled block in a blockchain network, according to an embodiment;
fig. 9 is a schematic flow chart of a data disaster recovery method according to another embodiment;
FIG. 10 is a block diagram of an embodiment of a data disaster recovery device;
FIG. 11 is a diagram illustrating an internal structure of a computer device in one embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
The data disaster recovery method provided by the application can be applied to the application environment shown in fig. 1. Referring to fig. 1, the data disaster recovery method is applied to a data disaster recovery system. The data disaster recovery system includes an observer node 102 and a consensus node 104. Wherein the watcher node 102 and the consensus node 104 are in the same blockchain network. The blockchain network may specifically include one or more watcher nodes 102, and a plurality of consensus nodes 104. The observer node 102 and the consensus node 104 may each be implemented as a separate server or as a server cluster of multiple servers.
The consensus node 104 and the observer node 102 are in the same blockchain network, the observer node 102 and the consensus node 104 communicate through the network, and the consensus nodes 104 also communicate through the network. The observer node 102 obtains a replacement instruction triggered when the locally observed consensus node 104 fails, and the observer node 102 determines the observation layer number corresponding to the locally stored block according to the replacement instruction. The observer node 102 sequentially pulls blocks with a higher number of layers than the number of observation layers from the blockchain network from the number of observation layers. The observer node 102 performs consensus on the pulled blocks in the blockchain network, stores the pulled blocks after consensus is completed, and replaces the failed consensus node 104 with the observer node 102 to become a new consensus node until the number of layers of the locally stored blocks reaches the current highest number of layers. Those skilled in the art will understand that the application environment shown in fig. 1 is only a part of the scenario related to the present application, and does not constitute a limitation to the application environment of the present application.
In one embodiment, as shown in fig. 2, a data disaster recovery method is provided, which is described by taking the method as an example applied to the observer node 102 in fig. 1, and includes the following steps:
s202, acquiring a replacement instruction triggered when the locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network.
The blockchain network is a carrier and organization mode for running blockchain technology. The block chain technology, bt (block chain technology) for short, also called distributed book technology, is an internet database technology, and is characterized by decentralization and public transparency, so that everyone can participate in data recording. The blockchain technology is a brand new distributed infrastructure and computing mode that uses blockchain data structures to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to secure data transmission and access, and uses intelligent contracts composed of automated script codes to program and manipulate data.
The consensus node is a node having voting right in the blockchain network, and is used for participating in consensus in the blockchain network. The observer node is a backup node in the blockchain network, has no voting right, and is used for backing up data in the observed consensus node.
Specifically, the observer node and the consensus node are in the same blockchain network, and when the consensus node observed by the observer node fails, the consensus node may trigger generation of a replacement instruction and send the generated replacement instruction to the corresponding observer node. Or, when the consensus node observed by the observer node fails, the consensus node may report a failure event to the central node, and the central node sends a replacement instruction to the observer node corresponding to the consensus node after receiving the failure event. The central node is a node except the consensus node and the observer node in the block chain network, and can be used for managing the consensus node and the observer node.
In one embodiment, the consensus node observed by the observer node fails, which may be a hardware performance failure of the consensus node itself. For example, a hardware component such as a Central Processing Unit (CPU), a power supply, or a chassis of the common node is damaged.
In one embodiment, the consensus node observed by the observer node fails, which may be a software failure of the consensus node itself. For example, the common node becomes a malicious common node due to the fact that a software of the common node is in error, data of a block stored by the common node is artificially falsified, and the common node is invaded by a virus.
In one embodiment, when a new consensus node needs to be added to the blockchain network, the observer node determines the number of layers of the locally stored block. When the number of layers of the block locally stored by the observer node is consistent with that of the observed block of the consensus node, the observer node can be upgraded to the consensus node to be used as a new consensus node to participate in the consensus work.
And S204, determining the observation layer number corresponding to the block locally stored by the observer node according to the replacement instruction.
The number of observation layers is the number of layers of the newly stored block in the blocks locally stored by the observer node. For example, if the new chunk newly stored by the observer node is the hundredth layer, the number of observation layers corresponding to the chunk locally stored by the observer node may be determined to be the hundredth layer.
Specifically, the observer node may, in response to the received replacement instruction, check the number of layers corresponding to each locally stored block, and use the highest number of layers in the number of layers corresponding to each block as the current observed number of layers.
In an embodiment, the step S204, that is, the step of determining, according to the replacement instruction, the number of observation layers corresponding to the block locally stored by the observer node specifically includes: determining a newly stored block in the blocks locally stored by the observer node according to the replacement instruction; and taking the layer number corresponding to the new block as the observation layer number corresponding to the observer node.
Specifically, after receiving the replacement instruction, the observer node may determine, according to the received replacement instruction, a new block that is newly stored in the blocks locally stored by the observer node according to the time for storing each block. And taking the layer number corresponding to the new block as the observation layer number corresponding to the observer node. It is understood that the blocks are generated continuously, and the number of layers corresponding to the continuously generated blocks may be increased continuously, so that the number of layers corresponding to the newly generated block is the currently largest number of layers. Therefore, the observer node can quickly determine the newly stored new block according to the time generated by each block, and accordingly, the observation layer number corresponding to the observer node can be quickly determined.
In one embodiment, the observer node may store the blocks in the consensus node synchronously while observing the consensus node. The observer node may continuously pull the corresponding block from the observed consensus node to be stored locally, starting from the block of the zeroth layer in the consensus node.
In one embodiment, the observer node may periodically pull blocks with a number of layers higher than the number of locally corresponding observation layers from the observed common node according to a preset time period, perform consistency check on the pulled blocks, and store the pulled blocks when the check is passed.
In one embodiment, when the observer node detects that a block in the observed common node changes, a newly generated block in the observed common node can be pulled in time, the pulled block is subjected to consistency check, and the pulled block is stored when the check passes. The process of the observer node performing the consistency check on the pulled block will be described in detail in the following embodiments.
Referring to fig. 3, fig. 3 is a schematic diagram illustrating an embodiment of a structure of a pull block of a viewer node. Referring to fig. 3, the consensus node may generate a new block and process the new block, i.e., hash the data in the new block, perform a consensus operation, and so on. When consensus is complete, the consensus node may store the new block. The observer node can pull the new block stored in the common node and perform hash processing on the data in the new block, and when the hash value corresponding to the new block processed by the observer node is consistent with the hash value obtained when the new block is processed by the common node, it can be determined that the new block passes the consistency check, and then the observer node can store the new block.
And S206, sequentially pulling blocks with the layer number higher than the observation layer number from the block chain network from the observation layer number.
Specifically, when the number of layers of the blocks stored in the common node observed by the observer node is higher than the number of observed layers, the observer node may sequentially pull the blocks with the number of layers higher than the number of observed layers from the common node according to the number of layers corresponding to each block from low to high.
In one embodiment, the observer node may determine a well-functioning consensus node in the blockchain network. Then, the observer node determines the current highest layer number corresponding to the block stored in the well-functioning consensus node. Therefore, the observer node can pull the blocks with the layer number higher than the observation layer number from the observation layer number to the block with the highest layer number from the well-operated common node in sequence.
The highest layer number is the layer number of a newly stored block in the blocks locally stored by the common node in the block chain network. For example, the number of newly stored new blocks in the blocks locally stored by the common node in the blockchain network is the first thousand layers. Then the highest number of layers of the tile stored locally at the common node in the current blockchain network may be determined to be the first thousand layers.
In one embodiment, the consensus nodes in the blockchain network may be deployed in a computer room. Referring to fig. 4, fig. 4 is a distribution diagram of consensus nodes and observer nodes in a blockchain network in one embodiment. For example, referring to fig. 4, there are four consensus nodes in the blockchain network: a consensus node 11, a consensus node 12, a consensus node 21 and a consensus node 22. In addition, there are two watcher nodes in the blockchain network: observer node 1 and observer node 2. The consensus node 11, the consensus node 12 and the observer node 1 are placed in the machine room 1, and the observer node can observe at least one of the consensus node 11 and the consensus node 12. The consensus node 21, the consensus node 22 and the observer node 2 are placed in the room 2, and the observer node can observe at least one of the consensus node 21 and the consensus node 22.
In one embodiment, when any one of the consensus nodes 11 and 12 in the premises 1 fails, the watcher node 1 may replace the failed consensus node as a new consensus node. At this time, the number of the common nodes in the blockchain network is four. The consensus can be completed as long as more than half of the consensus nodes in the blockchain network are well-functioning. Therefore, the blockchain system can perform consensus work as long as three or more than three consensus nodes in the blockchain system are good.
In one embodiment, when any one of the consensus nodes 11 and 12 in the computer room 1 fails, the observer node 1 may replace the consensus nodes 11 and 12 in the computer room 1 as a new consensus node in the computer room 1. At this time, the number of the common nodes in the blockchain system is changed from four to three, and the blockchain system can perform the common operation as long as two or more than two common nodes are well operated.
In an embodiment, both the common node 11 and the common node 12 in the machine room 1 have a fault, and the observer node 1 in the machine room 1 and the observer node 2 in the machine room 2 may respectively replace the common node 11 and the common node 12 in the machine room 1 to serve as new common nodes in the machine room 1. At this time, the number of the common nodes in the blockchain network is four, and the blockchain system can perform the common operation as long as three or more than three common nodes are well operated.
And S208, performing consensus on the pulled blocks in the block chain network, and storing the pulled blocks after the consensus is completed until the number of layers of the locally stored blocks reaches the current highest number of layers.
Specifically, after each layer of block is pulled by the observer node, the data in the pulled block is sent to the consensus node in the block chain network where the observer node is located. When the consensus node performs consensus operation to achieve consensus according to the data in the block, the observer node stores the pulled block. Further, the observer node pulls a higher layer of blocks, performs consensus in the blockchain network in the same manner, and stores the pulled blocks after the consensus is completed. And performing consensus operation layer by layer, and storing the blocks after the consensus operation is completed until the block with the highest layer number in the current block chain network is stored.
Common consensus algorithms in the blockchain network include POW (Proof of Work), POS (Proof of interest), DPOS (guaranteed Proof of interest), PBFT (Practical Byzantine Fault-tolerant algorithm), and the like. The embodiment of the application does not limit the consensus algorithm adopted by the consensus node.
In one embodiment, the block chain network may perform the block consensus in the following manner: the block stores transaction information corresponding to a plurality of transactions, and the observer node can carry out validity verification on the transaction information. The transaction information may specifically include a name of the transaction, time of the transaction, a resource transfer amount, a quantity of the transaction, account names of two parties of the transaction, and the like. And verifying the validity of the transaction information, specifically verifying the validity of the transaction information, whether the transaction information is correct, and the like. The transaction information which passes the validity verification is the transaction information which is complete in record, correct and not falsified.
Furthermore, the observer node can perform corresponding hash processing on the transaction information passing the validity verification to obtain a corresponding hash value. The observer node may send the hash value to each of the consensus nodes in the blockchain network. And each common identification node also carries out validity verification on the transaction information in the block, and carries out corresponding hash processing on the transaction information passing the validity verification to obtain a corresponding hash value. When the hash values calculated by more than half of the common nodes in the block chain network are consistent, the block is considered to pass the common identification. The observer node may then store the blocks that pass the consensus check locally.
It is understood that the hash process may specifically be to obtain the root of the mercker tree by using the mercker tree algorithm. The data of the block may also be processed by using MD5(Message-Digest Algorithm), SHA-1(Secure Hash Algorithm-1), or SHA-2(Secure Hash Algorithm-2), and the like, which is not limited herein in this embodiment of the present application.
And S210, replacing the failed consensus node into a new consensus node.
Specifically, when the number of layers of the block locally stored by the observer node reaches the current highest number of layers, the failed consensus node may halt operation, and the observer node replaces the failed consensus node to become a new consensus node in the blockchain network.
In one embodiment, the step S210, namely, the step of replacing the failed consensus node into a new consensus node specifically includes: triggering and suspending the operation of the fault consensus node; switching the working mode of the observer node from an observation mode to a consensus mode; and replacing the failed consensus node to become a new consensus node and participating in consensus work of the block chain network.
The observation mode is a working mode for performing observation and backup processing, and the observer node does not participate in the consensus work of the block chain in the observation mode. The consensus mode is an operation mode that participates in consensus work. Specifically, when the number of layers of the block locally stored by the observer node reaches the current highest number of layers, the operation of the failed consensus node can be triggered to be suspended. And then the current working mode can be switched from the observation mode to the consensus mode, so that the consensus node with the fault is replaced to be a new consensus node, and the consensus node participates in the consensus work of the block chain network.
In one embodiment, the failed consensus node is suspended, and specifically, the failed consensus node locally suspends the consensus operation in the blockchain network after detecting that the local anomaly occurs. Alternatively, the observer node may suspend the consensus operation of the consensus node on the blockchain network when the consensus node fails. Or when the consensus node fails, the consensus node can be reported to the central node, and the consensus operation of the consensus node in the block chain network is suspended under the control of the central node. Therefore, when the consensus node fails, the observer node can replace the failed consensus node to participate in the consensus work in the blockchain network, so that the good operation state of the blockchain network is ensured, and the disaster tolerance performance of the blockchain network is improved.
In the data disaster recovery method, when the common node in the blockchain network fails, the observer node in the same blockchain network can directly pull the blocks with the layer number higher than the observation layer number from the observation layer number corresponding to the locally stored block in the blockchain network in sequence. And after the consensus is completed, the legality of the data of the pulled block can be determined, so that the pulled block can be stored. When the number of layers of the block stored by the observer node reaches the highest number of layers of the current block chain network, the observer node can replace the failed consensus node as a new consensus node. Therefore, the observer node is arranged in the block chain network, blocks with a certain number of layers are stored in the observer node, and when the consensus node in the block chain network fails, the observer node can rapidly pull the blocks from the original number of layers to perform consensus processing without starting from zero. Therefore, the observer node can be quickly replaced with the fault consensus node to participate in consensus, and the disaster tolerance performance of the block chain network is obviously improved.
As shown in fig. 5, in one embodiment, step S202 is to obtain a replacement instruction triggered when the locally observed consensus node fails; before the step that the consensus node and the observer node are in the same block chain network, the data disaster recovery method further comprises a step that the observer node backs up the blocks in the consensus node, wherein the step comprises the following steps:
s502, determine the blocks observed by the observer node and stored in the consensus node in the blockchain network.
Specifically, a consensus node and an observer node exist in the blockchain network, and blocks are stored in both the consensus node and the observer node. The observer node determines a locally observed consensus node in the blockchain network and determines the blocks stored in the consensus node.
S504, the observation layer number corresponding to the block locally stored by the observer node is determined.
Specifically, the observer node may determine, according to the time stored in each local block, a new block newly stored in the locally stored block, and use the number of layers corresponding to the newly stored block as the number of observation layers corresponding to the observer node.
And S506, when the blocks with the layer number larger than the observation layer number exist in the consensus node, sequentially pulling the blocks with the layer number larger than the observation layer number from the consensus node.
Specifically, the number of observed layers corresponding to the locally stored block of the observer node is compared with the number of layers of the locally observed block of the consensus node. When the blocks with the layer number larger than the observation layer number exist in the common node, the observer node sequentially pulls the blocks with the layer number larger than the observation layer number from the observed common node.
In one embodiment, the observer node may pull the tiles from the consensus node of the blockchain network at a predetermined time. The predetermined time may be specifically set to a processing period of the largest block in the common node. For example, the number of blocks stored in the common node of the current blockchain network is ten thousand. Wherein the processing time of the maximum block is 50ms, the predetermined time for pulling the block from the common node in the blockchain network may be set to 50 ms.
S508, consistency check is carried out on the pulled blocks, and the pulled blocks are stored when the check is passed.
Specifically, the observer node may pull the blocks in the common node from a low layer to a high layer in sequence from the observed common node. After each layer of block is pulled, the observer node performs a consistency check on the pulled block. When the pulled block passes the consistency check, the observer node may store the pulled block.
In one embodiment, the observer node stores much information in each chunk pulled from the consensus node. When the observer node pulls a block from the common node, the information of the block can be hashed to obtain a corresponding hash value. When the consensus node performs consensus on the block before the block is stored, the same method is also adopted to calculate the hash value corresponding to the block, and the hash value corresponding to the block is stored in the consensus node. The observer node may perform consistency check on the block by comparing the hash value corresponding to the block stored in the common node with the locally calculated hash value. If the two blocks are consistent, the check can be judged to be passed, so that the observer node can store the checked blocks to the local.
In the above embodiment, when there is a block with a layer number greater than the observed layer number in the common node, it indicates that the highest layer number of the block stored in the common node has been updated. In order to ensure that the observer node can timely backup the observed data of the consensus node, blocks with the layer number greater than the observation layer number can be sequentially pulled from the consensus node. On the premise of ensuring data consistency, blocks in the consensus nodes can be backed up in time, so that when the consensus nodes observed by the observer nodes fail, the observer nodes can start processing from the current existing layer number, and the observer nodes can be quickly recovered after the failure occurs.
As shown in fig. 6, in an embodiment, step S508, namely, performing a consistency check on the pulled block, the step of storing the pulled block when the check is passed specifically includes:
s602, acquiring a first processing result corresponding to the pulled block from the observed consensus node; the first processing result is obtained by performing hash processing on the effective transaction information in the block by the consensus node before the block is stored, and the first processing result passes consensus verification of the block chain network.
Specifically, the observer node may search for a first processing result corresponding to the pulled tile from the locally observed consensus node. In one embodiment, the consensus node may process the valid transaction information in the block to be stored by using a merkel tree algorithm to obtain a first processing result. The first processing result may be specifically a root of the merkel tree, or values of leaf nodes and intermediate nodes in the merkel tree, and the like, and this embodiment of the present application is not limited herein.
S604, verifying the validity of each transaction information in the pulled block.
Specifically, the block of the consensus node observed by the observer node has transaction information stored therein. After the observer node pulls the observed block of the common node, validity verification is carried out on each transaction information of the pulled block.
And S606, carrying out hash processing on the effective transaction information to obtain a corresponding second processing result.
Specifically, after the observer node performs validity verification on each transaction information in the pulled block, the observer node processes the transaction information that passes the validity verification, such as hash processing, by using the same processing logic as that used for processing the block by using the common identification node, so as to obtain a corresponding second processing result.
In one embodiment, the observer node may process the valid transaction information stored in the pulled block by using the mercker tree algorithm to obtain a second processing result. The second processing result may specifically be a root of the mercker tree, or values of a leaf node and an intermediate node, and the like.
S608, when the second processing result is consistent with the first processing result, the block is determined to pass consistency check, and the pulled block is stored.
Specifically, the observer node may compare the first processing result with the second processing result, and when the second processing result is consistent with the first processing result, the observer node may determine that the block passes the consistency check and store the block. When the check is failed, the observer node can pull the block with the corresponding layer number again from other common identification nodes, perform consistency check on the pulled block again until the block with the layer number passes the check, and perform the steps of pulling and checking the block with the next layer number after storing the block with the layer number. It can be understood that for each pulled block, the observer node can perform the consistency check on the pulled block in the above manner, and when the check is passed, the pulled block can be stored.
In the above embodiment, before the block is backed up, the consistency check is performed on the pulled block, so that it can be ensured that the block backed up and stored by the observer node is a block that has passed the consensus in the blockchain network, that is, an effective block. Therefore, the observer nodes can accurately synchronize the data in the block chain network, and the consistency and the accuracy of the data are guaranteed.
As shown in fig. 7, in an embodiment, the step S206, that is, the step of pulling the tiles with the layer number higher than the observed layer number from the blockchain network sequentially from the observed layer number includes:
s702, determining a consensus node which has a distance from the observer node to the observer node in the block chain network, meets a short-distance condition and works well.
The distance between the observer node and the observer node satisfies the close-range condition, and specifically, the distance between the observer node and the observer node is smaller than a preset threshold, the observer node and the observer node are in the same machine room, or the observer node and the observer node are deployed in a machine room adjacent to the observer node. Specifically, the observer node searches for consensus nodes satisfying the short-distance condition in the blockchain network, and selects good consensus nodes from the found consensus nodes.
S704, determine the highest layer number currently corresponding to the block stored in the well-functioning consensus node.
Specifically, after the observer node determines a well-functioning consensus node, the newly stored new block is determined according to the time of the block stored locally at the consensus node. And taking the layer number corresponding to the new block as the highest layer number of the block currently stored by the common node.
And S706, sequentially pulling the blocks with the layer number higher than the observation layer number from the common identification nodes with good operation from the observation layer number until the block with the highest layer number is pulled.
Specifically, after pulling a layer of block from the number of observation layers, the observer node sends the data in the pulled block to the consensus node in the block chain network where the observer node is located. When the consensus node performs consensus operation to achieve consensus according to the data in the block, the observer node stores the pulled block. Further, the observer node pulls a higher layer of blocks, performs consensus in the blockchain network in the same manner, and stores the pulled blocks after the consensus is completed. And pulling the blocks layer by layer, performing consensus operation on the pulled blocks, and storing the blocks after the consensus operation is completed until the block with the highest layer number in the current block chain network is pulled.
In the above embodiment, when the consensus node fails, the observer node may pull the blocks with the layer number higher than the observation layer number in sequence from the consensus nodes satisfying the short-distance condition and operating well until the block with the highest layer number is pulled. In this way, all blocks in the blockchain network can be synchronized, so that the number of layers of the blocks of the observer node is the same as the number of layers of the blocks of the consensus node in the blockchain network.
As shown in fig. 8, in an embodiment, the step S208 of performing consensus on the pulled blocks in the blockchain network, and storing the pulled blocks after the consensus is completed until the number of locally stored blocks reaches the current highest number of layers specifically includes:
s802, for each layer of pulled blocks, the validity of each transaction message in the pulled blocks is verified.
Specifically, the observer node may store transaction information in each layer of block pulled from the well-functioning consensus node. And the observer node judges the transaction information which is completely and correctly recorded in all the transaction information and is not changed into the valid transaction information.
And S804, carrying out hash processing on the effective transaction information to obtain a corresponding third processing result.
Specifically, the observer node may perform hash processing on the valid transaction information to obtain a corresponding third processing result. In one embodiment, the observer node may perform hash operation on the valid transaction information through a merkel tree algorithm, for example, the observer node divides all valid transaction information into two groups, and performs hash processing on the transaction information of each group to obtain a first layer processing result. And dividing the first layer processing results into a group two by two, and respectively carrying out Hash processing on the first layer processing results of each group to obtain second layer processing results. And dividing the second layer processing results into a group in pairs, and performing hash processing on the second layer processing results of each group respectively to obtain a third layer processing result. And sequentially processing the processing result of each layer according to the method to obtain the processing result of the last layer. The processing result of the last layer can be regarded as the third processing result.
In one embodiment, the observer node may process the valid transaction information stored in the pulled block by using the mercker tree algorithm to obtain a third processing result. The third processing result may specifically be a root of the mercker tree, or may also be values of a leaf node and an intermediate node, and the like, which is not limited herein in this embodiment of the application.
And S806, performing consensus on the third processing result in the block chain network, and storing the pulled block after the consensus is completed until the number of layers of the locally stored block reaches the current highest number of layers.
Specifically, after obtaining the third processing result of the block pulled by each layer, the observer node sends the third processing result to the consensus node in the block chain network where the observer node is located. The observer node may store the pulled block after the third processing result agrees in the blockchain network. Furthermore, the observer node may pull the block of the higher layer, calculate a third processing result corresponding to the block of the higher layer, perform consensus in the blockchain network in the same manner, and store the pulled block after the consensus is completed. And performing pulling and consensus operation layer by layer, and storing the blocks after the consensus is completed until the block with the highest layer number in the current block chain network is stored.
In the above embodiment, since the transaction information stored in the block of the consensus node in the consensus network may have illegal transaction information, it is necessary to perform validity verification on each pulled transaction information of each layer of block. And carrying out hash processing on the transaction information passing the validity verification to obtain a third processing result. In order to ensure the validity of the third processing result, the third processing result needs to be commonly recognized in the blockchain network. And storing the pulled blocks after the consensus is finished until the layer number of the locally stored blocks reaches the current highest layer number. In this way, it is ensured that blocks stored locally by the watcher node are all legitimate.
As shown in fig. 9, in a specific embodiment, the data disaster recovery method includes the following steps:
s902, determine the blocks observed by the observer node and stored in the consensus node in the blockchain network.
And S904, determining the observation layer number corresponding to the block locally stored by the observer node.
And S906, when the blocks with the layer number larger than the observation layer number exist in the consensus node, sequentially pulling the blocks with the layer number larger than the observation layer number from the consensus node.
S908, obtaining a first processing result corresponding to the pulled block from the observed consensus node; the first processing result is obtained by performing hash processing on the effective transaction information in the block by the consensus node before the block is stored, and the first processing result passes consensus verification of the block chain network.
S910, verifying the validity of each transaction information in the pulled block.
And S912, carrying out hash processing on the effective transaction information to obtain a corresponding second processing result.
S914, when the second processing result is consistent with the first processing result, the block is determined to pass the consistency check, and the pulled block is stored.
S916, according to the replacement instruction, determining a new block newly stored in the blocks locally stored in the observer node.
S918, regarding the layer number corresponding to the new block as the observation layer number corresponding to the observer node.
S920, determining a consensus node which satisfies a short-distance condition and works well in the blockchain network.
S922, determine the highest layer number currently corresponding to the block stored in the well-functioning consensus node.
And S924, sequentially pulling the blocks with the layer number higher than the observation layer number from the observation layer number to the block with the highest layer number from the well-operated common identification nodes.
S926, for each layer of block pulled, verifying validity of each transaction information in the pulled block.
And S928, carrying out hash processing on the effective transaction information to obtain a corresponding third processing result.
S930, performing consensus on the third processing result in the blockchain network, and storing the pulled block after the consensus is completed until the number of layers of the locally stored block reaches the current highest number of layers.
And S932, triggering and suspending the operation of the failed consensus node.
And S934, switching the working mode of the observer node from the observation mode to the consensus mode.
And S936, replacing the failed consensus node to become a new consensus node and participating in consensus work of the block chain network.
According to the data disaster recovery method, when the common node in the blockchain network fails, the observer node in the same blockchain network can directly pull the blocks with the layer number higher than the observation layer number from the observation layer number corresponding to the locally stored block in the blockchain network in sequence. And after the consensus is completed, the legality of the data of the pulled block can be determined, so that the pulled block can be stored. When the number of layers of the block stored by the observer node reaches the highest number of layers of the current block chain network, the observer node can replace the failed consensus node as a new consensus node. Therefore, the observer node is arranged in the block chain network, blocks with a certain number of layers are stored in the observer node, and when the consensus node in the block chain network fails, the observer node can rapidly pull the blocks from the original number of layers to perform consensus processing without starting from zero. Therefore, the observer node can be quickly replaced with the fault consensus node to participate in consensus, and the disaster tolerance performance of the block chain network is obviously improved.
It should be understood that, although the steps in the flowchart of fig. 9 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a portion of the steps in fig. 9 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performance of the sub-steps or stages is not necessarily sequential, but may be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.
In one embodiment, as shown in fig. 10, there is provided a data disaster recovery apparatus, including: an obtaining module 1001, a determining module 1002, a pulling module 1003, a storing module 1004, and a replacing module 1005, wherein:
an obtaining module 1001, configured to obtain a replacement instruction triggered when a locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network.
The determining module 1002 is configured to determine, according to the replacement instruction, the number of observation layers corresponding to the block locally stored by the observer node.
And a pulling module 1003, configured to pull, from the number of observation layers, blocks with a number of layers higher than the number of observation layers from the block chain network in sequence.
The storage module 1004 is configured to perform consensus on the pulled blocks in the block chain network, and store the pulled blocks after the consensus is completed until the number of layers of the locally stored blocks reaches the current highest number of layers.
And a replacing module 1005, configured to replace the failed consensus node into a new consensus node.
In one embodiment, the determining module 1002 is also for determining the blocks observed by the observer node and stored in the consensus node in the blockchain network; and determining the observation layer number corresponding to the block locally stored by the observer node. The pulling module 1003 is further configured to, when there are blocks with a layer number greater than the observed layer number in the common node, sequentially pull the blocks with the layer number greater than the layer number from the common node. The storage module 1004 is further configured to perform a consistency check on the pulled block, and store the pulled block when the check passes.
In one embodiment, the storage module 1004 is further configured to obtain a first processing result corresponding to the pulled block from the observed common node; the first processing result is obtained by carrying out hash processing on the effective transaction information in the block by the consensus node before the block is stored, and the first processing result passes the consensus verification of the block chain network; verifying the validity of each transaction information in the pulled block; performing hash processing on the effective transaction information to obtain a corresponding second processing result; and when the second processing result is consistent with the first processing result, judging that the block passes the consistency check, and storing the pulled block.
In one embodiment, the determining module 1002 is further configured to determine, according to the replacement instruction, a new block newly stored in a block locally stored by the watcher node; and taking the layer number corresponding to the new block as the observation layer number corresponding to the observer node.
In one embodiment, the pulling module 1003 is further configured to determine a well-functioning consensus node in the blockchain network, where a distance between the consensus node and the observer node satisfies a close-range condition; determining the current corresponding highest layer number of the block stored in the well-operated consensus node; and from the observation layer number, sequentially pulling the blocks with the layer number higher than the observation layer number from the well-operated common identification nodes until the block with the highest layer number is pulled.
In one embodiment, the storage module 1004 is further configured to verify validity of each transaction information in the pulled block for each layer block; performing hash processing on the effective transaction information to obtain a corresponding third processing result; and performing consensus on the third processing result in the block chain network, and storing the pulled block after the consensus is completed until the layer number of the locally stored block reaches the current highest layer number.
In one embodiment, the replacement module 1005 is further configured to trigger suspension of operation of the failed consensus node; switching the working mode of the observer node from an observation mode to a consensus mode; and replacing the failed consensus node to become a new consensus node and participating in consensus work of the block chain network.
According to the data disaster recovery device, when the common node in the blockchain network fails, the observer node in the same blockchain network can directly pull the blocks with the layer number higher than the observation layer number from the observation layer number corresponding to the locally stored block in the blockchain network in sequence. And after the consensus is completed, the legality of the data of the pulled block can be determined, so that the pulled block can be stored. When the number of layers of the block stored by the observer node reaches the highest number of layers of the current block chain network, the observer node can replace the failed consensus node as a new consensus node. Therefore, the observer node is arranged in the block chain network, blocks with a certain number of layers are stored in the observer node, and when the consensus node in the block chain network fails, the observer node can rapidly pull the blocks from the original number of layers to perform consensus processing without starting from zero. Therefore, the observer node can be quickly replaced with the fault consensus node to participate in consensus, and the disaster tolerance performance of the block chain network is obviously improved.
For specific limitations of the data disaster recovery device, reference may be made to the above limitations of the data disaster recovery method, which is not described herein again. All or part of each module in the data disaster recovery device can be realized by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.
In one embodiment, a computer device is provided, which may be the viewer node 102 of fig. 1 described above, and its internal structure diagram may be as shown in fig. 11. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a data disaster recovery method.
Those skilled in the art will appreciate that the architecture shown in fig. 11 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
In one embodiment, the data disaster recovery apparatus provided in the present application may be implemented in a form of a computer program, and the computer program may be run on a computer device as shown in fig. 11. The memory of the computer device may store various program modules constituting the data disaster recovery apparatus, such as the acquisition module, the determination module, the pull module, the storage module, and the replacement module shown in fig. 10. The computer program constituted by the respective program modules causes the processor to execute the steps in the data disaster recovery method according to the respective embodiments of the present application described in the present specification.
For example, the computer device shown in fig. 11 may execute step S202 through the acquisition module in the data disaster recovery apparatus shown in fig. 10. The computer device may perform step S204 by the determination module. The computer device may perform step S206 by the pull module. The computer device may perform step S208 through the storage module. The computer device may perform step S210 through the replacement module.
In one embodiment, a computer device is provided, comprising a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the data disaster recovery method described above. Here, the steps of the data disaster recovery method may be steps in the data disaster recovery method of each of the above embodiments.
In one embodiment, a computer-readable storage medium is provided, in which a computer program is stored, which, when executed by a processor, causes the processor to perform the steps of the above-mentioned data disaster recovery method. Here, the steps of the data disaster recovery method may be steps in the data disaster recovery method of each of the above embodiments.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, or other media used in the embodiments provided herein can include non-volatile and/or volatile memory. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.
Claims (15)
1. A data disaster tolerance method is applied to an observer node in a block chain network, and the method comprises the following steps:
acquiring a replacement instruction triggered when a locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network;
determining the observation layer number corresponding to the block locally stored by the observer node according to the replacement instruction;
sequentially pulling blocks with the layer number higher than the observation layer number from the block chain network from the observation layer number;
performing consensus on the pulled blocks in the block chain network, and storing the pulled blocks after the consensus is completed until the number of layers of the locally stored blocks reaches the current highest number of layers;
and replacing the failed consensus node into a new consensus node.
2. The method of claim 1, wherein prior to obtaining the replacement instruction triggered by the failure of the locally observed consensus node, the method further comprises:
determining blocks observed by an observer node and stored in a consensus node in a blockchain network;
determining the observation layer number corresponding to the block locally stored by the observer node;
when blocks with the layer number larger than the observation layer number exist in the consensus node, sequentially pulling the blocks with the layer number larger than the observation layer number from the consensus node;
and carrying out consistency check on the pulled blocks, and storing the pulled blocks when the check is passed.
3. The method of claim 2, wherein said performing a consistency check on the pulled block, storing the pulled block when the check passes, comprises:
obtaining a first processing result corresponding to the pulled block from the observed consensus node;
the first processing result is obtained by performing hash processing on the effective transaction information in the block before the block is stored by the consensus node, and the first processing result passes consensus verification of a block chain network;
verifying the validity of each transaction information in the pulled block;
performing hash processing on the effective transaction information to obtain a corresponding second processing result;
and when the second processing result is consistent with the first processing result, judging that the block passes consistency check, and storing the pulled block.
4. The method according to claim 1, wherein the determining, according to the replacement instruction, the number of observation layers corresponding to the block locally stored by the observer node includes:
determining a newly stored block in the blocks locally stored by the observer node according to the replacement instruction;
and taking the layer number corresponding to the new block as the observation layer number corresponding to the observer node.
5. The method of claim 1, wherein pulling blocks with a higher number of layers than the number of observation layers from the blockchain network in sequence from the number of observation layers comprises:
determining a consensus node which is in the block chain network, has a distance between the consensus node and an observer node meeting a short-distance condition and works well;
determining the current corresponding highest layer number of the block stored in the well-functioning consensus node;
and sequentially pulling blocks with the layer number higher than the observation layer number from the observation layer number to the well-operated common identification nodes until the block with the highest layer number is pulled.
6. The method of claim 1, wherein the consensus of the pulled blocks in the blockchain network, and storing the pulled blocks after the consensus is completed until the number of locally stored blocks reaches the current highest number of layers, comprises:
verifying the validity of each transaction information in each pulled block for each layer of pulled blocks;
performing hash processing on the effective transaction information to obtain a corresponding third processing result;
and performing consensus on the third processing result in the block chain network, and storing the pulled block after the consensus is completed until the number of layers of the locally stored block reaches the current highest number of layers.
7. The method according to any one of claims 1 to 6, wherein replacing the failed consensus node into a new consensus node comprises:
triggering and suspending the operation of the fault consensus node;
switching the working mode of the observer node from an observation mode to a consensus mode;
and replacing the failed consensus node to become a new consensus node and participating in the consensus work of the block chain network.
8. A data disaster recovery apparatus, the apparatus comprising:
the acquisition module is used for acquiring a replacement instruction triggered when the locally observed consensus node fails; the consensus node and the observer node are in the same blockchain network;
the determining module is used for determining the observation layer number corresponding to the block locally stored by the observer node according to the replacing instruction;
the pulling module is used for pulling blocks with the layer number higher than the observation layer number from the block chain network in sequence from the observation layer number;
the storage module is used for carrying out consensus on the pulled blocks in the block chain network, and storing the pulled blocks after the consensus is finished until the layer number of the locally stored blocks reaches the current highest layer number;
and the replacing module is used for replacing the failed consensus node into a new consensus node.
9. The apparatus of claim 8, wherein the determining module is further configured to determine the blocks observed by the observer node and stored in a consensus node in a blockchain network; determining the observation layer number corresponding to the block locally stored by the observer node; the pulling module is further configured to, when blocks with a layer number greater than the observation layer number exist in the common node, sequentially pull the blocks with the layer number greater than the observation layer number from the common node; the storage module is further configured to perform consistency check on the pulled blocks, and store the pulled blocks when the check is passed.
10. The apparatus according to claim 8, wherein the determining module is further configured to determine a new block newly stored in a block locally stored by the watcher node according to the replacement instruction; and taking the layer number corresponding to the new block as the observation layer number corresponding to the observer node.
11. The apparatus of claim 8, wherein the pull module is further configured to determine a well-functioning consensus node in the blockchain network whose distance from the observer node satisfies a short-range condition; determining the current corresponding highest layer number of the block stored in the well-functioning consensus node; and sequentially pulling blocks with the layer number higher than the observation layer number from the observation layer number to the well-operated common identification nodes until the block with the highest layer number is pulled.
12. The apparatus of claim 8, wherein the storage module is further configured to verify validity of each transaction message in the pulled block for each layer of blocks; performing hash processing on the effective transaction information to obtain a corresponding third processing result; and performing consensus on the third processing result in the block chain network, and storing the pulled block after the consensus is completed until the number of layers of the locally stored block reaches the current highest number of layers.
13. The apparatus according to any one of claims 8 to 12, wherein the replacement module is further configured to trigger suspension of operation of the failed consensus node; switching the working mode of the observer node from an observation mode to a consensus mode; and replacing the failed consensus node to become a new consensus node and participating in the consensus work of the block chain network.
14. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method of any of claims 1 to 7 are implemented when the computer program is executed by the processor.
15. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910838460.4A CN110572287B (en) | 2019-09-05 | 2019-09-05 | Data disaster tolerance method and device, computer equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910838460.4A CN110572287B (en) | 2019-09-05 | 2019-09-05 | Data disaster tolerance method and device, computer equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110572287A CN110572287A (en) | 2019-12-13 |
| CN110572287B true CN110572287B (en) | 2022-03-18 |
Family
ID=68778035
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910838460.4A Active CN110572287B (en) | 2019-09-05 | 2019-09-05 | Data disaster tolerance method and device, computer equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110572287B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11496558B2 (en) | 2020-01-29 | 2022-11-08 | Hewlett Packard Enterprise Development Lp | Peer-to-peer blockchain fabric management mechanism |
| CN111061813B (en) * | 2020-03-16 | 2020-07-07 | 支付宝(杭州)信息技术有限公司 | Method, apparatus and computing device for data synchronization in blockchain network |
| CN111654393B (en) * | 2020-05-20 | 2023-01-06 | 中国工商银行股份有限公司 | Block chain networking method and system |
| CN111654415B (en) * | 2020-05-28 | 2021-09-10 | 腾讯科技（深圳）有限公司 | Block chain based information processing method, device, equipment and readable storage medium |
| CN111526217B (en) * | 2020-07-03 | 2020-10-09 | 支付宝(杭州)信息技术有限公司 | Consensus method and system in block chain |
| CN111988188A (en) * | 2020-09-03 | 2020-11-24 | 深圳壹账通智能科技有限公司 | Transaction endorsement method, device and storage medium |
| CN113032594B (en) * | 2021-02-26 | 2023-12-08 | 广东核电合营有限公司 | Label image storage method, apparatus, computer device and storage medium |
| CN114866567B (en) * | 2022-05-26 | 2023-06-02 | 成都质数斯达克科技有限公司 | Disaster-tolerant multi-level blockchain network block synchronization method and device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109313654A (en) * | 2016-05-24 | 2019-02-05 | 万事达卡国际股份有限公司 | The block chain being licensed desynchronize the method and system of recovery using Bloom filter |
| CN109688012A (en) * | 2018-12-29 | 2019-04-26 | 杭州趣链科技有限公司 | A kind of method of alliance's chain node hot standby switch |
| CN109788032A (en) * | 2018-12-17 | 2019-05-21 | 深圳壹账通智能科技有限公司 | Acquisition methods, device, computer equipment and the storage medium of image file |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111614655A (en) * | 2017-03-24 | 2020-09-01 | 创新先进技术有限公司 | Consensus checking method and device |
-
2019
- 2019-09-05 CN CN201910838460.4A patent/CN110572287B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109313654A (en) * | 2016-05-24 | 2019-02-05 | 万事达卡国际股份有限公司 | The block chain being licensed desynchronize the method and system of recovery using Bloom filter |
| CN109788032A (en) * | 2018-12-17 | 2019-05-21 | 深圳壹账通智能科技有限公司 | Acquisition methods, device, computer equipment and the storage medium of image file |
| CN109688012A (en) * | 2018-12-29 | 2019-04-26 | 杭州趣链科技有限公司 | A kind of method of alliance's chain node hot standby switch |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110572287A (en) | 2019-12-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110572287B (en) | Data disaster tolerance method and device, computer equipment and storage medium | |
| CN110633323B (en) | Service data storage method, device, storage medium and computer equipment | |
| CN111049902B (en) | Data storage method, device, storage medium and equipment based on block chain network | |
| CN110602239B (en) | Block chain information storage method and related equipment | |
| CN110784495B (en) | Block chain-based discovery and configuration information management method for big data cluster system | |
| CN108322533A (en) | Configuration and synchronization method between distributed type assemblies node based on operation log | |
| CN105550229A (en) | Method and device for repairing data of distributed storage system | |
| CN111314060B (en) | Key updating method, device and storage medium | |
| CN108334427B (en) | Fault diagnosis method and device in storage system | |
| CN108540447B (en) | Block chain-based certificate verification method and system | |
| CN111432009B (en) | Method and device for synchronizing block chain data, electronic equipment and storage medium | |
| CN111339551B (en) | Data verification method and related device and equipment | |
| CN113312005B (en) | Block chain-based Internet of things data capacity expansion storage method and system and computing equipment | |
| CN113609231A (en) | Method and device for maintaining network architecture information of block chain system | |
| CN110908801B (en) | Data processing method and device based on block chain, computer equipment and storage medium | |
| CN111368279B (en) | Data processing method, data processing device, computer readable storage medium and computer equipment | |
| CN113190620A (en) | Method, device, equipment and storage medium for synchronizing data between Redis clusters | |
| CN115328814B (en) | Fault injection method, device, equipment and storage medium based on mirror pair | |
| CN115297009B (en) | Digital encryption consistency optimization method based on blockchain distributed network | |
| CN113630445B (en) | Data storage method and device based on block chain network | |
| CN110597822A (en) | Information searching method and device in block chain, storage medium and computer equipment | |
| CN105550230A (en) | Method and device for detecting failure of node of distributed storage system | |
| CN109993002B (en) | Data integrity protection method and device | |
| CN111338848B (en) | Failure application copy processing method and device, computer equipment and storage medium | |
| CN114756624A (en) | Data processing method, device and equipment for full-scale nodes and storage medium |
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 |