CN114064343B

CN114064343B - Abnormal handling method and device for block chain

Info

Publication number: CN114064343B
Application number: CN202210037292.0A
Authority: CN
Inventors: 王晓亮; 王福音
Original assignee: Beijing Xita Technology Co ltd
Current assignee: Beijing Xita Technology Co ltd
Priority date: 2022-01-13
Filing date: 2022-01-13
Publication date: 2022-04-08
Anticipated expiration: 2042-01-13
Also published as: CN114064343A

Abstract

A block chain exception handling method and device are applied to a block chain of a micro service architecture, wherein a controller used for packaging transactions into blocks in the micro service architecture of the block chain is decoupled from a consensus device used for consensus on the blocks, and a consensus mechanism adopted by the block chain at least comprises a leader role and a follower role; the method comprises the following steps: the consensus device of the leader node of the block chain detects whether the controller of the same node is in an abnormal state; if the controller is in an abnormal state, sending a replacement leader request to other follower nodes participating in the consensus mechanism; the follower node that received the change leader request initiates a leader role vote to become a new leader node after the vote is passed within the consensus mechanism. By applying the scheme, the condition that the consensus device of the leader node is normal but the controller is abnormal can be treated, and the stable operation of the consensus mechanism is guaranteed.

Description

Abnormal handling method and device for block chain

Technical Field

The present disclosure relates to the field of block chain technologies, and in particular, to a method and an apparatus for handling exception of a block chain.

Background

The block chain technology, also called as distributed account book technology, is a technology in which a plurality of computing devices participate in accounting together and maintain a complete distributed database together; people develop a plurality of consensus algorithm systems to ensure the consistency of calculation and storage on a plurality of computing devices participating in 'accounting' together, wherein one type of formula algorithm system can comprise a leader role and a follower role; in real business, consensus can still be usually completed if an individual computer in the role of follower fails, but it may result in failure or suspension of consensus if a computing device in the role of leader fails.

In the related art, a fault handling algorithm can be included in a part of consensus algorithm system, and is specifically embodied in that if the time for which a computing device in the leader role is found to be unresponsive exceeds a threshold value, the leader role is automatically handed over, so that other computing devices which do not have faults become new leaders, and therefore the consensus can be guaranteed to run stably.

However, under the partial blockchain architecture, the above-mentioned failure handling algorithm cannot correctly identify the failed leader computing device, so that the failed leader computing device cannot provide normal functions for a long time, and the consensus cannot continue.

Disclosure of Invention

In view of this, the present specification discloses an exception handling method and apparatus for a block chain.

According to a first aspect of embodiments of the present specification, a method for handling an exception of a block chain is disclosed, which is applied to a block chain of a micro service architecture, wherein a controller in the micro service architecture of the block chain for packing transactions into blocks is decoupled from a consensus device for consensus on the blocks, and a consensus mechanism adopted by the block chain at least includes a leader role and a follower role; the method comprises the following steps:

the consensus device of the leader node of the block chain detects whether the controller of the same node is in an abnormal state;

if the controller is in an abnormal state, sending a replacement leader request to other follower nodes participating in the consensus mechanism;

the follower node that received the change leader request initiates a leader role vote to become a new leader node after the vote is passed within the consensus mechanism.

Optionally, the detecting whether the controller of the same node is in an abnormal state includes:

attempting to acquire new proposal information from a controller of the same node;

and if the new proposal information cannot be acquired or the content of the acquired new proposal information is illegal, determining that the controller of the same node is in an abnormal state.

Optionally, the sending a change leader request to other follower nodes participating in the consensus mechanism includes:

screening other follower nodes participating in the consensus mechanism to obtain candidate nodes;

sending a replacement leader request to the candidate node.

Optionally, the screening includes:

and screening to obtain follower nodes with the active indexes reaching a preset threshold value and the latest consensus state stored on the follower nodes based on the node state records.

Optionally, the screening includes:

sending a controller abnormity check message to other follower nodes participating in the consensus mechanism so that the other follower nodes participating in the consensus mechanism carry out abnormity check on the corresponding controller and feed back the abnormity check result;

and screening to obtain the follower nodes of which the corresponding controllers are not in the abnormal state according to the result of the abnormal inspection.

Optionally, the screening includes:

screening to obtain a candidate node with the highest priority based on a preset priority list; wherein the priority list is a list for prioritizing nodes based on their computational performance, and/or storage performance, and/or communication performance.

