CN109918261B - Fault monitoring method, device, equipment and computer readable storage medium - Google Patents
Fault monitoring method, device, equipment and computer readable storage medium Download PDFInfo
- Publication number
- CN109918261B CN109918261B CN201910073686.XA CN201910073686A CN109918261B CN 109918261 B CN109918261 B CN 109918261B CN 201910073686 A CN201910073686 A CN 201910073686A CN 109918261 B CN109918261 B CN 109918261B
- Authority
- CN
- China
- Prior art keywords
- view
- timestamp
- preset
- node
- request
- 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
Abstract
The invention provides a fault monitoring method, a fault monitoring device, fault monitoring equipment and a computer readable storage medium, wherein the method comprises the following steps: judging whether the current main node fails according to the adding condition of the new block; if so, sending a view replacing request to the timestamp server, wherein the view replacing request comprises the fault information of the main node; receiving a view replacement request including a timestamp and fed back by a timestamp server, and broadcasting the view replacement request including the timestamp into a block chain, wherein the view replacement request including the timestamp is fed back after the timestamp server verifies that the view replacement request is legal; determining whether the number of received view replacement requests including a time stamp exceeds a preset first threshold; if so, judging whether the block chain agrees with the view replacement request comprising the timestamp according to a preset judgment rule; if so, the preset standby node is set as the current main node, so that the state of the main node can be determined in time, and the view can be switched in time under the condition of failure.
Description
Technical Field
The present invention relates to the field of block chains, and in particular, to a method, an apparatus, a device, and a computer-readable storage medium for fault monitoring.
Background
The Blockchain (Blockchain) is an important concept of bitcoin, is essentially a decentralized database, and simultaneously serves as the underlying technology of bitcoin to record all transaction records. The block chain is a series of data blocks which are associated by using a cryptographic method, and each data block contains information of one bitcoin network transaction, so that the validity (anti-counterfeiting) of the information is verified and the next block is generated. The blockchain is public on the network and can be queried in each offline bitcoin wallet data. The function of a bitcoin wallet relies on an acknowledgment with a blockchain, a valid check being called an acknowledgment. Typically, several confirmations are obtained for a transaction.
Since the header of each block contains the transaction information compression value of the previous block, a long chain is formed by connecting the created block (the first block) to the current block. Since there is no way to generate the current tile if the "trade shadow" value of the previous tile is not known, each tile must follow the previous tile in chronological order. This structure of all blocks containing references to previous blocks allows existing sets of blocks to form a long chain of data. Starting from the first chunk, the blockchain stores all the historical data of the system, until the most recently generated chunk. The block chain provides the searching function of each data in the database. Each piece of transaction data on the block chain can be traced through the structure of the block chain, and the verification can be carried out in one stroke. Block + chain = timestamp, which is the most innovative point of a blockchain database. The block chain database enables the recorder of the whole network to record by covering a time stamp in each block, which indicates that the information is written at the time, and forms a non-falsifiable and non-counterfeitable database.
However, when the new block is generated in the above manner, it is often impossible to determine whether a master node in the block chain fails, and if the current master node fails, the block generation in the entire block chain network is affected.
Disclosure of Invention
The invention provides a fault monitoring method, a fault monitoring device, fault monitoring equipment and a computer readable storage medium, which are used for solving the technical problem that whether a main node fails or not can not be judged in the process of generating a new block by using the existing block chain.
The first aspect of the present invention provides a fault monitoring method, including:
judging whether the current main node fails according to the adding condition of the new block;
if so, sending a view replacing request to a timestamp server, wherein the view replacing request comprises fault information of the main node;
receiving a view replacement request including a timestamp fed back by a timestamp server, and broadcasting the view replacement request including the timestamp into a blockchain, wherein the view replacement request including the timestamp is fed back after the view replacement request is verified to be legal by the timestamp server;
determining whether the number of received view replacement requests including a time stamp exceeds a preset first threshold;
if so, judging whether the block chain agrees with the view replacement request comprising the timestamp according to a preset judgment rule;
if yes, setting the preset standby node as the current main node.
Another aspect of the present invention is to provide a fault monitoring apparatus, including:
the first judgment module is used for judging whether the current main node fails according to the adding condition of the new block;
a sending module, configured to send a view change request to a timestamp server if the view change request includes the fault information of the master node;
the view replacing module is used for receiving a view replacing request which comprises a timestamp and is fed back by the timestamp server, broadcasting the view replacing request which comprises the timestamp into the block chain, wherein the view replacing request which comprises the timestamp is fed back after the view replacing request is verified to be legal by the timestamp server;
a determining module, configured to determine whether the number of received view replacement requests including a timestamp exceeds a preset first threshold;
the second judgment module is used for judging whether the block chain agrees with the view replacement request comprising the timestamp according to a preset judgment rule if the view replacement request comprises the timestamp;
and the setting module is used for setting the preset standby node as the current main node if the preset standby node is the current main node.
Yet another aspect of the present invention is to provide a fault monitoring apparatus, including: a memory, a processor;
a memory; a memory for storing the processor-executable instructions;
wherein the processor is configured to perform the fault listening method as described in the first aspect above by the processor.
Yet another aspect of the present invention is to provide a computer-readable storage medium having stored therein computer-executable instructions for implementing the fault listening method as described in the first aspect above when executed by a processor.
The fault monitoring method, the fault monitoring device, the fault monitoring equipment and the computer readable storage medium provided by the invention judge whether the current main node has a fault or not according to the adding condition of the new block; if so, sending a view replacing request to the timestamp server, wherein the view replacing request comprises the fault information of the main node; receiving a view replacement request including a timestamp fed back by a timestamp server, and broadcasting the view replacement request including the timestamp into a blockchain, wherein the view replacement request including the timestamp is fed back after the timestamp server verifies that the view replacement request is legal; determining whether the number of received view replacement requests including a time stamp exceeds a preset first threshold; if so, judging whether the block chain agrees with the view replacement request comprising the timestamp according to a preset judgment rule; if so, the preset standby node is set as the current main node, so that the state of the main node can be determined in time, and the view can be switched in time under the condition of failure.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings can be obtained by those skilled in the art according to the drawings.
FIG. 1 is a schematic diagram of a network architecture on which the present invention is based;
fig. 2 is a schematic flowchart of a fault monitoring method according to an embodiment of the present invention;
fig. 3 is a schematic flowchart of a fault monitoring method according to a third embodiment of the present invention;
fig. 4 is a schematic flowchart of a fault monitoring method according to a third embodiment of the present invention;
fig. 5 is a schematic structural diagram of a fault monitoring apparatus according to a fourth embodiment of the present invention;
fig. 6 is a schematic structural diagram of a fault monitoring device according to a fifth embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other examples obtained based on the examples in the present invention are within the scope of the present invention.
Since the header of each block contains the transaction information compression value of the previous block, a long chain is formed by connecting the created block (the first block) to the current block. Since there is no way to generate the current tile if the "trade shadow" value of the previous tile is not known, each tile must follow the previous tile in chronological order. This structure of all blocks containing the previous block reference allows the existing set of blocks to form a long chain of data. All historical data of the system is stored on the blockchain from the first chunk until the newly generated chunk. The block chain provides the function of searching each data in the database. Each piece of transaction data on the block chain can be traced through the structure of the block chain, and can be verified at one stroke. Blockchain = timestamp, which is the most innovative point of blockchain databases. The block chain database enables the recorder of the whole network to record by covering a time stamp in each block, which indicates that the information is written at the time, and forms a non-falsifiable and non-counterfeitable database. However, when the new block is generated in the above manner, it is often impossible to determine whether a master node in the block chain fails, and if the current master node fails, the block generation in the entire block chain network is affected. In order to solve the technical problem, the invention provides a fault monitoring method, a fault monitoring device, fault monitoring equipment and a computer-readable storage medium.
It should be noted that the fault monitoring method, apparatus, device and computer-readable storage medium provided in the present application may be applied in any scenario of monitoring of block link points.
Fig. 1 is a schematic diagram of a network architecture based on the present invention, and as shown in fig. 1, the network architecture based on the present invention at least includes: at least one node 1 and a timestamp server 2. Wherein, each node 1 is respectively connected with the timestamp server 2 in a communication way, so that the two nodes can carry out information interaction.
Fig. 2 is a schematic flowchart of a fault monitoring method according to an embodiment of the present invention, and as shown in fig. 1, the method includes:
and step 206, if yes, setting the preset standby node as the current main node.
In the block chain, if a current master node fails, block generation in the whole block chain network is affected, and therefore, in order to increase the block exit speed of the block chain, it is necessary to monitor that the master node fails sufficiently. Specifically, it can be understood that if the adding condition of the current new block is abnormal, it may be determined that the current master node may have a fault, so that it may be determined whether the current master node has a fault according to the adding condition of the new block. Accordingly, if the master node fails, the view needs to be switched. Therefore, a view switching request may be sent to the timestamp server, where the view switching request may be sent after the current node is encrypted by its own private key, and the view switching request further includes fault information of the master node, including a fault reason and a fault node identifier. After receiving the view switching request, the timestamp server firstly verifies the view switching request through the public key corresponding to the node, and when the view switching request is verified to be legal, the timestamp is printed on the view switching request, and the view switching request including the timestamp is fed back to the node. Accordingly, the node may broadcast the view switch request containing the timestamp into the blockchain after receiving the view switch request containing the timestamp. It can be understood that, if the view switching request is determined to be illegal after the timestamp server verifies the view switching request according to the public key corresponding to the node, the view switching request may not be processed. If the number of view change requests including the timestamp received by any node in the blockchain network exceeds a preset threshold, whether the view switch request is agreed by the current blockchain or not can be judged according to a preset judgment rule. It can be understood that if the view switching request is agreed, the preset standby node may be set as the current master node, so that the current master node can quickly add the current new area, and the efficiency of block generation is improved.
In the fault monitoring method provided by this embodiment, whether a current host node fails is determined according to an addition status of a new block; if so, sending a view replacing request to the timestamp server, wherein the view replacing request comprises the fault information of the main node; receiving a view replacement request including a timestamp and fed back by a timestamp server, and broadcasting the view replacement request including the timestamp into a block chain, wherein the view replacement request including the timestamp is fed back after the timestamp server verifies that the view replacement request is legal; determining whether the number of received view replacement requests including a time stamp exceeds a preset first threshold; if so, judging whether the block chain agrees with the view replacement request comprising the timestamp according to a preset judgment rule; if yes, the preset standby node is set as the current main node, and when the main node has an error, the system can complete the view switching within a certain threshold time. The whole view switching process adopts overtime triggering according to the optimal block timestamp in the block chain, the switching of the main node is completed within the tolerable delay range of the block chain, the mutual communication among the nodes is not needed, and the communication consumption is reduced
Fig. 3 is a flowchart illustrating a fault monitoring method according to a third embodiment of the present invention, on the basis of any of the above embodiments, the method comprises:
and 306, if yes, setting the preset standby node as the current main node.
In this embodiment, if a current master node fails, block generation in the whole block chain network is affected, and therefore, in order to increase the block exit speed of the block chain, it is necessary to monitor that the master node fails sufficiently. It can be understood that if the adding condition of the current new zone block is abnormal, it can be determined that the current master node may have a fault, so that it can be determined whether the current master node has a fault according to the adding condition of the new zone block. Specifically, when a new block is added, the generation condition of the current new block may be monitored, whether the master node has exceeded a preset time threshold and has not executed the operation of adding the new block is determined, and if yes, it is indicated that the master node has a fault. The condition for adding the new block is that the transaction number of the block reaches a preset threshold value.
According to the fault monitoring method provided by the embodiment, whether the main node exceeds the preset time threshold value and does not perform block addition is judged under the condition that new blocks are added, and if yes, the current main node is judged to have a fault, so that whether the current main node has a fault can be accurately determined, and the block output speed and efficiency of a block chain can be guaranteed.
Fig. 4 is a schematic flow chart of a fault monitoring method according to a third embodiment of the present invention, where on the basis of any one of the foregoing embodiments, as shown in fig. 4, the method further includes:
and 407, if the preset time threshold is exceeded and no new view is generated, returning to execute the step of judging whether the current main node fails according to the adding condition of the new block until a new view is generated.
In this embodiment, after detecting that the master node fails and the blockchain agrees with the view switching request, the view switching may be implemented, and in order to ensure normal view switching, the view switching process needs to be monitored, specifically, the time for generating the view may be determined, and if it is detected that the time exceeds a preset time threshold to generate a new view, the step of determining whether the current master node fails according to the addition condition of the new block may be returned until the new view is generated.
In the fault monitoring method provided by this embodiment, if a new view is not generated after exceeding a preset time threshold, the step of determining whether the current host node has a fault according to the addition condition of the new block is returned to be executed until the new view is generated, so that normal switching of the view can be ensured after the host node is detected to have a fault.
Further, on the basis of any of the above embodiments, the method comprises:
judging whether the current main node fails according to the adding condition of the new block;
if so, sending a view replacing request to a timestamp server, wherein the view replacing request comprises fault information of the main node;
receiving a view replacement request including a timestamp fed back by a timestamp server, and broadcasting the view replacement request including the timestamp into a blockchain, wherein the view replacement request including the timestamp is fed back after the view replacement request is verified to be legal by the timestamp server;
determining whether the number of received view replacement requests including a time stamp exceeds a preset first threshold;
if yes, determining the timestamps of the first view replacement requests of which the number exceeds a preset proportion in all the view replacement requests comprising the timestamps;
determining whether a difference absolute value between a timestamp corresponding to the first view change request and a variance of timestamps of all the current view change requests including timestamps is less than a preset first difference threshold value;
and/or the presence of a gas in the gas,
determining whether the absolute value of the difference between the starting time without adding the new block in the view replacement request including the timestamp sent by each node and the starting time without adding the new block by the master node is smaller than a preset second difference threshold value;
and/or the presence of a gas in the gas,
determining whether the absolute value of the difference between the termination of no new block addition and the termination time of no new block addition of the master node in the view replacement request including the timestamp sent by each node is less than a preset third difference threshold;
if yes, setting the preset standby node as the current main node.
In this embodiment, if the number of view replacement requests including the timestamp received by any node in the blockchain network exceeds a preset threshold, it may be determined whether the current blockchain agrees with the view switching request according to a preset determination rule. Specifically, the determination of whether to achieve consensus can be realized in the following three ways: determining whether a difference absolute value between a timestamp corresponding to the first view change request and a variance of timestamps of all the current view change requests including the timestamp is smaller than a preset first difference threshold value; determining whether the absolute value of the difference between the starting time without adding the new block in the view replacement request including the timestamp sent by each node and the starting time without adding the new block by the master node is smaller than a preset second difference threshold value; and determining whether the absolute value of the difference between the termination of no new block addition and the termination time of no new block addition of the master node in the view replacement request comprising the timestamp sent by each node is less than a preset third difference threshold. It should be noted that the three embodiments described above can be implemented individually or in combination, and the present invention is not limited herein.
In the fault monitoring method provided by this embodiment, it is determined whether an absolute value of a difference between a timestamp corresponding to the first view change request and variances of timestamps of all the current view change requests including the timestamp is smaller than a preset first difference threshold; determining whether the absolute value of the difference between the starting time without adding the new block in the view replacement request including the timestamp sent by each node and the starting time without adding the new block by the master node is smaller than a preset second difference threshold value; and determining whether the absolute value of the difference between the termination time without adding the new block in the view replacement request including the timestamp sent by each node and the termination time without adding the new block by the master node is smaller than a preset third difference threshold value, so as to judge whether a block chain achieves consensus on the view switching request, and further realize view switching.
Further, on the basis of any of the above embodiments, the method further includes:
judging whether the current main node fails according to the adding condition of the new block;
if so, sending a view replacing request to a timestamp server, wherein the view replacing request comprises fault information of the main node;
receiving a view replacement request including a timestamp fed back by a timestamp server, and broadcasting the view replacement request including the timestamp into a blockchain, wherein the view replacement request including the timestamp is fed back after the view replacement request is verified to be legal by the timestamp server;
determining whether the number of received view replacement requests including a time stamp exceeds a preset first threshold;
if so, judging whether the block chain agrees with the view replacement request comprising the timestamp according to a preset judgment rule;
if yes, setting the preset standby node as the current main node;
and deleting the pre-stored certificate list of the original main node.
In this embodiment, after detecting that the master node fails, and the blockchain agrees with the view switching request and switches the standby node, the certificate list of the original master node may be deleted.
In the fault monitoring method provided in this embodiment, after the preset standby node is set as the current master node, the pre-stored certificate list of the original master node is deleted, so that the memory occupation can be reduced after the master node and the view are switched.
Fig. 5 is a schematic structural diagram of a fault monitoring apparatus according to a fourth embodiment of the present invention, and as shown in fig. 5, the apparatus includes:
a first judging module 51, configured to judge whether a current master node fails according to an addition status of a new block;
a sending module 52, configured to send a view change request to a timestamp server if the view change request includes the fault information of the master node;
a receiving module 53, configured to receive a view replacement request including a timestamp and fed back by a timestamp server, and broadcast the view replacement request including the timestamp into a blockchain, where the view replacement request including the timestamp is fed back after the timestamp server verifies that the view replacement request is legal;
a determining module 54, configured to determine whether the number of received view replacement requests including the timestamp exceeds a preset first threshold;
a second judging module 55, configured to judge, if yes, according to a preset judging rule, whether the block chain agrees with the view replacement request including the timestamp;
and a setting module 56, configured to set the preset standby node as the current master node if the preset standby node is the current master node.
Further, on the basis of any of the above embodiments, the determining module includes:
and the fault determination unit is used for determining whether the main node exceeds a preset time threshold value and does not perform block addition under the condition that new blocks are added, and if so, determining that the current main node has a fault.
Further, on the basis of any one of the above embodiments, the apparatus further includes:
and the circulating module is used for returning to execute the step of judging whether the current main node fails according to the adding condition of the new block until the new view is generated if the preset time threshold is exceeded and no new view is generated.
Further, on the basis of any one of the above embodiments, the second determining module includes:
a first determining unit, configured to determine a timestamp of a first view replacement request of which the number exceeds a preset ratio among all current view replacement requests including timestamps;
a first processing unit, configured to determine whether an absolute value of a difference between a timestamp corresponding to the first view replacement request and a variance of timestamps of all the current view replacement requests including timestamps is smaller than a preset first difference threshold;
and/or the presence of a gas in the gas,
the second processing unit is used for determining whether the absolute value of the difference between the starting time without adding the new block in the view replacement request which is sent by each node and comprises the timestamp and the starting time without adding the new block of the main node is smaller than a preset second difference threshold value or not;
and/or the presence of a gas in the gas,
a third processing unit, configured to determine whether an absolute value of a difference between a termination time when no new block is added and a termination time when no new block is added in the view replacement request including a timestamp sent by each node is smaller than a preset third difference threshold.
Further, on the basis of any one of the above embodiments, the apparatus further includes:
and the deleting module is used for deleting the pre-stored certificate list of the original main node.
Fig. 6 is a schematic structural diagram of a fault monitoring device according to a fifth embodiment of the present invention, and as shown in fig. 6, the fault monitoring device includes: a memory 61, a processor 62;
a memory 61; a memory 61 for storing instructions executable by the processor 62;
wherein the processor 62 is configured to execute the fault listening method according to any one of the above embodiments by the processor 62.
Yet another embodiment of the present invention provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the computer-readable storage medium is configured to implement the fault monitoring method according to any one of the above embodiments.
It can be clearly understood by those skilled in the art that, for convenience and simplicity of description, the specific working process of the apparatus described above may refer to the corresponding process in the foregoing method embodiment, and details are not described herein again.
Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The foregoing program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.
Claims (10)
1. A method of fault monitoring, comprising:
judging whether the current main node fails according to the adding condition of the new block;
if so, sending a view replacing request to a timestamp server, wherein the view replacing request comprises the fault information of the main node; the fault information comprises a timestamp of the master node;
receiving a view replacement request including a timestamp fed back by a timestamp server, and broadcasting the view replacement request including the timestamp into a blockchain, wherein the view replacement request including the timestamp is fed back after the view replacement request is verified to be legal by the timestamp server;
determining whether the number of received view replacement requests including a time stamp exceeds a preset first threshold;
if so, judging whether the block chain agrees with the view replacement request comprising the timestamp according to a preset judgment rule;
if yes, setting the preset standby node as the current main node;
the judging whether the block chain agrees with the view change including the timestamp according to a preset judgment rule includes:
determining the time stamps of the first view replacement requests of which the number exceeds a preset proportion in all the view replacement requests comprising the time stamps;
and determining whether the absolute value of the difference between the timestamp corresponding to the first view change request and the variance of the timestamps of all the current view change requests including the timestamp is less than a preset first difference threshold value.
2. The method of claim 1, wherein the determining whether the current master node fails according to the addition status of the new block comprises:
and under the condition that new blocks are added, judging whether the main node exceeds a preset time threshold value and does not add the blocks, and if so, judging that the current main node has a fault.
3. The method of claim 1, wherein after the setting of the preset backup node as the current master node, further comprising:
and if the preset time threshold is exceeded and no new view is generated, returning to execute the step of judging whether the current main node fails according to the adding condition of the new block until the new view is generated.
4. The method of claim 1, wherein the failure information further comprises a start time and an end time of the master node without block addition; the judging whether the block chain agrees with the view change including the timestamp according to a preset judgment rule further includes:
determining whether the absolute value of the difference between the starting time without adding the new block in the view replacement request including the timestamp sent by each node and the starting time without adding the new block by the master node is smaller than a preset second difference threshold value;
and/or the presence of a gas in the gas,
and determining whether the absolute value of the difference between the termination of no new block addition in the view replacement request including the timestamp sent by each node and the termination time of no new block addition of the master node is less than a preset third difference threshold.
5. The method according to any one of claims 1 to 4, wherein after setting the preset backup node as the current primary node, the method comprises:
and deleting the pre-stored certificate list of the original master node.
6. A fault listening device, comprising:
the first judgment module is used for judging whether the current main node fails according to the adding condition of the new block;
a sending module, configured to send a view change request to a timestamp server if the view change request includes the fault information of the master node; the fault information comprises a timestamp of the master node;
the view replacing module is used for receiving a view replacing request which comprises a timestamp and is fed back by the timestamp server, broadcasting the view replacing request which comprises the timestamp into the block chain, wherein the view replacing request which comprises the timestamp is fed back after the timestamp server verifies that the view replacing request is legal;
a determining module, configured to determine whether the number of received view replacement requests including a timestamp exceeds a preset first threshold;
the second judgment module is used for judging whether the block chain agrees with the view replacement request comprising the timestamp according to a preset judgment rule if the view replacement request comprises the timestamp;
the setting module is used for setting the preset standby node as the current main node if the preset standby node is the current main node;
the second judging module is specifically configured to determine the timestamps of the first view replacement requests, of which the number exceeds a preset ratio, in all the current view replacement requests including the timestamps; and determining whether the absolute value of the difference between the timestamp corresponding to the first view change request and the variance of the timestamps of all the current view change requests including the timestamp is less than a preset first difference threshold value.
7. The apparatus of claim 6, wherein the determining module comprises:
and the fault determination unit is used for determining whether the main node exceeds a preset time threshold value and does not perform block addition under the condition that new blocks are added, and if so, determining that the current main node has a fault.
8. The apparatus of claim 7, further comprising:
and the circulating module is used for returning to execute the step of judging whether the current main node fails according to the adding condition of the new block until the new view is generated if the preset time threshold is exceeded and no new view is generated.
9. A fault listening device, comprising: a memory, a processor;
a memory; a memory for storing the processor-executable instructions;
wherein the processor is configured to perform the fault listening method of any one of claims 1-5 by the processor.
10. A computer-readable storage medium having computer-executable instructions stored thereon, which when executed by a processor, are configured to implement the fault listening method of any one of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910073686.XA CN109918261B (en) | 2019-01-25 | 2019-01-25 | Fault monitoring method, device, equipment and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910073686.XA CN109918261B (en) | 2019-01-25 | 2019-01-25 | Fault monitoring method, device, equipment and computer readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109918261A CN109918261A (en) | 2019-06-21 |
| CN109918261B true CN109918261B (en) | 2022-11-22 |
Family
ID=66960869
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910073686.XA Active CN109918261B (en) | 2019-01-25 | 2019-01-25 | Fault monitoring method, device, equipment and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109918261B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110351133B (en) * | 2019-06-28 | 2021-09-17 | 创新先进技术有限公司 | Method and device for main node switching processing in block chain system |
| US10944624B2 (en) | 2019-06-28 | 2021-03-09 | Advanced New Technologies Co., Ltd. | Changing a master node in a blockchain system |
| CN110727731B (en) * | 2019-09-05 | 2021-12-21 | 创新先进技术有限公司 | Method for adding node in block chain network and block chain system |
| CN111104282B (en) * | 2019-11-26 | 2024-01-16 | 众安信息技术服务有限公司 | Node processing method and device based on block chain |
| CN110954780A (en) * | 2019-12-03 | 2020-04-03 | 湖南国奥电力设备有限公司 | Underground cable fault detection method and device based on block chain |
| CN110995837B (en) * | 2019-12-03 | 2022-09-30 | 湖南国奥电力设备有限公司 | Underground cable collected data uploading method and system based on block chain |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108134706A (en) * | 2018-01-02 | 2018-06-08 | 中国工商银行股份有限公司 | Block chain high-availability system mostly living, computer equipment and method |
| CN108390891A (en) * | 2018-03-28 | 2018-08-10 | 电子科技大学天府协同创新中心 | Information protecting method based on privately owned block chain |
| CN108492103A (en) * | 2018-02-07 | 2018-09-04 | 北京大学深圳研究生院 | A kind of alliance's block chain common recognition method |
| CN108768630A (en) * | 2018-05-25 | 2018-11-06 | 全链通有限公司 | The encryption communication method and system of block chain node |
| CN109086626A (en) * | 2018-08-09 | 2018-12-25 | 全链通有限公司 | The bookkeeping methods and system of block chain network |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10586210B2 (en) * | 2016-11-30 | 2020-03-10 | International Business Machines Corporation | Blockchain checkpoints and certified checkpoints |
-
2019
- 2019-01-25 CN CN201910073686.XA patent/CN109918261B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108134706A (en) * | 2018-01-02 | 2018-06-08 | 中国工商银行股份有限公司 | Block chain high-availability system mostly living, computer equipment and method |
| CN108492103A (en) * | 2018-02-07 | 2018-09-04 | 北京大学深圳研究生院 | A kind of alliance's block chain common recognition method |
| CN108390891A (en) * | 2018-03-28 | 2018-08-10 | 电子科技大学天府协同创新中心 | Information protecting method based on privately owned block chain |
| CN108768630A (en) * | 2018-05-25 | 2018-11-06 | 全链通有限公司 | The encryption communication method and system of block chain node |
| CN109086626A (en) * | 2018-08-09 | 2018-12-25 | 全链通有限公司 | The bookkeeping methods and system of block chain network |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109918261A (en) | 2019-06-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109918261B (en) | Fault monitoring method, device, equipment and computer readable storage medium | |
| CN110995468B (en) | System fault processing method, device, equipment and storage medium of system to be analyzed | |
| WO2020253083A1 (en) | Synchronization data verification method for primary and secondary storage volume, device, apparatus, and storage medium | |
| CN110908833A (en) | Data backup method, device and equipment and computer readable storage medium | |
| CN110690974B (en) | Block chain based data verification method, device, equipment and readable storage medium | |
| CN107832169B (en) | Memory data migration method and device, terminal equipment and storage medium | |
| JP6230322B2 (en) | Communication apparatus, key sharing method, program, and communication system | |
| CN111026767B (en) | Block chain data storage method and device and hardware equipment | |
| CN108965383B (en) | File synchronization method and device, computer equipment and storage medium | |
| CN106878038B (en) | Fault positioning method and device in communication network | |
| CN104579558A (en) | Method for detecting integrity in data transmission process | |
| CN110597918A (en) | Account management method and device and computer readable storage medium | |
| CN112184436B (en) | Data synchronization method, electronic device and readable storage medium | |
| CN111899019A (en) | Method and system for cross validation and sharing of blacklist and multiple parties | |
| CN111831974A (en) | Interface protection method and device, electronic equipment and storage medium | |
| CN112398692A (en) | Consensus process processing method and device and electronic equipment | |
| CN110830500B (en) | Network attack tracking method and device, electronic equipment and readable storage medium | |
| CN114363034B (en) | Verification code generation and verification method and device, electronic equipment and storage medium | |
| CN108924772B (en) | Short message sending method and device, computer equipment and storage medium | |
| CN108846085B (en) | ID generation method, device, electronic equipment and system | |
| CN112436962B (en) | Block chain consensus network dynamic expansion method, electronic device, system and medium | |
| CN111260227B (en) | Service data source processing method, device, computer equipment and storage medium | |
| US11930292B2 (en) | Device state monitoring method and apparatus | |
| CN111831954A (en) | Content data updating method and device, computer equipment and storage medium | |
| CN108882230B (en) | Call record management method, device and system |
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 |