CN113094437B - Method and system for synchronizing state data of blockchain based on Rsync - Google Patents
Method and system for synchronizing state data of blockchain based on Rsync Download PDFInfo
- Publication number
- CN113094437B CN113094437B CN202110410601.XA CN202110410601A CN113094437B CN 113094437 B CN113094437 B CN 113094437B CN 202110410601 A CN202110410601 A CN 202110410601A CN 113094437 B CN113094437 B CN 113094437B
- Authority
- CN
- China
- Prior art keywords
- check value
- sub
- data
- block
- data block
- 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
- 238000000034 method Methods 0.000 title claims abstract description 36
- 230000001360 synchronised effect Effects 0.000 claims abstract description 25
- 238000012216 screening Methods 0.000 claims abstract description 13
- 230000002159 abnormal effect Effects 0.000 claims description 17
- 238000004364 calculation method Methods 0.000 claims description 9
- 238000005538 encapsulation Methods 0.000 claims description 4
- 230000004044 response Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005096 rolling process Methods 0.000 description 3
- 230000005856 abnormality Effects 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 238000000638 solvent extraction Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
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
- 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/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2255—Hash tables
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a method for synchronizing state data of a blockchain based on Rsync, which encapsulates the state data of all the blocknodes in the blockchain into objects and stores the objects in a message queue, and reads the data of each blocknode from the message queue one by one; based on the block data of each block node, uniformly dividing the block data into a plurality of sub-data blocks according to the size of the data quantity, and numbering the plurality of sub-data blocks; calculating a strong check value and a weak check value of each sub data block based on an Rsync algorithm; inputting the sub data block and the corresponding strong check value and weak check value to the Rsync client; searching corresponding weak check values and strong check values based on a synchronous source file of the Rsync client, and screening sub-data blocks with missing weak check values and/or strong check values; and replacing the sub data block with the missing check value based on the synchronous source file. The problem of unbalanced node load in the block chain data synchronization process is solved, the data synchronization performance in the block network can be improved, and fewer computing resources are required.
Description
Technical Field
The application relates to the technical field of blockchain data synchronization, in particular to a method and a system for synchronizing blockchain state data based on Rsync.
Background
Data synchronization is a very important process in a blockchain and can be functionally divided into traffic synchronization and state synchronization. The existing blockchain state data synchronization method is as follows: the lagging block node needs to download the block from other nodes in a request mode, and the other nodes respond after receiving the request, namely, send missing data to the lagging block node. Since the blockchain contains a plurality of nodes, there are a large number of request-response processes in the existing state data synchronization process, and a large amount of information needs to be transferred in the request-response process, which also means that a large amount of resources need to be consumed. In addition, the request-response process is random, which may result in a large number of requests being received by some nodes and others being idle, resulting in an overall blockchain load imbalance. Under the condition that the data synchronization speed of the block chain nodes is difficult to increase, how to realize state data synchronization among blocks by using a more efficient method solves the problem of unbalanced load in the block chain, which is a main problem to be solved.
Disclosure of Invention
The application provides a method and a system for synchronizing state data of a blockchain based on Rsync, which aim to solve the problems of low synchronization efficiency and unbalanced load in the existing blockchain data synchronizing method.
According to an embodiment of the present application, there is provided an Rsync-based blockchain status data synchronization method, including the steps of: step S1: encapsulating the state data of all block nodes in the block chain as objects and storing the objects in a message queue, and reading the data of each block node from the message queue one by one; step S2: based on the block data of each block node, uniformly dividing the block data into a plurality of sub-data blocks according to the size of the data quantity, and numbering the plurality of sub-data blocks; step S3: calculating a strong check value and a weak check value of each sub data block based on an Rsync algorithm; step S4: inputting the sub data block and the corresponding strong check value and weak check value to the Rsync client; step S5: searching corresponding weak check values and strong check values based on a synchronous source file of the Rsync client, and screening sub-data blocks with missing weak check values and/or strong check values; step S6: and replacing the sub data blocks with missing check values based on the synchronous source file.
Preferably, the step S3 specifically includes: step S31: setting a preset time interval based on the number of sub-data blocks; step S32: sequentially calculating a weak check value and a strong check value of the sub-data block by using an Rsync algorithm according to the preset time interval; step S33: and adding the block number and the sub-data block number to the weak check value and the strong check value calculated by each sub-data block.
Preferably, the step S5 specifically includes: step S51: the synchronous source file receives the calculated check value of each data block and stores the encoded value into a hash table; step S52: searching the weak check value of the sub data block in the hash table, judging whether the weak check value exists in the hash table, if so, entering step S53, and if not, entering step S55; step S53: searching the strong check value of the sub data block in the hash table, judging whether the strong check value exists in the hash table, if so, entering a step S54, and if not, entering a step S55; step S54: judging that the current sub-data block is normal, and entering the next sub-data block; step S55: and judging that the current sub-data block is abnormal, and entering the next sub-data block.
Preferably, step S6 specifically includes the following steps: step S61: based on the judging result, the synchronous source file reads the number corresponding to the sub data block judged to be abnormal; step S62: the abnormal sub data block is replaced with a normal sub data block.
Preferably, in the step S2, the block data of each node is uniformly divided into a plurality of sub-data blocks according to the size of the data volume by using a Checksum algorithm.
The application also provides a system for synchronizing state data of a blockchain based on Rsync, which comprises: the state data encapsulation unit is used for encapsulating the state data of all block nodes in the block chain as objects and storing the objects in the message queue, and reading the data of each block node from the message queue one by one; the data block dividing unit is used for dividing the block data of each block node into a plurality of sub data blocks uniformly according to the size of the data quantity and numbering the plurality of sub data blocks; the check value calculation unit is used for calculating a strong check value and a weak check value of each sub data block based on an Rsync algorithm; the check value input unit is used for inputting the sub data block and the corresponding strong check value and weak check value to the Rsync client; the check value screening unit is used for searching the corresponding weak check value and strong check value based on the synchronous source file of the Rsync client, and screening sub data blocks with missing weak check value and/or strong check value; and the data block updating unit is used for replacing the sub data blocks with the missing check values based on the synchronous source file.
Preferably, the check value calculation unit further includes: a time setting unit for setting a preset time interval based on the number of sub data blocks; the sequence calculating unit is used for sequentially calculating the weak check value and the strong check value of the sub-data block by using an Rsync algorithm according to the preset time interval; and a number adding unit for adding the block number and the sub data block number to the weak check value and the strong check value calculated for each sub data block.
Preferably, the check value screening unit further includes: a check value receiving unit for receiving the calculated check value of each data block based on the synchronous source file, and storing the encoded value in the hash table; the weak check value checking unit is used for searching the weak check value of the sub data block in the hash table; the strong check value checking unit is used for searching the strong check value of the sub data block in the hash table when the weak check value is detected, and judging whether the strong check value exists in the hash table or not; the first sub-data block judging unit is used for judging that the current sub-data block is normal and entering the next sub-data block when the weak check value and the strong check value are searched at the same time; and the second sub-data block judging unit is used for judging that the current sub-data block is abnormal and entering the next sub-data block when the weak check value or the strong check value is not found.
The method and the system for synchronizing the state data of the blockchain based on the Rsync have the following beneficial effects:
the state data is packaged into the message queue to read the data, the block data is divided into a plurality of sub-data blocks, the state information in one block is divided into a plurality of small sub-data blocks, subsequent operations such as encoding and data transmission are facilitated, the problem that one node in the block chain receives a plurality of downloading requests is solved, the problem of unbalanced node load in the block chain data synchronization process is solved, and the speed and efficiency of data synchronization are improved. Meanwhile, the Rsync algorithm is adopted to calculate check values and synchronize information of sub data blocks in the block nodes, multiple requests and responses are not needed among the nodes in the process of node data synchronization, and replacement of different information blocks is completed only by judging the check values of the nodes, so that the performance of data synchronization in a block network can be improved, and fewer calculation resources are needed.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a flowchart of a method for synchronizing state data of a blockchain based on Rsync according to a first embodiment of the present application.
Fig. 2 is a flowchart of step S3 in a method for synchronizing state data of a blockchain based on Rsync according to the first embodiment of the present application.
Fig. 3 is a flowchart of step S5 in a method for synchronizing state data of a blockchain based on Rsync according to the first embodiment of the present application.
Fig. 4 is a flowchart of step S6 in a method for synchronizing state data of a blockchain based on Rsync according to the first embodiment of the present application.
Fig. 5 is a block diagram of an Rsync-based blockchain status data synchronization system according to a second embodiment of the present application.
Fig. 6 is a block diagram of a check value calculation unit in an Rsync-based blockchain status data synchronization system according to a second embodiment of the present application.
Fig. 7 is a block diagram of a check value filtering unit in an Rsync-based blockchain status data synchronization system according to a second embodiment of the present application.
Fig. 8 is a block diagram of an electronic device according to a third embodiment of the present application.
Description of the reference numerals:
1. a state data encapsulation unit; 2. a data block unit; 3. a check value calculation unit; 4. a check value input unit; 5. a check value screening unit; 6. a data block updating unit;
31. a time setting unit; 32. a sequence calculating unit; 33. a number adding unit; 51. a check value receiving unit; 52. a weak check value checking unit; 53. a strong check value checking unit; 54. a first sub data block determination unit; 55. a second sub data block determination unit;
10. a memory; 20. a processor.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
It is also to be understood that the terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.
It should be further understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
Referring to fig. 1, a first embodiment of the present application discloses a method for synchronizing state data of a blockchain based on Rsync, comprising the steps of:
step S1: encapsulating the state data of all block nodes in the block chain as objects and storing the objects in a message queue, and reading the data of each block node from the message queue one by one;
step S2: based on the block data of each block node, uniformly dividing the block data into a plurality of sub-data blocks according to the size of the data quantity, and numbering the plurality of sub-data blocks;
step S3: calculating a strong check value and a weak check value of each sub data block based on an Rsync algorithm;
step S4: inputting the sub data block and the corresponding strong check value and weak check value to the Rsync client;
step S5: searching corresponding weak check values and strong check values based on a synchronous source file of the Rsync client, and screening sub-data blocks with missing weak check values and/or strong check values; and
Step S6: and replacing the sub data blocks with missing check values based on the synchronous source file.
It will be appreciated that in step S1, to ensure standardization of data, the data is sent to the destination reliably and accurately during synchronization of the data, and the subsequent processing is performed in combination with the status data.
It will be appreciated that in step S2, the block data of each node may be uniformly divided into a plurality of sub-data blocks according to the size of the data amount based on the Checksum algorithm, and different sub-data blocks in the node are numbered. The number of the sub data blocks can be set and divided according to the requirements of users.
It will be appreciated that in step S3, the weak check value and the strong check value corresponding to each sub-data block are calculated separately.
It can be appreciated that in step S4, the Rsync client may be installed in the server in advance, and service configuration, setting, and testing of the synchronization source file of the server may be performed after the installation is confirmed.
It can be understood that in step S5, based on the synchronous source file, a plurality of sub-data blocks after existing partitioning are sequentially searched in the synchronous source file, and whether the current sub-data block is a normal data block is determined based on checking of the strength check value, and the abnormal data block is usually caused by the problems of data lack of synchronization, data missing, and the like.
It will be understood that in step S6, the sub data block determined to be abnormal is replaced, and the data in the source file is updated to the sub data block, so that the abnormal sub data block is updated.
It can be understood that by encapsulating the status data into the message queue to read the data and dividing the block data into a plurality of sub-data blocks, the status information in one block is divided into a plurality of small sub-data blocks, which is beneficial to subsequent operations such as encoding, data transmission, etc., which solves the problem of unbalanced node load in the process of synchronizing the block chain data and improves the speed of data synchronization. Meanwhile, the Rsync algorithm is adopted to calculate the check value and synchronize the information of the sub data blocks in the block nodes, and only the information blocks with different check values are replaced, so that the data synchronization performance in the block network can be improved.
The application combines the new field of researching mature Rsync algorithm and blockchain state data synchronization, and establishes a blockchain state data synchronization method based on the Rsync algorithm. The prior blockchain data synchronization is mainly improved from the perspective of transaction data, and a synchronization method for the state data of the nodes is not available.
Referring to fig. 2, the step S3 specifically includes:
step S31: setting a preset time interval based on the number of sub-data blocks;
step S32: sequentially calculating a weak check value and a strong check value of the sub-data block by using an Rsync algorithm according to the preset time interval; and
Step S33: and adding the block number and the sub-data block number to the weak check value and the strong check value calculated by each sub-data block.
It will be appreciated that in step S31, the preset time interval is increased based on the increase in the number of sub-data blocks, so as to facilitate accurate calculation for a plurality of sub-data blocks.
It will be appreciated that in step S32, the weak parity value rolling check sum of the data block is rapidly calculated by using the adler-32 rolling check algorithm, which is 32bits in total, whereinRepresenting data block->Rolling check value of (2).
。
Calculating a strong check value: the strong checksum of the data block is calculated by adopting an md5 hash algorithm, 128bits is total, and the specific steps are as follows: MD5 processes the incoming information in 512-bit packets, and each packet is divided into 16 32-bit sub-packets, after a series of processing, the output of the algorithm consists of four 32-bit packets, which are concatenated to generate a 128-bit hash value. By adopting the algorithm, the sub data block of each block can obtain a strong check value and a weak check value through an Rsync algorithm.
It should be understood that steps S31 to S33 are only one implementation of this embodiment, and implementation thereof is not limited to steps S31 to S33.
Referring to fig. 3, the step S5 specifically includes:
step S51: the synchronous source file receives the calculated check value of each data block and stores the encoded value into a hash table;
step S52: searching the weak check value of the sub data block in the hash table, judging whether the weak check value exists in the hash table, if so, entering step S53, and if not, entering step S55;
step S53: searching the strong check value of the sub data block in the hash table, judging whether the strong check value exists in the hash table, if so, entering a step S54, and if not, entering a step S55;
step S54: judging that the current sub-data block is normal, and entering the next sub-data block; and
Step S55: and judging that the current sub-data block is abnormal, and entering the next sub-data block.
It will be appreciated that in step S51, the synchronization source file is written in the Rsync client for performing data synchronization operations, including: transmitting and receiving user check values, comparing check values, judging check values and replacing data blocks.
It will be appreciated that in step S54, only if the weak check value and the strong check value of the sub data block are both checked to be correct, the normal data block can be determined, otherwise the abnormal data block can be determined.
It should be understood that steps S51 to S55 are only one implementation of this embodiment, and implementation thereof is not limited to steps S51 to S55.
Referring to fig. 4, the step S6 specifically includes the following steps:
step S61: based on the judging result, the synchronous source file reads the number corresponding to the sub data block judged to be abnormal; and
Step S62: the abnormal sub data block is replaced with a normal sub data block.
It will be understood that in step S61, the synchronization source file has real-time updated data, and when an abnormality occurs in the data, the position of the sub-data block can be quickly located based on the number corresponding to the sub-data block of the abnormality (i.e. the data that is not updated), and the abnormal sub-data block is replaced with the correct sub-data block, so as to complete the update of the data.
Referring to fig. 5, a second embodiment of the present application improves an Rsync-based blockchain status data synchronization system, comprising:
a state data encapsulation unit 1, configured to encapsulate state data of all block nodes in a blockchain as objects and store the objects in a message queue, and read data of each block node from the message queue one by one;
a data partitioning unit 2, configured to uniformly partition the data into a plurality of sub-data blocks according to the size of the data amount based on the block data of each block node, and number the plurality of sub-data blocks;
a check value calculating unit 3, configured to calculate a strong check value and a weak check value of each sub data block based on an Rsync algorithm;
a check value input unit 4, configured to input the sub data block and the corresponding strong check value and weak check value to the Rsync client;
the check value screening unit 5 is used for searching the corresponding weak check value and strong check value based on the synchronous source file of the Rsync client, and screening the sub-data blocks with the missing weak check value and/or strong check value;
and the data block updating unit 6 is used for replacing the sub data block with the missing check value based on the synchronous source file.
Referring to fig. 6, the check value calculating unit 3 specifically includes:
a time setting unit 31 for setting a preset time interval based on the number of sub data blocks;
a sequence calculating unit 32, configured to sequentially calculate a weak check value and a strong check value of the sub-data block using an Rsync algorithm according to the preset time interval; and
A number adding unit 33 for adding the weak check value and the strong check value calculated for each sub data block to the block number and the sub data block number.
Referring to fig. 7, the check value filtering unit 5 further includes:
a check value receiving unit 51 for receiving the calculated check values of the respective data blocks based on the synchronous source file, and storing the encoded values in a hash table;
a weak check value checking unit 52, configured to search the weak check value of the sub data block in the hash table;
a strong check value checking unit 53, configured to search the strong check value of the sub data block in the hash table when the weak check value is found, and determine whether the strong check value exists in the hash table;
a first sub-data block determining unit 54, configured to determine that the current sub-data block is normal and enter the next sub-data block when the weak check value and the strong check value are found at the same time;
and a second sub data block determination unit 55, configured to determine that the current sub data block is abnormal and enter the next sub data block when the weak check value or the strong check value is not found.
Referring to fig. 8, a third embodiment of the present application provides an electronic device, including a memory 10 and a processor 20, where the memory 10 stores an operator program configured to perform, when running, the steps of any of the embodiments of the Rsync-based blockchain status data synchronization method described above. The processor 20 is arranged to perform the steps of any of the above-described Rsync-based blockchain status data synchronization method embodiments by the operator program.
Alternatively, in this embodiment, the electronic device may be located in at least one network device of a plurality of network devices of the computing machine network.
The method and the system for synchronizing the state data of the blockchain based on the Rsync have the following beneficial effects:
the state data is packaged into the message queue to read the data, the block data is divided into a plurality of sub-data blocks, the state information in one block is divided into a plurality of small sub-data blocks, subsequent operations such as encoding and data transmission are facilitated, the problem that one node in the block chain receives a plurality of downloading requests is solved, the problem of unbalanced node load in the block chain data synchronization process is solved, and the speed and efficiency of data synchronization are improved. Meanwhile, the Rsync algorithm is adopted to calculate check values and synchronize information of sub data blocks in the block nodes, multiple requests and responses are not needed among the nodes in the process of node data synchronization, and replacement of different information blocks is completed only by judging the check values of the nodes, so that the performance of data synchronization in a block network can be improved, and fewer calculation resources are needed.
While the application has been described with reference to certain preferred embodiments, it will be understood by those skilled in the art that various changes and substitutions of equivalents may be made and equivalents will be apparent to those skilled in the art without departing from the scope of the application. Therefore, the protection scope of the application is subject to the protection scope of the claims.
Claims (5)
1. The method for synchronizing the state data of the blockchain based on the Rsync is characterized by comprising the following steps:
step S1: encapsulating the state data of all block nodes in the block chain as objects and storing the objects in a message queue, and reading the data of each block node from the message queue one by one;
step S2: based on the state data of each block node, uniformly dividing the state data into a plurality of sub-data blocks according to the size of the data quantity, and numbering the plurality of sub-data blocks;
step S3: calculating a strong check value and a weak check value of each sub data block based on an Rsync algorithm;
step S4: inputting the sub data block and the corresponding strong check value and weak check value to the Rsync client;
step S5: searching corresponding weak check values and strong check values based on a synchronous source file of the Rsync client, and screening sub-data blocks with missing weak check values and/or strong check values; and
Step S6: replacing the sub data blocks with missing weak check values and/or strong check values based on the synchronous source file;
the step S5 specifically includes:
step S51: the synchronous source file receives the strong check value and the weak check value of each sub data block, and stores the check values into a hash table;
step S52: searching the weak check value of the sub data block in the hash table, judging whether the weak check value exists in the hash table, if so, entering step S53, and if not, entering step S55;
step S53: searching the strong check value of the sub data block in the hash table, judging whether the strong check value exists in the hash table, if so, entering a step S54, and if not, entering a step S55;
step S54: judging that the current sub-data block is normal, and entering the next sub-data block; and
Step S55: and judging that the current sub-data block is abnormal, and entering the next sub-data block.
2. The Rsync-based blockchain status data synchronization method of claim 1, wherein: the step S3 specifically includes:
step S31: setting a preset time interval based on the number of sub-data blocks;
step S32: sequentially calculating a weak check value and a strong check value of the sub-data block by using an Rsync algorithm according to the preset time interval; and
Step S33: and adding the block number and the sub-data block number to the weak check value and the strong check value calculated by each sub-data block.
3. The Rsync-based blockchain status data synchronization method of claim 1, wherein: the step S6 specifically comprises the following steps:
step S61: based on the judging result, the synchronous source file reads the number corresponding to the sub data block judged to be abnormal; and
Step S62: the abnormal sub data block is replaced with a normal sub data block.
4. The Rsync-based blockchain status data synchronization method of claim 1, wherein: in the step S2, the Checksum algorithm is adopted to uniformly divide the state data of each node into a plurality of sub-data blocks according to the data size.
5. A Rsync-based blockchain status data synchronization system, characterized by: comprising the following steps:
the state data encapsulation unit is used for encapsulating the state data of all block nodes in the block chain as objects and storing the objects in the message queue, and reading the data of each block node from the message queue one by one;
the data block dividing unit is used for uniformly dividing the data block into a plurality of sub data blocks according to the size of the data volume based on the state data of each block node, and numbering the plurality of sub data blocks;
the check value calculation unit is used for calculating a strong check value and a weak check value of each sub data block based on an Rsync algorithm;
the check value input unit is used for inputting the sub data block and the corresponding strong check value and weak check value to the Rsync client;
the check value screening unit is used for searching the corresponding weak check value and strong check value based on the synchronous source file of the Rsync client, and screening sub data blocks with missing weak check value and/or strong check value;
the data block updating unit is used for replacing the sub data blocks with the missing check values based on the synchronous source file;
the check value calculation unit further includes:
a time setting unit for setting a preset time interval based on the number of sub data blocks;
the sequence calculating unit is used for sequentially calculating the weak check value and the strong check value of the sub-data block by using an Rsync algorithm according to the preset time interval; and
The number adding unit is used for adding the block number and the sub-data block number to the weak check value and the strong check value calculated by each sub-data block;
the check value screening unit further includes:
the check value receiving unit is used for receiving the strong check value and the weak check value of each sub data block based on the synchronous source file and storing the check values into the hash table;
the weak check value checking unit is used for searching the weak check value of the sub data block in the hash table;
the strong check value checking unit is used for searching the strong check value of the sub data block in the hash table when the weak check value is detected, and judging whether the strong check value exists in the hash table or not;
the first sub-data block judging unit is used for judging that the current sub-data block is normal and entering the next sub-data block when the weak check value and the strong check value are searched at the same time;
and the second sub-data block judging unit is used for judging that the current sub-data block is abnormal and entering the next sub-data block when the weak check value or the strong check value is not found.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110410601.XA CN113094437B (en) | 2021-04-14 | 2021-04-14 | Method and system for synchronizing state data of blockchain based on Rsync |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110410601.XA CN113094437B (en) | 2021-04-14 | 2021-04-14 | Method and system for synchronizing state data of blockchain based on Rsync |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113094437A CN113094437A (en) | 2021-07-09 |
| CN113094437B true CN113094437B (en) | 2023-10-03 |
Family
ID=76678776
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110410601.XA Active CN113094437B (en) | 2021-04-14 | 2021-04-14 | Method and system for synchronizing state data of blockchain based on Rsync |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113094437B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113630445B (en) * | 2021-07-19 | 2022-10-14 | 山东区块链研究院 | Data storage method and device based on block chain network |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009230523A (en) * | 2008-03-24 | 2009-10-08 | Nippon Hoso Kyokai <Nhk> | File synchronizing device, file synchronizing method, and file synchronizing program |
| CN102065098A (en) * | 2010-12-31 | 2011-05-18 | 网宿科技股份有限公司 | Method and system for synchronizing data among network nodes |
| CN103428242A (en) * | 2012-05-18 | 2013-12-04 | 阿里巴巴集团控股有限公司 | Method, device and system for increment synchronization |
| CN104023085A (en) * | 2014-06-25 | 2014-09-03 | 武汉大学 | Security cloud storage system based on increment synchronization |
| CN106528125A (en) * | 2016-10-26 | 2017-03-22 | 腾讯科技（深圳）有限公司 | Data file incremental updating method, server, client and system |
| CN107124444A (en) * | 2017-03-28 | 2017-09-01 | 上海瑞麒维网络科技有限公司 | A kind of method and apparatus of block chain data syn-chronization |
| CN108762798A (en) * | 2017-04-25 | 2018-11-06 | 腾讯科技（深圳）有限公司 | A kind of method and device of incremental update file |
| CN110569305A (en) * | 2019-08-27 | 2019-12-13 | 网易（杭州）网络有限公司 | Block synchronization method, device, medium and computing equipment |
| CN111259072A (en) * | 2020-01-08 | 2020-06-09 | 广州虎牙科技有限公司 | Data synchronization method and device, electronic equipment and computer readable storage medium |
| CN111651421A (en) * | 2020-06-05 | 2020-09-11 | 南方电网科学研究院有限责任公司 | Improved Rsync method, device and information synchronization system |
| CN112383610A (en) * | 2020-11-11 | 2021-02-19 | 上海保险交易所股份有限公司 | Synchronous processing method and system for block chain state data |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11080144B2 (en) * | 2019-01-25 | 2021-08-03 | Coinbase, Inc. | System and method for managing blockchain nodes |
| US10839377B2 (en) * | 2019-01-25 | 2020-11-17 | Coinbase, Inc. | Syncing blockchain nodes with snapshots |
| US10956444B2 (en) * | 2019-07-31 | 2021-03-23 | Advanced New Technologies Co., Ltd. | Block chain state data synchronization method, apparatus, and electronic device |
-
2021
- 2021-04-14 CN CN202110410601.XA patent/CN113094437B/en active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009230523A (en) * | 2008-03-24 | 2009-10-08 | Nippon Hoso Kyokai <Nhk> | File synchronizing device, file synchronizing method, and file synchronizing program |
| CN102065098A (en) * | 2010-12-31 | 2011-05-18 | 网宿科技股份有限公司 | Method and system for synchronizing data among network nodes |
| CN103428242A (en) * | 2012-05-18 | 2013-12-04 | 阿里巴巴集团控股有限公司 | Method, device and system for increment synchronization |
| CN104023085A (en) * | 2014-06-25 | 2014-09-03 | 武汉大学 | Security cloud storage system based on increment synchronization |
| CN106528125A (en) * | 2016-10-26 | 2017-03-22 | 腾讯科技（深圳）有限公司 | Data file incremental updating method, server, client and system |
| CN107124444A (en) * | 2017-03-28 | 2017-09-01 | 上海瑞麒维网络科技有限公司 | A kind of method and apparatus of block chain data syn-chronization |
| CN108762798A (en) * | 2017-04-25 | 2018-11-06 | 腾讯科技（深圳）有限公司 | A kind of method and device of incremental update file |
| CN110569305A (en) * | 2019-08-27 | 2019-12-13 | 网易（杭州）网络有限公司 | Block synchronization method, device, medium and computing equipment |
| CN111259072A (en) * | 2020-01-08 | 2020-06-09 | 广州虎牙科技有限公司 | Data synchronization method and device, electronic equipment and computer readable storage medium |
| CN111651421A (en) * | 2020-06-05 | 2020-09-11 | 南方电网科学研究院有限责任公司 | Improved Rsync method, device and information synchronization system |
| CN112383610A (en) * | 2020-11-11 | 2021-02-19 | 上海保险交易所股份有限公司 | Synchronous processing method and system for block chain state data |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113094437A (en) | 2021-07-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109831487B (en) | Fragmented file verification method and terminal equipment | |
| CN101409706B (en) | Method, system and relevant equipment for distributing data of edge network | |
| CN107295036B (en) | Data sending method and data merging equipment | |
| CN110995513B (en) | Data sending and receiving method in Internet of things system, internet of things equipment and platform | |
| CN105634977B (en) | It was found that the method and apparatus of Path Maximum Transmission Unit | |
| CN108366001B (en) | Forwarding test method and device | |
| CN105939201A (en) | Method and device for checking state of server | |
| CN113094437B (en) | Method and system for synchronizing state data of blockchain based on Rsync | |
| CN108243146B (en) | Information submitting method | |
| WO2014032553A1 (en) | Network resource management method and device, client and system | |
| CN115150333B (en) | Congestion control method, congestion control device, computer equipment and storage medium | |
| Yasin et al. | Gossip routing protocol for forest fire detection using wireless sensor networks | |
| CN114884730B (en) | Request detection method, device, equipment and readable storage medium | |
| CN113783751B (en) | Method, electronic device and medium for detecting user broadband quality | |
| CN111953671B (en) | Dynamic honey net data processing method and system based on block chain | |
| CN109495319A (en) | The fault message of CDN node determines method, device and equipment | |
| CN109617779A (en) | Routing table maintenance method and device based on VTEP | |
| US10992702B2 (en) | Detecting malware on SPDY connections | |
| CN108334424B (en) | Method for filtering redundant data of network communication management platform based on LPWAN technology | |
| Kang et al. | Blockchain-based high-reliability recovery and verification mechanism for power data storage nodes | |
| CN117692149B (en) | Method, equipment and medium for checking integrity of log transparent entity | |
| CN109002296A (en) | A kind of method for downloading software, device and base station | |
| CN114745415B (en) | Vehicle service communication data processing method, device, equipment and storage medium | |
| CN113497813B (en) | Content refreshing method and device for content distribution network and electronic equipment | |
| CN117539649B (en) | Identification management method, equipment and readable storage medium of distributed cluster |
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 |