Optionally, the consensus mechanism adopted by the block chain includes a Raft mechanism; the change leader request includes a leader node timeout message.

According to a second aspect of the embodiments of the present specification, an exception handling apparatus for a block chain is disclosed, which is applied to a block chain of a micro service architecture, wherein a controller in the micro service architecture of the block chain for packing transactions into blocks is decoupled from a consensus device for consensus on the blocks, and the consensus mechanism adopted by the block chain at least includes a leader role and a follower role; the device comprises:

a detection module configured to cause a consensus of the blockchain leader node to detect whether a controller of a same node is in an abnormal state;

a sending module configured to send a replacement leader request to other follower nodes participating in the consensus mechanism if the controller is in an abnormal state;

a voting module configured to cause a follower node that received the change leader request to initiate a leader role vote to become a new leader node after the vote is passed within the consensus mechanism.

According to a third aspect of the embodiments of the present specification, a computer device is disclosed, which at least comprises a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of the above-mentioned aspect embodiments when executing the program.

According to a fourth aspect of embodiments herein, a computer-readable storage medium is disclosed, on which a computer program is stored, which, when executed by a processor, implements the method of any of the above-described aspect embodiments.

In the above technical solution, since the consensus device of the leader node of the block chain can actively detect whether the controller of the same node is in an abnormal state, and start the process of migrating the leader role in the consensus mechanism under the condition that the controller is in the abnormal state, so that the leader role is migrated to other nodes, even if the block chain adopts a micro-service architecture in which the controller and the consensus device are decoupled, under the condition that only the controller fails but the consensus device fails and a conventional fault detection and handling algorithm cannot take effect, the original leader node in which the controller fails but the consensus device fails can be detected and handled by the scheme, thereby ensuring the normal operation of the consensus system.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this specification and together with the description, serve to explain the principles.

Fig. 1 is a diagram illustrating an example of a situation where a block chain consensus is abnormal, which is shown in the present specification;

FIG. 2 is a flowchart illustrating a method of exception handling for a blockchain as described herein;

FIG. 3 is a diagram illustrating an example of a structure of an exception handling apparatus for a blockchain shown in this specification;

fig. 4 is a diagram illustrating an example of a structure of a computer device for exception handling of a block chain according to this specification.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in one or more embodiments of the present disclosure, the technical solutions in one or more embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in one or more embodiments of the present disclosure. It is to be understood that the described embodiments are only a few, and not all embodiments. All other embodiments that can be derived by one of ordinary skill in the art from one or more embodiments of the disclosure without making any creative effort shall fall within the scope of the disclosure.

When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of systems and methods consistent with aspects of the present description.

The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Referring to fig. 1, fig. 1 is a diagram illustrating a scenario in which a block chain consensus is abnormal, according to an embodiment of the present disclosure; as shown in fig. 1, the scenario includes 4 interconnected block nodes (more possible block nodes and communication lines are not directly shown in the figure) respectively being node a, node B, node C, and node D; the nodes adopt a micro-service architecture, and a controller for packaging transactions into blocks and a recognizer for recognizing the blocks are decoupled inside the nodes; in other words, the nodes can communicate information with each other through the communication lines between the respective consensus devices.

Wherein, assuming that the node a in the above example is a leader under the current consensus mechanism, a controller thereof has a fault that the transaction cannot be packed into blocks, but the consensus machine is still in a normal state; if the traditional timeout detection exception handling algorithm is applied, since the consensus device of the node a does not fail and can respond in time, the consensus mechanism cannot find the failure condition of the node a, and any leader role transfer flow for the node a cannot be started, so that the node a occupies the role of the leader node but cannot normally provide the function of packaging transactions into blocks, and consensus may not be performed.

Based on this, the present specification proposes a technical solution, where a block chain adopts a micro-service architecture in which a controller and a consensus device are decoupled, and a consensus system includes a leader and a follower, where the consensus device of the leader node actively detects whether the controller of the same node is in an abnormal state, and starts a leader migration flow in a consensus mechanism when it is determined that the controller is abnormal, so that the role of the leader can be replaced in time, and normal operation of the consensus mechanism is guaranteed.

In implementation, if the controller capable of determining that the leader node is in an abnormal state is detected, a replacement leader request may be sent to other follower nodes participating in the consensus mechanism, and the follower node receiving the replacement leader request may initiate a leader role vote, so that the follower node becomes a new leader node after the vote is passed through the consensus mechanism.

