CN111209343B - Node data synchronization method, device, equipment and storage medium - Google Patents
Node data synchronization method, device, equipment and storage medium Download PDFInfo
- Publication number
- CN111209343B CN111209343B CN202010074098.0A CN202010074098A CN111209343B CN 111209343 B CN111209343 B CN 111209343B CN 202010074098 A CN202010074098 A CN 202010074098A CN 111209343 B CN111209343 B CN 111209343B
- Authority
- CN
- China
- Prior art keywords
- data
- block
- node
- snapshot
- target
- 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
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
- G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The embodiment of the application discloses a node data synchronization method, a device, equipment and a storage medium, wherein the method comprises the following steps: acquiring a first data snapshot from a first data node; acquiring a second data snapshot from a second data node; if the first data snapshot is inconsistent with the second data snapshot, acquiring a data state log of the target block from the block chain, and performing data recovery on the first data snapshot according to the data state log to obtain a third data snapshot; storing first block data of all blocks corresponding to the third data snapshot to a target node; and acquiring second block data of other blocks except all blocks corresponding to the third data snapshot from the first data node, and synchronizing the second block data to the target node. By adopting the embodiment of the application, the node data synchronization time can be reduced, and the node working efficiency is improved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a storage medium for node data synchronization.
Background
With the continuous development of the blockchain technology, on a blockchain platform, in order to ensure the security of data storage, after data of any one node is updated, the data needs to be synchronously stored to other nodes. For any node, the withdrawal data of one block needs to be synchronized again to complete the block data synchronization, however, as more and more blocks are in the block chain, once a new node is added into the block chain, a lot of time is consumed for the new node to complete the synchronization of all the block data, and the work efficiency of the new node is reduced.
Therefore, how to improve the node data synchronization efficiency becomes an urgent problem to be solved.
Disclosure of Invention
The embodiment of the application provides a node data synchronization method, a node data synchronization device and a storage medium, which can reduce the node data synchronization time and improve the node working efficiency.
In a first aspect, an embodiment of the present application provides a node data synchronization method, where the method includes:
acquiring a first data snapshot from a first data node, wherein each data node performs one backup on block data of all blocks of a block chain to obtain a data snapshot when a preset number of blocks are added to the block chain, and the first data snapshot is a data snapshot generated when the first data node performs the last backup at a distance from the current moment;
acquiring a second data snapshot from a second data node, wherein the second data snapshot is a data snapshot generated when the second data node is backed up for the last time from the current moment;
matching the first data snapshot with the second data snapshot, if the first data snapshot is inconsistent with the second data snapshot, acquiring a data state log of a target block from the block chain, and performing data recovery on the first data snapshot according to the data state log to obtain a third data snapshot, wherein the target block is a block with the highest block height in all blocks corresponding to the first data snapshot;
storing the first block data of all blocks corresponding to the third data snapshot to a target node;
and acquiring second block data of other blocks except all blocks corresponding to the third data snapshot from the first data node, and synchronizing the second block data to the target node.
With reference to the first aspect, in a possible implementation manner, the performing data recovery on the first data snapshot according to the data state log to obtain a third data snapshot includes:
determining transaction data, contract data and account data of the target block according to the data state log;
and updating the block data of the target block according to the transaction data, the contract data and the account data to obtain a third data snapshot.
With reference to the first aspect, in one possible implementation, the method further includes:
acquiring second transaction data, second contract data and second account data of the target block from the target block of the block chain;
matching the first transaction data, the first contract data, and the second account data with the second transaction data, the second contract data, and the second account data, respectively;
and updating the block data of the target block if the first transaction data is identical to the second transaction data, the first contract data is identical to the second contract data, and the first account data is identical to the second account data.
With reference to the first aspect, in one possible implementation, the method further includes:
acquiring first Merck tree roots of all blocks corresponding to the third data snapshot according to the first block data;
acquiring second merkel tree roots of all blocks corresponding to the third data snapshot from the block chain;
and matching the first Merck tree root with the second Merck tree root, and if each first Merck tree root is consistent with the corresponding second Merck tree root, executing a step of storing the first block data of all blocks corresponding to the third data snapshot to a target node.
With reference to the first aspect, in one possible implementation, the method further includes:
if the first data snapshot is inconsistent with the second data snapshot, acquiring third block data of other blocks except the target block in all blocks corresponding to the first data snapshot;
acquiring fourth block data of the target block from the target block of the block chain;
and storing the third block data and the fourth block data to the target node.
With reference to the first aspect, in one possible implementation, the synchronizing the second block data to the target node includes:
sending the second block data to a common node so that the common node verifies the second block data according to the block data of other data nodes except the first data node;
and acquiring a verification result of each consensus node, and storing the second block data to the target node when all the verification results meet a preset consensus strategy.
With reference to the first aspect, in one possible implementation, the method further includes:
determining whether a third data node exists in the block chain, wherein the highest block height corresponding to the third data node is higher than the highest block height corresponding to the target node;
and if the third data node exists in the block chain, acquiring fifth block data of a block corresponding to a target block height interval from the third data node, and synchronizing the fifth block data to the target node, wherein the target block height interval is a block height interval from the highest block height corresponding to the target node to the highest block height corresponding to the third data node.
In a second aspect, an embodiment of the present application provides a node data synchronization apparatus, where the apparatus includes:
the first obtaining module is used for obtaining a first data snapshot from a first data node, wherein each data node performs one backup on block data of all blocks of a block chain to obtain the data snapshot when a preset number of blocks are added to the block chain, and the first data snapshot is a data snapshot generated when the first data node performs the last backup at a distance from the current moment;
a second obtaining module, configured to obtain a second data snapshot from a second data node, where the second data snapshot is a data snapshot generated when the second data node is backed up last time from the current time;
a first processing module, configured to match the first data snapshot with the second data snapshot, and if the first data snapshot is inconsistent with the second data snapshot, obtain a data state log of a target block from the block chain, and perform data recovery on the first data snapshot according to the data state log to obtain a third data snapshot, where the target block is a block with a highest block height in all blocks corresponding to the first data snapshot;
a first synchronization module, configured to store first block data of all blocks corresponding to the third data snapshot to a target node;
a second synchronization module, configured to obtain second block data of other blocks from the first data node except for all blocks corresponding to the third data snapshot, and synchronize the second block data to the target node.
With reference to the second aspect, in one possible implementation manner, the first processing module includes:
the determining unit is used for determining the transaction data, contract data and account data of the target block according to the data state log;
and the first updating unit is used for updating the block data of the target block according to the transaction data, the contract data and the account data to obtain a third data snapshot.
With reference to the second aspect, in a possible implementation manner, the first processing module further includes:
the acquisition unit is further used for acquiring second transaction data, second contract data and second account data of the target block from the target block of the block chain;
a matching unit, configured to match the first transaction data, the first contract data, and the second account data with the second transaction data, the second contract data, and the second account data, respectively;
and a second updating unit configured to execute the step of updating the block data of the target block if the first transaction data is identical to the second transaction data, the first contract data is identical to the second contract data, and the first account data is identical to the second account data.
With reference to the second aspect, in a possible implementation manner, the apparatus further includes:
a third obtaining module, configured to obtain, according to the first block data, first mercker tree roots of all blocks corresponding to the third data snapshot;
a fourth obtaining module, configured to obtain second merkel tree roots of all blocks corresponding to the third data snapshot from the block chain;
and the second processing module is further configured to match the first tacher tree root with the second tacher tree root, and if each first tacher tree root is consistent with the corresponding second tacher tree root, perform a step of storing the first block data of all blocks corresponding to the third data snapshot in a target node.
With reference to the second aspect, in a possible implementation manner, the apparatus further includes:
a fifth obtaining module, configured to obtain third block data of other blocks, except the target block, in all blocks corresponding to the first data snapshot if the first data snapshot is inconsistent with the second data snapshot;
a sixth obtaining module, configured to obtain fourth block data of the target block from the target block of the block chain;
and the third synchronization module is further configured to store the third block data and the fourth block data in the target node.
With reference to the second aspect, in one possible implementation manner, the second synchronization module includes:
a sending unit, configured to send the second block data to a common node so that the common node verifies the second block data according to block data of other data nodes except the first data node;
and the synchronization unit is used for acquiring the verification result of each consensus node and storing the second block data to the target node when all the verification results meet a preset consensus strategy.
With reference to the second aspect, in a possible implementation manner, the apparatus further includes:
a determining module, configured to determine whether a third data node exists in the block chain, where a highest block height corresponding to the third data node is higher than a highest block height corresponding to the target node;
the third processing module is further configured to, if the third data node exists in the block chain, obtain fifth block data of a block corresponding to a target block height interval from the third data node, and synchronize the fifth block data to the target node, where the target block height interval is a block height interval from a highest block height corresponding to the target node to a highest block height corresponding to the third data node.
In a third aspect, an embodiment of the present application provides an apparatus, which includes a processor and a memory, where the processor and the memory are connected to each other. The memory is configured to store a computer program that supports the terminal device to execute the method provided by the first aspect and/or any one of the possible implementation manners of the first aspect, where the computer program includes program instructions, and the processor is configured to call the program instructions to execute the method provided by the first aspect and/or any one of the possible implementation manners of the first aspect.
In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program, where the computer program is executed by a processor to implement the method provided by the first aspect and/or any one of the possible implementation manners of the first aspect.
In the embodiment of the application, the data snapshot generated by backing up the block data through the data node is directly used for data synchronization of the target node, so that the time required by data synchronization of the target node is greatly reduced. On the other hand, the data snapshots with the same block height are acquired from different data nodes to restore the acquired data snapshots, so that the block data corresponding to the data snapshots for data synchronization of the target node can be ensured to be complete and correct. Meanwhile, the target only needs to synchronize the block data of other block heights except all the blocks corresponding to the data snapshots, node data synchronization can be completed quickly, and the applicability is high.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.
FIG. 1 is a schematic diagram illustrating a node data synchronization method according to an embodiment of the present disclosure;
fig. 2 is a schematic flow chart of a node data synchronization method according to an embodiment of the present application;
FIG. 3 is a block diagram according to an embodiment of the present disclosure;
fig. 4 is a schematic view of a scenario of node data synchronization provided in an embodiment of the present application;
fig. 5 is another schematic flow chart of a node data synchronization method according to an embodiment of the present application;
fig. 6 is a schematic flowchart of a node data synchronization method according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of a node data synchronization apparatus according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of an apparatus provided in an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Referring to fig. 1, fig. 1 is a schematic diagram illustrating a node data synchronization method according to an embodiment of the present disclosure. In fig. 1, the node 10b and the node 10c are data nodes in a blockchain, where the node 10b and the node 10c perform data backup on the block data of all blocks of the blockchain to obtain a data snapshot every time a preset number of blocks are added to the blockchain. When the node 10a is a node newly added to the blockchain, or the node 10a is a failed node in the blockchain, if the node 10a is added to the blockchain or the failed node 10a is recovered, the block data of the node 10a needs to be synchronized with the data node 10b and the node 10c so that the node 10a can normally operate after the node 10a is added to the blockchain or the node 10a is recovered. When the node 10a is synchronized, the latest data snapshot 30 of the node 10a may be obtained from the node 10a, so that block data of a block height (e.g., within height 100) corresponding to the data snapshot 30 is stored in the node 10 a. On the other hand, the block data 40 of all blocks outside the block height (height 101) corresponding to the data snapshot 30 may be obtained from the node 10c, and the block data 40 may be stored to the node 10a to complete the synchronization of all block data of the current block chain to the node 10 a. The node 10b and the node 10c may also be the same node, and may be determined according to an actual application scenario, which is not limited herein.
Referring to fig. 2, fig. 2 is a schematic flow chart of a node data synchronization method according to an embodiment of the present application. As shown in fig. 2, the node data synchronization method provided in the embodiment of the present application may include the following steps S201 to S205.
S201, obtaining a first data snapshot from a first data node.
In some possible embodiments, the data node in the block chain may detect a change in the number of blocks in the block chain in real time, and each time a preset number of blocks are added to the block chain, the data node may perform a backup on the block data of all the blocks in the block chain at that time to obtain a data snapshot. For example, when there are blocks from height 1 to height 100 in the original blockchain, the data node may be backed up once when the height of the blocks in the blockchain increases to height 200. The data node may be a consensus node with a data backup function, or may be another node that backs up block data in a block chain, and may be determined specifically according to an actual application scenario, which is not limited herein. The preset number may be 100 or other numbers, and may be determined according to an actual application scenario, which is not limited herein.
Specifically, when a target node joins the block chain at the current time, since the block chain is in distributed storage, in order to enable the target node to normally work after joining the block chain, the block data corresponding to the target node needs to be kept consistent with the block data of other data nodes in the block chain. The target node may be a node newly added to the block chain, or may wait for another node performing data recovery, such as a failure node. Further, a first data snapshot may be obtained from the first data node at the current time, where the first data snapshot is a data snapshot generated when the first data node performs backup for the last time at the current time, and the first data snapshot includes block data of all blocks in the block chain in the time zone where the first data node performs backup for the last time. If the first data node performs block data backup at a certain time, the block height corresponding to the added block chain is 100, and at this time, the data snapshot obtained by the first data node performing data backup includes block data of all 100 blocks in the block chain at the certain time.
S202, obtaining a second data snapshot from a second data node
In some possible embodiments, since the first data snapshot is only obtained from the first data node, the data synchronization of the target node is affected once the error data exists in the first data snapshot. A second data snapshot may be taken from a second data node to verify whether the first data snapshot contains erroneous data. The second data snapshot is a data snapshot generated when the second data node is backed up for the last time at the current moment, and the second data snapshot also comprises block data of all blocks in the block chain when the second data node is backed up for the last time. If the first data snapshot includes block data of all 100 blocks in the block chain at the time, the second data snapshot also includes the block data of the 100 blocks. The second data node is any one or more data nodes except the first data node, and the method for verifying the first data snapshot according to the second data snapshot may refer to an implementation manner shown in step S203, which is not described here.
And S203, matching the first data snapshot with the second data snapshot, if the first data snapshot is inconsistent with the second data snapshot, acquiring a data state log of the target block from the block chain, and performing data recovery on the first data snapshot according to the data state log to obtain a third data snapshot.
In some possible implementations, the first data snapshot and the second data snapshot may be matched after the second data snapshot is taken from the second data node. If the first data snapshot is inconsistent with the second data snapshot, the first data snapshot is indicated to have error data, and if the first data snapshot is consistent with the second data snapshot, the first data snapshot is indicated to have no error data. Optionally, after the plurality of second data snapshots are obtained from the plurality of second data nodes, if the first data snapshot is consistent with each second data snapshot or consistent with the second data snapshots exceeding the first preset ratio, it may be determined that no error data exists in the first data snapshot. The first preset proportion may be determined according to the number of the second data snapshots and an actual application scenario, which is not limited herein. If the first data snapshot is inconsistent with each second data snapshot or inconsistent with the second data snapshots which are smaller than a second preset proportion, it can be determined that the first data snapshot has error data, wherein the second preset proportion can also be determined according to the number of the second data snapshots and the actual application scene, and is not limited herein.
Further, when it is determined that there is erroneous data in the first data snapshot, a target block, that is, a block with the highest block height among all blocks covered by the first data snapshot, needs to be determined from the blocks in the block chain. In other words, the last block corresponding to all the block data included in the first data snapshot is the target block. After the target block is determined, a data status log of the target block may be obtained from the target block. The block chain writes a data state log, such as a binary wal log, into a block each time a block is packed, which may be determined according to an actual application scenario, and is not limited herein. On the other hand, since the last block in the block chain includes the block information of all blocks before the last block, and when the data node backs up the block data of all blocks, the block data of all blocks before the backed up last block already stably exists, when the first data snapshot has error data, only the data state log of the target block (the last block corresponding to the first data snapshot) needs to be obtained to restore the block data of the target block in the first data snapshot. The data status log may describe data writing process information of the corresponding block, and may include data processing process, contract data, account data, and the like of the corresponding block, so that the block data of the corresponding block may be recovered according to the data status log.
In some possible embodiments, when the first data snapshot is subjected to data recovery according to the data state log, transaction data, contract data, block data, account data, and the like of the target block may be determined according to the data state log. Specifically, the target block may be re-executed according to the data status log to obtain transaction data, contract data, account data, and the like of the target block, and the transaction data, the contract data, the account data, and the like may be verified. When the data such as the transaction data, the contract data and the account data are accurate and correct, the transaction data, the contract data and the account data are updated to the block data corresponding to the target block in the first data snapshot to obtain an updated first data snapshot (for convenience of description, hereinafter referred to as a third data snapshot) so as to complete data recovery of the first data snapshot. When transaction data, contract data and fund account data are verified, transaction data, contract data, account data and other data of a target block can be obtained from the target block of the block chain, further, the transaction data, the contract data and the account data obtained by re-executing the target block are respectively matched with the transaction data, the contract data and the account data directly obtained from the target block, and if the transaction data, the contract data and the account data are accurate, corresponding data in the first data snapshot can be updated according to the transaction data, the contract data and the account data obtained by executing the target block to obtain a third data snapshot.
And S204, storing the first block data of all blocks corresponding to the third data snapshot to the target node.
In some possible embodiments, after the data of the first data snapshot is restored to obtain a third data snapshot, the block data corresponding to the third data snapshot may be stored to the target node. The target node may restore the block data of each block corresponding to the third data snapshot according to the block data corresponding to the third data snapshot, where the target node stores the block data of all the blocks corresponding to the third data snapshot.
S205, obtain the second block data of the other blocks except all blocks corresponding to the third data snapshot from the first data node, and synchronize the second block data to the target node.
In some possible embodiments, since there is a time interval when the data node performs data backup on the block chain each time, there is a time interval between the time when the target node joins the block chain and the last time when the first data node performs backup, and therefore after storing the block data corresponding to the third data snapshot to the target node, it is further necessary to synchronize the block data of the block that is not backed up by the first data node to the target node. Specifically, the block data of the other blocks except for all blocks corresponding to the third data snapshot may be obtained from the first data node, and the block data may be synchronized to the target node. Optionally, the block data (for convenience of description, hereinafter referred to as second block data) of other blocks except all the blocks corresponding to the third data snapshot may also be obtained from any one data node except the first data node, and may be determined according to an actual application scenario, which is not limited herein.
Optionally, after the second block data is acquired, the second block data may be verified to be synchronized to the target node after determining that the second block data is accurate. Specifically, the second block data may be sent to the common node so that the common node verifies the second block data according to the block data of the other data nodes except the first data node. And the block height corresponding to the block data of other data nodes is consistent with the block height corresponding to the second block data. The common identification nodes can compare the second block data with the block data of other data nodes, each common identification node generates a confirmed consistent result when the second block data is confirmed to be consistent with the block data of other data nodes, and generates a confirmed inconsistent result when the second block data is inconsistent or not completely consistent with the block data of other data nodes. Optionally, the consensus node may further determine a block height corresponding to the second block data, obtain the block data from the block chain from the block corresponding to the block height, verify the second block data according to the block data obtained from the block corresponding to the block height, and determine that the second block data is accurate when the verification result passes the preset consensus policy. The preset consensus strategy can be determined according to an actual application scenario, and is not limited herein.
Optionally, the first merkel root of the block corresponding to the second block data may also be obtained according to the second block data, and the second merkel root of the block may also be obtained from the block body of the block corresponding to the second block data of the block chain. At this time, the first merkel root and the second merkel root may be compared, and if the first merkel root is consistent with the second merkel root, it is determined that the acquired second block data is correct, and the second block data may be further synchronized to the target node according to the second block data. Referring to fig. 3, fig. 3 is a block structure diagram provided in the present application. As shown in fig. 3, the block chain includes a plurality of blocks, each block includes a block header and a block body, the block header stores information such as a mercker tree root, a version number, a timestamp, and a difficulty value, and the block body stores input information; the previous block of each block is a parent block, the next block also comprises a block head and a block main body, the block head stores the root of the current block, the block head characteristic value, the version number, the timestamp and the difficulty value of the parent block, and the like, so that the block data stored in each block in the block chain is associated with the block data stored in the parent block, and the safety of input information in the blocks is ensured. When a new block is generated, the hash value of the Mercker tree root of the new block can be obtained based on each service data; and then, updating the updating time stamp to the time when the input information is received, trying different random numbers, and calculating the characteristic value for multiple times, so that the calculated characteristic value can meet the following formula:
SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET
wherein, version is version information of related block protocols in the block chain; prev _ hash is a block header characteristic value of a parent block of the new block; merkle root is the root of the mercker tree; ntime is the update time of the update timestamp; nbits is the current difficulty, is a fixed value within a period of time, and is determined again after exceeding a fixed time period; x is a random number; TARGET is a feature threshold, which can be determined from nbits. Thus, when the random number meeting the formula is obtained through calculation, the information can be correspondingly stored, and a block header and a block main body are generated to obtain a new block.
Wherein, the service data 1, the service data 2, the service data 3 and the service data 4 can be organized together in the form of a merkel tree. Taking the service data 1 and the service data 2 as examples, the hash value 1 corresponding to the service data 1 can be obtained through hash calculation; similarly, the hash value 2 corresponding to the service data 2 can be calculated through hash calculation. Further, the hash value 1 and the hash value 2 are concatenated, and then hash transformation is continued, so as to obtain the hash value 12 shown in fig. 3. By analogy, for the service data 3 and the service data 4, the hash value 34 shown in fig. 3 can be obtained by performing recursive computation layer by layer, so that the hash value 12 and the hash value 34 can be further concatenated to perform hash transformation until a root (i.e., the hash value 1234 shown in fig. 3) is finally left. At this time, the hash value of all the finally obtained service data may be used as the root of the new chunk. Therefore, whether the second block data acquired from the data node is accurate can be verified by acquiring the root of the merck tree of the block corresponding to the second block data from the block chain.
In some possible embodiments, since the blocks in the block chain are continuously growing, after synchronizing the block data corresponding to the third data snapshot and the second block data to the target node, it is further required to determine whether a block higher than the highest block height corresponding to the second block data exists in the block chain. Specifically, since the block synchronization times of different data nodes are not completely consistent, all data nodes may be traversed to determine a third data node, where the highest block height corresponding to the third data node is higher than the highest block height corresponding to the target node at that time. If the third data node exists in the block chain, the block data of the block corresponding to the block height interval from the highest block height corresponding to the target node to the highest block height corresponding to the third data node can be obtained from the third data node, and the block data of the block corresponding to the block height interval is synchronized to the target node.
Referring to fig. 4, fig. 4 is a schematic view of a scenario of node data synchronization provided in an embodiment of the present application. In fig. 4, the block height corresponding to the third data snapshot obtained from any data node is 100, that is, the third data snapshot corresponds to the block data of the first 100 blocks in the block chain. On the other hand, the block of the data node which is not backed up is determined to be the block from the height 101 to the height 102, and the block data of the two blocks are acquired from the node. After synchronizing the block data of the first 100 blocks and the block data of the blocks with the heights from 101 to 102 to the target node, assuming that a data node 2 and a data node 3 are also present in the block chain, at this time, the data node 2 stores the block data with the highest block height of 102 (i.e., the block data of the first 102 blocks), and the data node 3 stores the block data with the highest block height of 103 (i.e., the block data of the first 103 blocks). At this time, since only the data node 3 stores the block data with the block height of 103, the block data with the withdrawal height of 103 can be obtained from the data node 3 and synchronized to the target node, so as to ensure that the block data corresponding to the target node is always consistent with the block data of all the current blocks in the block chain.
Referring to fig. 5, fig. 5 is another schematic flow chart of a node data synchronization method provided in the embodiment of the present application. As shown in fig. 5, the node data synchronization method provided in the embodiment of the present application includes the following steps S301 to S307.
S301, a first data snapshot is obtained from the first data node.
S302, a second data snapshot is obtained from a second data node.
And S303, matching the first data snapshot with the second data snapshot, if the first data snapshot is inconsistent with the second data snapshot, acquiring a data state log of the target block from the block chain, and performing data recovery on the first data snapshot according to the data state log to obtain a third data snapshot.
In some possible embodiments, the specific implementation of the steps S301 to S303 can refer to the implementation shown in steps S201 to S203 in fig. 2, and will not be described herein again.
S304, obtaining the first Merck tree roots of all blocks corresponding to the third data snapshot according to the first block data.
In some possible embodiments, after the third data snapshot is obtained by data recovery of the first data snapshot, the third data snapshot may be verified in order that no error data exists in the third data snapshot obtained by data recovery of the first data snapshot. When the third data snapshot is verified, the service data of all blocks corresponding to the third data snapshot can be determined according to the third data snapshot, and the root of the merck tree of each block can be obtained according to the service data of each block. Based on the foregoing implementation, the merck tree roots (hereinafter referred to as the first merck tree root for convenience of description) of all the blocks corresponding to the third data snapshot can be obtained.
S305, obtaining second Merck tree roots of all blocks corresponding to the third data snapshot from the block chain.
In some possible embodiments, the block heights of all blocks corresponding to the third data snapshot may be determined, and the blocks having the same block height may be determined from the chain of blocks. Further, the root of the merck tree of each block (for convenience of description, the root of the second merck tree is hereinafter referred to) is obtained from the blocks of the blocks with the same block height.
S306, matching the first Merck tree roots with the second Merck tree roots, and if each first Merck tree root is consistent with the corresponding second Merck tree root, storing the first block data of all blocks corresponding to the third data snapshot to the target node.
In some possible embodiments, after determining the first mercker tree root of all blocks corresponding to the third data snapshot according to the third data snapshot and obtaining the second mercker tree root from the blocks with the same block height in the block chain, the first mercker tree root and the corresponding second mercker tree root may be matched. If the first and second roots of each block are consistent, it is indicated that the block data of each block corresponding to the third data snapshot obtained from the first data node is consistent with the block data of the corresponding block in the block, and it can be determined that there is no error data in the block data of all blocks included in the third data snapshot.
S307, second block data of other blocks except all blocks corresponding to the third data snapshot are obtained from the first data node, and the second block data is synchronized to the target node.
In some possible embodiments, the specific implementation of step S307 may refer to the implementation shown in step S205 in fig. 2, and is not described herein again.
Referring to fig. 6, fig. 6 is a schematic flowchart of a node data synchronization method provided in the embodiment of the present application. As shown in fig. 6, the node data synchronization method provided in the embodiment of the present application may include the following steps S401 to S406.
S401, a first data snapshot is obtained from a first data node.
S402, obtaining a second data snapshot from the second data node.
In some possible embodiments, the specific implementation of the steps S401 to S402 may refer to the implementation shown in the steps S201 to S202 in fig. 2, and will not be described herein again.
And S403, matching the first data snapshot with the second data snapshot, and if the first data snapshot is inconsistent with the second data snapshot, acquiring third block data of other blocks except the target block in all blocks corresponding to the first data snapshot.
In some possible embodiments, when the first data snapshot and the second data snapshot are not consistent, it indicates that there is error data in the first data snapshot, and for the same reason described in step S203 in fig. 2, the error data exists in the last block (for convenience of description, hereinafter referred to as a target block) corresponding to the first data snapshot, that is, there is error data in the block data of the target block in the first data snapshot. At this time, the block data (hereinafter referred to as third block data for convenience of description) of the blocks other than the target block may be obtained from the first data snapshot to ensure that the partial block data obtained from the first data snapshot is accurate data.
S404, acquiring fourth block data of the target block from the target block of the block chain.
In some possible embodiments, since there is error data in the block data of the target block in the first data snapshot, if the block data of the target block is obtained from the data snapshot sinks of other data nodes at this time, there may still be error data in the obtained block data of the target block, and therefore, it is necessary to directly obtain the block data of the target block (hereinafter referred to as fourth block data for convenience of description) from the target block of the block chain.
S405, storing the third block data and the fourth block data to the target node.
In some possible embodiments, the block height ranges corresponding to the third block data and the fourth block data are consistent with the block height range corresponding to the first data snapshot, so that the third block data and the fourth block data can be directly stored in the target node to complete partial block data synchronization of the target node.
S406, second block data of other blocks except all blocks corresponding to the third data snapshot are obtained from the first data node, and the second block data is synchronized to the target node.
In some possible embodiments, the specific implementation of step S406 may refer to the implementation shown in step S205 in fig. 2, and is not described herein again.
In the embodiment of the application, the data snapshot generated by backing up the block data through the data node is directly used for data synchronization of the target node, so that the time required by data synchronization of the target node is greatly reduced. On the other hand, the data snapshots with the same block height are acquired from different data nodes to restore the acquired data snapshots, so that the block data corresponding to the data snapshots for data synchronization of the target node can be ensured to be complete and correct. Meanwhile, the target only needs to synchronize the block data of other block heights except all the blocks corresponding to the data snapshots, node data synchronization can be completed quickly, and the applicability is high.
Referring to fig. 7, fig. 7 is a schematic structural diagram of a node data synchronization apparatus according to an embodiment of the present application. The device 1 provided by the embodiment of the application comprises:
a first obtaining module 11, configured to obtain a first data snapshot from a first data node, where each data node performs a backup on block data of all blocks of a block chain to obtain a data snapshot when a preset number of blocks are added to the block chain, and the first data snapshot is a data snapshot generated when the first data node performs a backup last time from a current time;
a second obtaining module 12, configured to obtain a second data snapshot from a second data node, where the second data snapshot is a data snapshot generated when the second data node is backed up last time from the current time;
a first processing module 13, configured to match the first data snapshot with the second data snapshot, and if the first data snapshot is inconsistent with the second data snapshot, obtain a data state log of a target block from the block chain, and perform data recovery on the first data snapshot according to the data state log to obtain a third data snapshot, where the target block is a block with a highest block height in all blocks corresponding to the first data snapshot;
a first synchronization module 14, configured to store the first block data of all blocks corresponding to the third data snapshot to a target node;
a second synchronization module 15, configured to obtain second block data of other blocks from the first data node except for all blocks corresponding to the third data snapshot, and synchronize the second block data to the target node.
In some possible embodiments, the first processing module 13 includes:
the determining unit 131 is configured to determine transaction data, contract data, and account data of the target block according to the data status log;
the first updating unit 132 is configured to update the block data of the target block according to the transaction data, the contract data, and the account data to obtain a third data snapshot.
In some possible embodiments, the first processing module 13 further includes:
the obtaining unit 133 is further configured to obtain second transaction data, second contract data, and second account data of the target block from the target block of the block chain;
a matching unit 134, configured to match the first transaction data, the first contract data, and the second account data with the second transaction data, the second contract data, and the second account data, respectively;
the second updating unit 135 is further configured to execute the step of updating the block data of the target block if the first transaction data matches the second transaction data, the first contract data matches the second contract data, and the first account data matches the second account data.
In some possible embodiments, the above-mentioned device 1 further comprises:
a third obtaining module 16, configured to obtain first merck tree roots of all blocks corresponding to the third data snapshot according to the first block data;
a fourth obtaining module 17, configured to obtain second merck tree roots of all blocks corresponding to the third data snapshot from the block chain;
the second processing module 18 is further configured to match the first mercker tree root with the second mercker tree root, and if each first mercker tree root is consistent with the corresponding second mercker tree root, perform a step of storing the first block data of all blocks corresponding to the third data snapshot to a target node.
In some possible embodiments, the above-mentioned device 1 further comprises:
a fifth obtaining module 19, configured to obtain third block data of other blocks, except the target block, in all the blocks corresponding to the first data snapshot if the first data snapshot is inconsistent with the second data snapshot;
a sixth obtaining module 20, configured to obtain fourth block data of the target block from the target block of the block chain;
the third synchronization module 21 is further configured to store the third block data and the fourth block data in the target node.
In some possible embodiments, the second synchronization module 15 includes:
a sending unit 151, configured to send the second block data to a common node so that the common node verifies the second block data according to block data of other data nodes except the first data node;
the synchronization unit 152 is configured to obtain a verification result of each consensus node, and store the second block data to the target node when all the verification results satisfy a predetermined consensus policy.
In some possible embodiments, the above-mentioned device 1 further comprises:
a determining module 22, configured to determine whether a third data node exists in the block chain, where a highest block height corresponding to the third data node is higher than a highest block height corresponding to the target node;
the third processing module 23 is further configured to, if the third data node exists in the block chain, obtain fifth block data of a block corresponding to a target block height interval from the third data node, and synchronize the fifth block data to the target node, where the target block height interval is a block height interval from a highest block height corresponding to the target node to a highest block height corresponding to the third data node.
In a specific implementation, the apparatus 1 may execute, through each built-in functional module thereof, the implementation manners provided in the steps in fig. 2, fig. 5, and fig. 6, which may be referred to specifically for the implementation manners provided in the steps, and are not described herein again.
In the embodiment of the application, the data snapshot generated by backing up the block data through the data node is directly used for data synchronization of the target node, so that the time required by data synchronization of the target node is greatly reduced. On the other hand, the data snapshots with the same block height are acquired from different data nodes to restore the acquired data snapshots, so that the block data corresponding to the data snapshots for data synchronization of the target node can be ensured to be complete and correct. Meanwhile, the target only needs to synchronize the block data of other block heights except all the blocks corresponding to the data snapshots, node data synchronization can be completed quickly, and the applicability is high.
Referring to fig. 8, fig. 8 is a schematic structural diagram of an apparatus provided in an embodiment of the present application. As shown in fig. 8, the apparatus 1000 in the present embodiment may include: the processor 1001, the network interface 1004, and the memory 1005, and the apparatus 1000 may further include: a user interface 1003, and at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display) and a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a standard wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory (e.g., at least one disk memory). The memory 1005 may optionally be at least one memory device located remotely from the processor 1001. As shown in fig. 8, a memory 1005, which is a kind of computer-readable storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.
In the device 1000 shown in fig. 8, the network interface 1004 may provide network communication functions; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:
acquiring a first data snapshot from a first data node, wherein each data node performs one backup on block data of all blocks of a block chain to obtain a data snapshot when a preset number of blocks are added to the block chain, and the first data snapshot is a data snapshot generated when the first data node performs the last backup at a distance from the current moment;
acquiring a second data snapshot from a second data node, wherein the second data snapshot is a data snapshot generated when the second data node is backed up for the last time from the current moment;
matching the first data snapshot with the second data snapshot, if the first data snapshot is inconsistent with the second data snapshot, acquiring a data state log of a target block from the block chain, and performing data recovery on the first data snapshot according to the data state log to obtain a third data snapshot, wherein the target block is a block with the highest block height in all blocks corresponding to the first data snapshot;
storing the first block data of all blocks corresponding to the third data snapshot to a target node;
and acquiring second block data of other blocks except all blocks corresponding to the third data snapshot from the first data node, and synchronizing the second block data to the target node.
In some possible embodiments, the processor 1001 is configured to:
determining transaction data, contract data and account data of the target block according to the data state log;
and updating the block data of the target block according to the transaction data, the contract data and the account data to obtain a third data snapshot.
In some possible embodiments, the processor 1001 is further configured to:
acquiring second transaction data, second contract data and second account data of the target block from the target block of the block chain;
matching the first transaction data, the first contract data, and the second account data with the second transaction data, the second contract data, and the second account data, respectively;
and updating the block data of the target block if the first transaction data is identical to the second transaction data, the first contract data is identical to the second contract data, and the first account data is identical to the second account data.
In some possible embodiments, the processor 1001 is further configured to:
acquiring first Merck tree roots of all blocks corresponding to the third data snapshot according to the first block data;
acquiring second merkel tree roots of all blocks corresponding to the third data snapshot from the block chain;
and matching the first Merck tree root with the second Merck tree root, and if each first Merck tree root is consistent with the corresponding second Merck tree root, executing a step of storing the first block data of all blocks corresponding to the third data snapshot to a target node.
In some possible embodiments, the processor 1001 is further configured to:
if the first data snapshot is inconsistent with the second data snapshot, acquiring third block data of other blocks except the target block in all blocks corresponding to the first data snapshot;
acquiring fourth block data of the target block from the target block of the block chain;
and storing the third block data and the fourth block data to the target node.
In some possible embodiments, the processor 1001 is configured to:
sending the second block data to a common node so that the common node verifies the second block data according to the block data of other data nodes except the first data node;
and acquiring a verification result of each consensus node, and storing the second block data to the target node when all the verification results meet a preset consensus strategy.
In some possible embodiments, the processor 1001 is further configured to:
determining whether a third data node exists in the block chain, wherein the highest block height corresponding to the third data node is higher than the highest block height corresponding to the target node;
and if the third data node exists in the block chain, acquiring fifth block data of a block corresponding to a target block height interval from the third data node, and synchronizing the fifth block data to the target node, wherein the target block height interval is a block height interval from the highest block height corresponding to the target node to the highest block height corresponding to the third data node.
It should be understood that in some possible embodiments, the processor 1001 may be a Central Processing Unit (CPU), and the processor may be other general purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The memory may include both read-only memory and random access memory, and provides instructions and data to the processor. The portion of memory may also include non-volatile random access memory. For example, the memory may also store device type information.
In a specific implementation, the device 1000 may execute, through each built-in functional module thereof, the implementation manners provided in the steps in fig. 2, fig. 5, and fig. 6, which may be referred to specifically for the implementation manners provided in the steps, and are not described herein again.
In the embodiment of the application, the data snapshot generated by backing up the block data through the data node is directly used for data synchronization of the target node, so that the time required by data synchronization of the target node is greatly reduced. On the other hand, the data snapshots with the same block height are acquired from different data nodes to restore the acquired data snapshots, so that the block data corresponding to the data snapshots for data synchronization of the target node can be ensured to be complete and correct. Meanwhile, the target only needs to synchronize the block data of other block heights except all the blocks corresponding to the data snapshots, node data synchronization can be completed quickly, and the applicability is high.
An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and is executed by a processor to implement the methods provided in the steps in fig. 2, fig. 5, and fig. 6, which may specifically refer to implementation manners provided in the steps, and are not described herein again.
The computer readable storage medium may be an internal storage unit of the task processing device provided in any of the foregoing embodiments, for example, a hard disk or a memory of an electronic device. The computer readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, a Smart Memory Card (SMC), a Secure Digital (SD) card, a flash card (flash card), and the like, which are provided on the electronic device. The computer readable storage medium may further include a magnetic disk, an optical disk, a read-only memory (ROM), a Random Access Memory (RAM), and the like. Further, the computer readable storage medium may also include both an internal storage unit and an external storage device of the electronic device. The computer-readable storage medium is used for storing the computer program and other programs and data required by the electronic device. The computer readable storage medium may also be used to temporarily store data that has been output or is to be output.
The terms "first", "second", and the like in the claims and in the description and drawings of the present application are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus. Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments. The term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.
Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.
Claims (10)
1. A method for node data synchronization, the method comprising:
the method comprises the steps that a first data snapshot is obtained from a first data node, wherein each data node performs one backup on block data of all blocks of a block chain to obtain the data snapshot when a preset number of blocks are added to the block chain, and the first data snapshot is a data snapshot generated when the first data node performs the last backup at a distance from the current moment;
acquiring a second data snapshot from a second data node, wherein the second data snapshot is a data snapshot generated when the second data node is backed up for the last time from the current moment;
matching the first data snapshot with the second data snapshot, if the first data snapshot is inconsistent with the second data snapshot, acquiring a data state log of a target block from the block chain, and performing data recovery on the first data snapshot according to the data state log to obtain a third data snapshot, wherein the target block is a block with the highest block height in all blocks corresponding to the first data snapshot;
storing first block data of all blocks corresponding to the third data snapshot to a target node;
and acquiring second block data of other blocks except all blocks corresponding to the third data snapshot from the first data node, and synchronizing the second block data to the target node.
2. The method of claim 1, wherein the recovering the first data snapshot from the data state log to obtain a third data snapshot comprises:
determining transaction data, contract data and account data of the target block according to the data state log;
and updating the block data of the target block according to the transaction data, the contract data and the account data to obtain a third data snapshot.
3. The method of claim 2, further comprising:
acquiring second transaction data, second contract data and second account data of a target block from the target block of the block chain;
matching the transaction data, the contract data, and the second account data with the second transaction data, the second contract data, and the second account data, respectively;
and if the transaction data is consistent with the second transaction data, the contract data is consistent with the second contract data, and the first account data is consistent with the second account data, executing the step of updating the block data of the target block.
4. The method of claim 1, further comprising:
acquiring first Merck tree roots of all blocks corresponding to the third data snapshot according to the first block data;
acquiring second Merck tree roots of all blocks corresponding to the third data snapshot from the block chain;
and matching the first Mercker tree roots with the second Mercker tree roots, and if each first Mercker tree root is consistent with the corresponding second Mercker tree root, executing a step of storing the first block data of all blocks corresponding to the third data snapshot to a target node.
5. The method of claim 1, further comprising:
if the first data snapshot is inconsistent with the second data snapshot, acquiring third block data of other blocks except the target block in all blocks corresponding to the first data snapshot;
acquiring fourth block data of a target block from the target block of the block chain;
storing the third block data and the fourth block data to the target node.
6. The method of claim 1, wherein the synchronizing the second block of data to the target node comprises:
sending the second block data to a common identification node so that the common identification node verifies the second block data according to the block data of other data nodes except the first data node;
and acquiring a verification result of each consensus node, and storing the second block data to the target node when all the verification results meet a preset consensus strategy.
7. The method of claim 1, further comprising:
determining whether a third data node exists in the block chain, wherein the highest block height corresponding to the third data node is higher than the highest block height corresponding to the target node;
if the third data node exists in the block chain, acquiring fifth block data of a block corresponding to a target block height interval from the third data node, and synchronizing the fifth block data to the target node, wherein the target block height interval is a block height interval from the highest block height corresponding to the target node to the highest block height corresponding to the third data node.
8. A node data synchronization apparatus, the apparatus comprising:
the first obtaining module is used for obtaining a first data snapshot from a first data node, wherein each data node performs one backup on block data of all blocks of a block chain to obtain the data snapshot when a preset number of blocks are added to the block chain, and the first data snapshot is a data snapshot generated when the first data node performs the last backup at a distance from the current moment;
the second obtaining module is used for obtaining a second data snapshot from a second data node, wherein the second data snapshot is a data snapshot generated when the second data node is backed up for the last time from the current moment;
the first processing module is configured to match the first data snapshot with the second data snapshot, obtain a data state log of a target block from the block chain if the first data snapshot is inconsistent with the second data snapshot, and perform data recovery on the first data snapshot according to the data state log to obtain a third data snapshot, where the target block is a block with a highest block height in all blocks corresponding to the first data snapshot;
a first synchronization module, configured to store first block data of all blocks corresponding to the third data snapshot to a target node;
a second synchronization module, configured to obtain, from the first data node, second block data of other blocks except all blocks corresponding to the third data snapshot, and synchronize the second block data to the target node.
9. A node data synchronization device, comprising a processor and a memory, the processor and the memory being interconnected;
the memory for storing a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any of claims 1 to 7.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which is executed by a processor to implement the method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010074098.0A CN111209343B (en) | 2020-01-22 | 2020-01-22 | Node data synchronization method, device, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010074098.0A CN111209343B (en) | 2020-01-22 | 2020-01-22 | Node data synchronization method, device, equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111209343A CN111209343A (en) | 2020-05-29 |
| CN111209343B true CN111209343B (en) | 2022-02-22 |
Family
ID=70787639
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010074098.0A Active CN111209343B (en) | 2020-01-22 | 2020-01-22 | Node data synchronization method, device, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111209343B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109636388B (en) * | 2018-12-07 | 2024-02-23 | 深圳市智税链科技有限公司 | Data processing method, device, medium and electronic equipment in block chain network |
| CN112085504B (en) * | 2020-11-16 | 2021-02-09 | 腾讯科技（深圳）有限公司 | Data processing method and device, computer equipment and storage medium |
| CN113326332A (en) * | 2021-06-18 | 2021-08-31 | 深圳前海微众银行股份有限公司 | Snapshot synchronization method and device for block chain |
| CN113378144B (en) * | 2021-07-14 | 2022-09-02 | 湖北央中巨石信息技术有限公司 | Image file consensus method, system, device and medium based on block chain |
| CN115292419B (en) * | 2022-10-09 | 2023-03-31 | 深圳市明源云科技有限公司 | Data processing method, device and equipment based on poH consensus and storage medium |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8516210B2 (en) * | 2011-12-21 | 2013-08-20 | Microsoft Corporation | Application consistent snapshots of a shared volume |
| US9524328B2 (en) * | 2014-12-28 | 2016-12-20 | Strato Scale Ltd. | Recovery synchronization in a distributed storage system |
| CN106815091B (en) * | 2015-11-27 | 2020-02-14 | 成都华为技术有限公司 | Synchronous continuous transmission method, slave end equipment and system |
| CN109145163B (en) * | 2018-08-22 | 2021-08-24 | 深圳前海微众银行股份有限公司 | Block chain data capacity reduction method and device and storage medium |
| CN109636388B (en) * | 2018-12-07 | 2024-02-23 | 深圳市智税链科技有限公司 | Data processing method, device, medium and electronic equipment in block chain network |
-
2020
- 2020-01-22 CN CN202010074098.0A patent/CN111209343B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN111209343A (en) | 2020-05-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111209343B (en) | Node data synchronization method, device, equipment and storage medium | |
| US11611445B2 (en) | Changing smart contracts recorded in block chains | |
| CN110288479B (en) | Method and related equipment for consensus of block chain data | |
| CN110690974B (en) | Block chain based data verification method, device, equipment and readable storage medium | |
| WO2020151323A1 (en) | Data slicing-based data storage method, device, and medium | |
| CN109522363B (en) | Cloud platform synchronization method, system, equipment and storage medium based on block chain | |
| US20210049715A1 (en) | Blockchain-based data procesing method, apparatus, and electronic device | |
| CN108491301B (en) | Electronic device, abnormality early warning method based on redis and storage medium | |
| CN110442473B (en) | Nonvolatile data storage method and device, electronic equipment and medium | |
| CN110570196A (en) | Transaction data processing method and device, terminal equipment and storage medium | |
| CN107861832B (en) | Data verification method and device and readable storage medium | |
| CN110704428A (en) | Data indexing method and device for block chain, computer equipment and storage medium | |
| EP3474143B1 (en) | Method and apparatus for incremental recovery of data | |
| CN112035472A (en) | Data processing method, data processing device, computer equipment and storage medium | |
| CN110543516A (en) | Intelligent contract processing method and device, computer equipment and storage medium | |
| CN109586949B (en) | Block generation method and computer storage medium | |
| KR100922584B1 (en) | Distributed object-sharing system and method thereof | |
| CN111209339B (en) | Block synchronization method, device, computer and storage medium | |
| CN111680104A (en) | Data synchronization method and device, computer equipment and readable storage medium | |
| CN105550071A (en) | System file upgrading and detecting method and communication device | |
| CN108196975B (en) | Data verification method and device based on multiple checksums and storage medium | |
| CN115883533A (en) | File synchronization method and device, computer equipment and storage medium | |
| CN114416874A (en) | Synchronous verification method, device, equipment and storage medium of database | |
| CN111507840B (en) | Block chain consensus method, apparatus, computer and readable storage medium | |
| CN112306527A (en) | Server upgrading method and device, computer equipment 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 |