That is, the technical solution disclosed in the present specification can be used as a supplementary solution for exception handling under the consensus mechanism including the leader role and the follower role for the micro-service architecture in which the controller is decoupled from the consensus engine.

The present specification is described below with reference to specific embodiments and specific application scenarios.

Referring to fig. 2, fig. 2 is a flowchart of an exception handling method for a block chain according to an embodiment of the present disclosure, where the method may be applied to a block chain of a micro service architecture, where a controller in the micro service architecture of the block chain for packaging transactions into blocks may be decoupled from a consensus for consensus on the blocks, and the consensus mechanism adopted by the block chain may include at least a leader role and a follower role; the above method may comprise the steps of:

s201, a consensus device of the leader node of the block chain detects whether a controller of the same node is in an abnormal state;

s202, if the controller is in an abnormal state, sending a leader replacement request to other follower nodes participating in the consensus mechanism;

s203, the follower node which receives the request of replacing the leader initiates a leader role vote to become a new leader node after the vote is passed through the consensus mechanism.

The block chain can comprise any form of block chain; in the art, blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). Furthermore, there may be a combination of the above types, such as private chain + federation chain, federation chain + public chain, and so on. The most decentralized is the public chain, the private chain can be a weak centralized system, which has strict limitation on nodes and a small number of nodes, and the federation chain is a block chain between the public chain and the private chain, which can implement "partial decentralized". The skilled person can select the specific used block chain type according to the specific service requirement, which is not limited in detail in this specification.

The node device may include a type or a form of node device; from the functional point of view, the block link node device may include a full-function node, a read-only node, a light-weight node, and the like, where the full-function node may participate in services such as consensus, intelligent contract logic calculation, and data storage, and the read-only node generally does not participate in consensus voting, and only provides a function of data storage, so as to improve the stability of the block link, and the light-weight node may only store data of several latest blocks, and its services that can be handled are relatively limited, but the storage cost that the node device needs to pay can be reduced. The block link point equipment is divided from the aspect of form, and can comprise physical equipment such as a personal computer, a smart phone and the like of an independent operation block link node client, and also can refer to a block link point virtual machine which operates in a cloud server; it should be understood that a cloud computing cluster running a plurality of blockchain nodes through a cloud native engine may also be regarded as a node device, but when discussing blockchain node individuals, it refers to each blockchain node process running relatively independently in the cloud computing cluster.

The leader may refer to a role played by a node that proposes a consensus proposal in the consensus hierarchy, and the follower may refer to a role in voting for the consensus proposal in the consensus hierarchy. It is understood that the names of the above roles may differ in different consensus systems, which need not be detailed herein, and one of ordinary skill in the art can distinguish between the tasks actually responsible for the node and perform a specific migration application operation.

In the field, a microservice architecture generally refers to a software design style that divides a software structure as fine as possible according to functions, thereby improving the extensibility and reliability of software. For example, for a blockchain node, functions such as master control, consensus, network interface, transaction execution, key management, data storage, and the like can be decoupled by way of a microservice, so that each microservice can be upgraded and maintained independently. The blockchain architecture referred to in this specification is a micro-service architecture that is a controller for packaging transactions into blocks, decoupled from a consensus for consensus on blocks. It will be appreciated that a single microservice failing may not affect the operation of other microservices, which may be both an advantage of proving high software reliability and a disadvantage of causing the failure to be masked (e.g., the controller failure described herein cannot be detected by the conventional failure detection handling algorithm described above).

In this specification, the consensus device of the leader node of the block chain may detect whether the controller of the same node is in an abnormal state; it is understood that the trigger condition for detecting whether the node is in the abnormal state may be set according to specific requirements, for example, the trigger condition may be performed according to a preset time interval or time point, or according to a specific event (for example, starting the consensus calculation, exiting the consensus system with the node, and the like), or according to a specific instruction input by the user, and the like. Those skilled in the art can design the consensus device of the leader node according to specific requirements to detect whether the controller of the same node is in an abnormal state.

The algorithm for specifically detecting whether the controller is in an abnormal state does not need to be limited in detail in the specification; for example, whether the controller is in an abnormal state may be determined according to whether the controller can complete an expected task, or may be determined according to the behavior of the controller and an occupancy indicator for the resource. For example, it is assumed that the controller normally occupies only 10 to 50MB of memory space, but it is detected that the controller occupies 600MB of memory space in a certain period of time and deviates from the expected memory space occupation interval, so that it can be presumed that the controller has a failure such as a memory leak.

In one embodiment shown, when it is required to detect whether the controller of the same node is in an abnormal state, it may be attempted to acquire new proposal information from the controller of the same node; and if the new proposal information cannot be acquired or the content of the acquired new proposal information is illegal, determining that the controller of the same node is in an abnormal state. For example, if the consensus device acquires new proposal information from the controller under normal conditions, the new proposal information fed back by the controller can be obtained within 200ms, and the controller can be judged to have a fault and be in an abnormal state if no new proposal information is obtained within 200 ms; or, if the new proposal information carries the preset verification information according to the preset data structure under the normal condition, but the new proposal information received this time does not carry the preset verification information according to the preset data structure, it can also be concluded that the controller is in the abnormal state.

In this specification, if it is determined that the controller is in an abnormal state, a replacement leader request may be sent to other follower nodes participating in the consensus mechanism; as described above, if it is determined that the controller is in an abnormal state, which means that the leader node enters an abnormal state that the controller is abnormal but the consensus device is normal and cannot be found by the conventional detection means, a request for replacing the leader may be sent to other follower nodes participating in the consensus mechanism.

In one embodiment, the consensus mechanism adopted by the block chain comprises a Raft mechanism; the change leader request includes a leader node timeout message. For the Raft mechanism, the replacement process of the leader role is started by default under the condition that the leader node is overtime; therefore, under the condition of adopting a Raft consensus mechanism, the replacement leader request can be directly set as a leader node overtime message, the Raft mechanism is fully utilized, and the software development workload is reduced. It is understood that different consensus systems may implement different ways of implementing the replacement leader, and those skilled in the art can do the design work requested by the replacement leader.

In an embodiment shown, when sending a request for replacing a leader to other follower nodes participating in the consensus mechanism, the other follower nodes participating in the consensus mechanism may be screened to obtain candidate nodes; and sending a request of replacing the leader to the candidate node. It can be understood that, since the leader role bears more critical tasks in the consensus system, not all follower nodes are suitable as new leader nodes, so that candidate nodes can be selected by screening first, and then new leader nodes are voted from the candidate nodes.

In an embodiment shown, the screening may refer to screening, based on the node state record, a follower node whose active index reaches a preset threshold and has the latest consensus state stored; it can be generally considered that if a follower node activity indicator is high enough, it can fulfill an obligation, for example, with a high probability of completing a task; if a follower node has the latest consensus status, it can enter the leader role as soon as possible to begin the relevant task (without having to reacquire the latest consensus status from other nodes).

In another illustrated embodiment, during the screening, a controller anomaly check message may be sent to other follower nodes participating in the consensus mechanism, so that the other follower nodes participating in the consensus mechanism perform anomaly check on the corresponding controller, and feed back the result of the anomaly check; and screening to obtain follower nodes of which the corresponding controllers are not in abnormal states according to the abnormal checking result. Obviously, if the newly selected node is still in an abnormal state, the replacement of the leader does not achieve the expected purpose of selecting a leader node capable of completing the task. Therefore, in the screening stage, the follower nodes of which the corresponding controllers are not in the abnormal state can be screened and obtained in a mode that other follower nodes participating in the consensus mechanism carry out abnormal check on the corresponding controllers and feed back results, and the invalid replacement of the role of the leader is avoided.

In another illustrated embodiment, the candidate node with the highest priority may be obtained by screening based on a preset priority list; wherein the priority list is a list for prioritizing nodes based on their computational performance, and/or storage performance, and/or communication performance. Generally, the higher the performance of a node, the more suitable it is as the leader node; therefore, a priority list of nodes can be generated in advance according to performance indexes of calculation, storage, communication and the like of the nodes, and a candidate node with the highest priority can be selected during screening. In this way, the new leader node can be guaranteed to have more excellent performance.

It is understood that the above screening methods can be freely combined, and those skilled in the art can implement relevant combinational logic design according to specific business requirements.

In this description, a follower node that receives the change leader request may initiate a leader role vote to become a new leader node after the vote is passed within the consensus mechanism. In general, a new leader node can be selected by voting in the consensus mechanism; specifically, in the case where the consensus mechanism does not have most of the nodes failed, the process of voting to select a new leader node is usually always completed; therefore, the most critical technology for solving the failure of the leader node is the logic of triggering the replacement of the leader node by detecting the failure which cannot be detected in the past. Within different consensus mechanisms, there may be differences in the way that a particular vote is cast, e.g., one vote per node in some consensus mechanisms, while some nodes in other consensus mechanisms may hold votes of higher weight, etc. The skilled person can refer to the relevant literature to perform relevant voting logic design by himself, and this specification does not need to be listed in more detail.

The scheme described in this specification is described below by a more detailed example of a feasible mechanism based on the Raft consensus. Assuming that there is a blockchain consisting of three nodes, node one is the leader node, and for some reasons, the controller of node one fails; if the consensus device of the first node fails to attempt to acquire new proposal information from the controller, the controller can be considered to be abnormal, and the leader role of the consensus device is started to migrate; the common recognizer of the first node can broadcast an indication for starting abnormal examination into the common recognition mechanism, the common recognizers of the second and third nodes receive the indication and initiate the abnormal examination to a local controller, and if the controllers of the second and third nodes operate normally, the common recognizers report to a leader role (the first node); after receiving the responses of the second number and the third number, the first node checks the raft state record, finds that the second node and the third node both contain the latest state, assumes that the first node is set according to the migration priority, finds that the second node has better performance, and can take the second node as a candidate node to initiate an overtime request to the second node; the second node broadcasts a voting request, and becomes a new leader node after receiving approval from the first node and the third node; and the consensus device of the second node acquires new proposal information from the controller which normally operates locally, and the block can be successfully output after consensus is completed.

The foregoing description is directed to all embodiments of the exception handling method for the blockchain in this specification. Based on the above embodiments, the present application finds a specific abnormal situation (the common recognizer is normal but the controller is abnormal) under a specific situation (the block chain adopts a micro service architecture in which the controller and the common recognizer are separated, and the common recognition system includes a leader and a follower), and provides a detection and processing scheme for the specific abnormal situation, so that the specific abnormal situation can be effectively processed, and the healthy operation of the common recognition mechanism is ensured.

This specification also provides embodiments of an exception handling apparatus for a corresponding blockchain as follows:

referring to fig. 3, fig. 3 is a diagram of an example of a structure of an exception handling apparatus for a block chain, which may be applied to a block chain of a micro service architecture, where a controller for packaging transactions into blocks in the micro service architecture of the block chain is decoupled from a consensus device for performing consensus on the blocks, and a consensus mechanism adopted by the block chain at least includes a leader role and a follower role; the above-mentioned device includes:

a detection module 301 configured to cause the consensus of the block chain leader node to detect whether the controller of the same node is in an abnormal state;

a sending module 302 configured to send a replacement leader request to other follower nodes participating in the consensus mechanism if the controller is in an abnormal state;

a voting module 303 configured to cause a follower node that received the change leader request to initiate a leader role vote to become a new leader node after the vote is passed within the consensus mechanism.

Embodiments of the present specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the foregoing exception handling method for a block chain when executing the program.

Fig. 4 is a schematic diagram illustrating a more specific hardware structure of a computing device according to an embodiment of the present disclosure, where the computing device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.

The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.

The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

Bus 1050 includes a path that transfers information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.

It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.

Embodiments of the present specification further provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the foregoing exception handling method for a blockchain.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present disclosure. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.

Claims

1. An exception handling method of a block chain is applied to the block chain of which nodes adopt a micro service architecture, and is characterized in that the micro service architecture of the nodes of the block chain is used for a controller for packaging transactions into blocks and a consensus machine for consensus on the blocks, wherein the consensus machine adopted by the block chain at least comprises a leader role and a follower role; the method comprises the following steps:

2. The method of claim 1, wherein the detecting whether the controller of the same node is in an abnormal state comprises:

3. The method of claim 1, wherein sending a change leader request to other follower nodes participating in the consensus mechanism comprises:

sending a replacement leader request to the candidate node.

4. The method of claim 3, wherein the screening comprises:

5. The method of claim 3, wherein the screening comprises:

6. The method of claim 3, wherein the screening comprises:

7. The method of claim 1, wherein the consensus mechanism employed by the blockchain comprises a Raft mechanism; the change leader request includes a leader node timeout message.

8. An exception handling device of a block chain is applied to the block chain of which nodes adopt a micro service architecture, and is characterized in that the micro service architecture of the nodes of the block chain is used for packing transactions into blocks and decoupling a consensus machine used for consensus on the blocks, and a consensus mechanism adopted by the block chain at least comprises a leader role and a follower role; the device comprises:

9. A computer device comprising at least a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor when executing the program implements the method of any of claims 1 to 7.

10. A computer-readable storage medium, having stored thereon a computer program which, when executed by a processor, implements the method of any one of claims 1 to 7.