CN114268532B - Games method based on Raft protocol, distributed system and storage medium - Google Patents
Games method based on Raft protocol, distributed system and storage medium Download PDFInfo
- Publication number
- CN114268532B CN114268532B CN202111409153.8A CN202111409153A CN114268532B CN 114268532 B CN114268532 B CN 114268532B CN 202111409153 A CN202111409153 A CN 202111409153A CN 114268532 B CN114268532 B CN 114268532B
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- election
- candidate
- current
- 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 39
- 238000004590 computer program Methods 0.000 claims description 6
- 230000002159 abnormal effect Effects 0.000 claims description 5
- 230000002860 competitive effect Effects 0.000 claims description 5
- 238000006243 chemical reaction Methods 0.000 claims description 3
- 230000002950 deficient Effects 0.000 description 9
- 230000005856 abnormality Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002035 prolonged effect Effects 0.000 description 2
- 238000012797 qualification Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention discloses an election method, a distributed system and a storage medium based on Raft protocol, wherein the method comprises the steps of converting a plurality of slave nodes into candidate nodes when a Redis cluster is in an election mode; each candidate node sequentially initiates an election request; when the current voting node votes to the current candidate node, if the latest log submitting time of the current candidate node is later than the latest log submitting time of the current voting node, terminating the round of election, and converting the current voting node into an updated candidate node; and controlling the updating candidate node to continuously initiate the election request until the master node is elected. According to the Raft protocol-based election method, the distributed system and the storage medium provided by the embodiment of the invention, by comparing the important parameter of the latest log submitting time, the meaningless election process is ended in advance, so that the data operation amount and operation time of election are greatly reduced, the probability of selecting a main node in each round of bidding is improved, and the availability of a cluster is ensured.
Description
Technical Field
The present invention relates to the field of distributed cluster management technologies, and in particular, to an election method, a distributed system, and a storage medium based on Raft protocols.
Background
Raft is an algorithm for managing REPLICATED LOG, which is an important application in distributed fault tolerant systems. In the Redis cluster, each server is only in one of three states of a master node, a candidate and a slave node at any time. The master node receives the log entries from the client, copies the log entries to other servers, and controls the other servers to apply the log entries to own state machines; slave nodes are passive in that they do not issue requests, but only respond to requests from the master node and candidates; the candidate is randomly selected from the server by the cluster to elect a master node.
Now, when the candidate asks other slave nodes to vote on the candidate, the period and the log length owned by the candidate and the voting node are compared, and the condition that the period and the log length owned by the candidate are larger than those owned by the voting node is that the new master node is elected in this way. In some cases, the ballot may be split, resulting in no master node being generated, the term will end up with no master node, and a new term will be generated soon. The Raft protocol ensures that there is at most one master per term, and in extreme cases the cluster will go through multiple rounds of voting to bid on the master.
Because the distributed fault-tolerant system can generate various complex abnormal conditions such as network delay, partition, packet loss, repetition, out-of-order and the like, log length can be smaller than that of other nodes, but the wilting period is higher than that of 'defective nodes' of other nodes, if the 'defective nodes' are randomly established as candidates by a cluster at first, a round of election which a main node cannot be generated is initiated, meaningless time consumption is caused, the calculated amount of data is increased, the operation time of an algorithm is prolonged, and the availability of the cluster is greatly reduced.
Disclosure of Invention
The invention provides an election method, a distributed system and a storage medium based on Raft protocol, which are used for solving the technical problems that the algorithm operation time is prolonged and the cluster availability is reduced due to 'defective nodes' in the existing Redis cluster, and the meaningless election initiated by the 'defective nodes' is ended in advance by comparing the important parameter of the latest log submission time, so that the process of electing the master nodes is quickened and the availability of the cluster is improved.
In order to solve the above technical problems, an embodiment of the present invention provides an election method based on Raft protocols, including:
When the Redis cluster is in an election mode, converting a plurality of slave nodes into candidate nodes;
Each candidate node sequentially initiates an election request, and the current candidate node in each round of bidding can require other nodes except the current candidate node to vote on the current candidate node one by one;
When a current voting node votes for the current candidate node, comparing the latest log submitting time of the current candidate node with the latest log submitting time of the current voting node;
If the latest log submitting time of the current candidate node is later than the latest log submitting time of the current voting node, terminating the round of election, and converting the current voting node into an updated candidate node;
And controlling the updating candidate node to continuously initiate an election request until the master node is elected.
As one preferable solution, the election method based on Raft protocol further includes:
If detecting that the main node does not exist in the Redis cluster, controlling the Redis cluster to enter the election mode; or alternatively, the first and second heat exchangers may be,
And if the period of the current master node is lower than the period of any slave node, controlling the current master node to be converted into the slave node, and controlling the Redis cluster to enter the election mode.
As one preferable solution, before the plurality of slave nodes are converted into candidate nodes, the election method based on Raft protocol further includes:
and controlling each slave node to enter a standby state, wherein the standby state lasts 150 ms-300 ms.
As one preferable scheme, if the latest log submitting time of the current candidate node is earlier than the latest log submitting time of the current voting node, controlling the current voting node with the tenure and the log length smaller than the current candidate node to vote to the current candidate node.
As one preferable scheme, if the number of votes of the current candidate node satisfies the following relation, the current candidate node is elected as the master node:
wherein a is the ticket number of the current candidate node, and b is the node number of the Redis cluster.
As one preferable solution, the election method based on Raft protocol further includes:
If at least two updating candidate nodes exist in the Redis cluster, each updating candidate node sequentially generates a special competitive choice request with a time zone bit, wherein the time zone bit reflects the conversion time of the updating candidate node;
comparing the time zone bit of the two updating candidate nodes, controlling the updating candidate node with the later time zone bit to vote to the updating candidate node with the earlier time zone bit, and
And forwarding all the ticket numbers of the updating candidate nodes with the later time zone bits to the updating candidate nodes with the earlier time zone bits.
As one preferable scheme, after the master node is elected, the election mode is ended, and the Redis cluster is controlled to enter a normal mode.
Another embodiment of the present invention provides a distributed system including a plurality of nodes, the nodes being dis servers operating in a cluster mode, and the nodes being divided into master nodes and slave nodes;
the distributed system is used for executing the competing method based on Raft protocol when the main node is abnormal.
As one preferable scheme, the nodes comprise N master nodes and n×n slave nodes, and any one master node corresponds to N slave nodes respectively.
Yet another embodiment of the present invention provides a computer readable storage medium storing a computer program, where the computer program when executed controls a device in which the computer readable storage medium is located to perform an election method based on Raft protocol as described above.
Compared with the prior art, the embodiment of the invention has the beneficial effects that at least one of the following points is adopted: when the Redis cluster is in an election mode, except for two parameters of a period of time for providing and a log length, each round of election initiated by the candidate node can require the candidate node and the voting node to provide the latest log submission time owned by the candidate node, after the voting node finds the latest log submission time owned by the self and updates, the cluster can immediately finish the round of election, and the voting node is converted into the updated candidate node to continuously initiate an election request.
Drawings
FIG. 1 is a flow chart of an election method based on Raft protocol in one embodiment of the invention;
FIG. 2 is a flow chart of a special election link in one embodiment of the invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
In the description of the present application, the terms "first," "second," "third," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first", "a second", "a third", etc. may explicitly or implicitly include one or more such feature. In the description of the present application, unless otherwise indicated, the meaning of "a plurality" is two or more.
In the description of the present application, it should be noted that, unless explicitly specified and limited otherwise, the terms "mounted," "connected," and "connected" are to be construed broadly, and may be either fixedly connected, detachably connected, or integrally connected, for example; can be mechanically or electrically connected; can be directly connected or indirectly connected through an intermediate medium, and can be communication between two elements. The specific meaning of the above terms in the present application will be understood in specific cases by those of ordinary skill in the art.
In the description of the present application, it should be noted that all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs unless defined otherwise. The terminology used in the description of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application, as the particular meaning of the terms described above in the present application will be understood to those of ordinary skill in the art in the detailed description of the application.
An embodiment of the present invention provides an election method based on Raft protocol, specifically, referring to fig. 1, fig. 1 is a schematic flow chart showing an election method based on Raft protocol in one embodiment of the present invention, which includes steps S1 to S5:
S1, when a Redis cluster is in an election mode, converting a plurality of slave nodes into candidate nodes;
s2, each candidate node sequentially initiates an election request, and the current candidate node in each round of bidding can require other nodes except the current candidate node to vote on the current candidate node one by one;
S3, when the current voting node votes for the current candidate node, comparing the latest log submitting time of the current candidate node with the latest log submitting time of the current voting node;
s4, if the latest log submitting time of the current candidate node is later than the latest log submitting time of the current voting node, terminating the round of election, and converting the current voting node into an updated candidate node;
And S5, controlling the updating candidate node to continuously initiate an election request until the main node is elected.
The Raft protocol uses a heartbeat mechanism to trigger a leader election, e.g., when a server is started in a follower state, it will maintain the follower state when it can receive a valid RPC request from a leader or candidate. The Leader sends periodic heartbeats (APPENDENTRIES RPC without log) to all follow to ensure its authority, and when an exception occurs, it will assume that the Leader fails and start a new election.
To start a new election, the cluster randomly selects a plurality of slave nodes from a plurality of servers, converts the states of the slave nodes, and the selected follower raises its current term and converts the state into a candidate state. It will cast itself a ticket and then send an election request in parallel to the other servers in the cluster, and candidate will remain in this state until it wins the election itself, another server is established as a leader, or no winner occurs.
It should be noted that each server can vote for at most one candidate in a given term, and that the votes received for the majority of nodes are obtained first, ensuring that at most one leader can be selected in a term. Once a candidate wins the election, it becomes a leader. It will then send a heartbeat message to establish its own authority and prevent new elections. If candidate does not elect successfully or fails, candidate will timeout and trigger a new round of election, raising term and sending a new election request, if the vote is again divided, this will result in no server being established as a leader yet.
It follows that in extreme cases, the cluster will undergo multiple rounds of voting to select the master node, with a probability of nearly 50% that the master node cannot be selected each round. In order to shorten the whole election time, the inventor finds that, due to the reasons that the server state is abnormal or the network is unstable, the log length is smaller than that of other nodes, but the election process of the defective nodes is definitely nonsensical when the period is higher than that of the defective nodes of other nodes, so that in order to optimize the process of the election master node of the cluster, the embodiment of the invention immediately establishes the candidate node initiating the voting request as the defective node when the latest log submitting time of the candidate node initiating the voting request is found to be later than the latest log submitting time of the voting node by comparing the latest log submitting time, and at the moment, the election process of the defective nodes requiring the voting of other nodes is not continued one by one, the election process of the defective nodes is ended directly, the candidate qualification of the candidate node is deprived, the voting node is upgraded to the candidate node, and the subsequent election process is continued, in this way, the operation amount of the voting data is reduced, and the availability of the cluster is improved.
It should be noted that the leader can decide where to place the new log entry without querying other nodes, and that data always simply flows from the leader to other nodes. Therefore, in the case of a Leader abnormality or disconnection, the cluster needs to elect a new Leader, and in this embodiment, the Leader abnormality includes the following two cases:
Detecting that a master node does not exist in the Redis cluster, or that the period of the current master node is lower than the period of any slave node, under the two conditions, the cluster can stop normal work such as log receiving and transmitting replication, enter an election mode and elect a new master node.
Further, in the above embodiment, the election method based on Raft protocol further includes:
the slave nodes are controlled to enter a standby state, wherein the standby state lasts for any value between 150ms and 300ms, and of course, the duration of the standby state can be set according to the actual server cluster performance except the range, and the method is not limited herein. After standby, the free period of each node needs to be increased, so that the time sequence of the cluster is ensured, and the description is omitted.
Further, in this embodiment, after the candidate node requests the voting node to vote on itself, it is determined whether the candidate node has voting qualification, and if the latest log submission time of the current candidate node is earlier than the latest log submission time of the current voting node, the current voting node with a period and a log length smaller than those of the current candidate node is controlled to vote on the current candidate node.
In this embodiment, when the number of votes reaches a certain value, the votes are immediately converted into the master node at this time, and the competitive process is ended, specifically, if the number of votes of the current candidate node satisfies the following relation, the current candidate node is elected as the master node:
wherein a is the ticket number of the current candidate node, and b is the node number of the Redis cluster.
Specifically, referring to fig. 2, fig. 2 is a schematic flow chart of a special election link in one embodiment of the present invention, in this embodiment, after the voting node finds that the voting node has the latest log of the update and submits time, the voting node immediately converts to the update candidate node, and initiates an election voting request, where this request is referred to as a "special election request" in this embodiment, a special flag bit (IrregularVote) is attached to the request to indicate that the request is a special election request, and the sending time (RequestTime) information is sent this time, that is, the "special election request" is a request with a time flag bit, where the time flag bit reflects the conversion time of the update candidate node.
The object node receiving the special competitive choice request comprises two major classes, wherein one class is a common slave node, and the common slave node triggers a voting mechanism after receiving the special competitive choice request, votes to a candidate and then waits for a subsequent instruction; the other type is other candidate nodes, after the other candidate nodes receive the special competition request, whether the other candidate nodes send the special competition request or not is judged, if the special competition request is not sent, a voting mechanism is triggered, the other candidate nodes send the special competition request to the candidate nodes, the other candidate nodes can also be called update candidate nodes, a cluster compares time zone bits of the two update candidate nodes, the update candidate nodes with later time zone bits are controlled to vote to the update candidate nodes with earlier time zone bits, and all the votes of the update candidate nodes with later time zone bits are forwarded to the update candidate nodes with earlier time zone bits. Of course, for the whole cluster, the node that sends the "special competition request" earlier tends to be selected as the master node, so if the update candidate node that receives the "special competition request" finds that the time zone bit of the "special competition request" sent before itself is later, the currently received "special competition request" will be ignored, and the signal of the master node will be sent/waited for, which will not be described here again.
Since the normal workflow is interrupted when the cluster is in the election mode, the cluster in the election mode is in an unavailable state, and in this embodiment, after the master node is elected, the election mode is ended, and the Redis cluster is controlled to enter the normal mode, so that the availability of the cluster is optimized.
Another embodiment of the present invention provides a distributed system including a plurality of nodes, the nodes being dis servers operating in a cluster mode, and the nodes being divided into master nodes and slave nodes;
the distributed system is used for executing the competing method based on Raft protocol when the main node is abnormal.
In the above embodiment, the nodes include N master nodes and n×n slave nodes, and any one of the master nodes corresponds to N slave nodes, respectively. Of course, the number and the corresponding relation of the nodes need to be combined with the actual distributed system, and factors in aspects of disaster recovery, fault tolerance, network security of different places/local machine rooms and the like are considered, which are not described herein.
Accordingly, an embodiment of the present invention provides a computer readable storage medium, where the computer readable storage medium includes a stored computer program, where when the computer program runs, the device where the computer readable storage medium is controlled to execute steps in the method for electing based on Raft protocol according to the above embodiment, for example, steps S1 to S5 described in fig. 1.
The Raft protocol-based election method, the distributed system and the storage medium provided by the embodiment of the invention have the beneficial effects that at least one of the following is adopted:
When the Redis cluster is in an election mode, except for two parameters of a period of time for providing and a log length, each round of election initiated by the candidate node can require the candidate node and the voting node to provide the latest log submission time owned by the candidate node, after the voting node finds the latest log submission time owned by the self and updates, the cluster can immediately finish the round of election, and the voting node is converted into the updated candidate node to continuously initiate an election request.
While the foregoing is directed to the preferred embodiments of the present invention, it will be appreciated by those skilled in the art that changes and modifications may be made without departing from the principles of the invention, such changes and modifications are also intended to be within the scope of the invention.
Claims (8)
1. An election method based on Raft protocol, comprising:
When the Redis cluster is in an election mode, converting a plurality of slave nodes into candidate nodes;
Each candidate node sequentially initiates an election request, and the current candidate node in each round of bidding can require other nodes except the current candidate node to vote on the current candidate node one by one;
When a current voting node votes for the current candidate node, comparing the latest log submitting time of the current candidate node with the latest log submitting time of the current voting node;
If the latest log submitting time of the current candidate node is later than the latest log submitting time of the current voting node, terminating the round of election, and converting the current voting node into an updated candidate node;
controlling the updating candidate node to continuously initiate an election request until a main node is elected;
the competing method based on Raft protocol also comprises the following steps:
If detecting that the main node does not exist in the Redis cluster, controlling the Redis cluster to enter the election mode; or alternatively, the first and second heat exchangers may be,
If the period of the current master node is lower than the period of any slave node, controlling the current master node to be converted into the slave node, and controlling a Redis cluster to enter the election mode;
the competing method based on Raft protocol also comprises the following steps:
If at least two updating candidate nodes exist in the Redis cluster, each updating candidate node sequentially generates a special competitive choice request with a time zone bit, wherein the time zone bit reflects the conversion time of the updating candidate node;
comparing the time zone bit of the two updating candidate nodes, controlling the updating candidate node with the later time zone bit to vote to the updating candidate node with the earlier time zone bit, and
And forwarding all the ticket numbers of the updating candidate nodes with the later time zone bits to the updating candidate nodes with the earlier time zone bits.
2. The method of claim 1, wherein prior to said converting a plurality of slave nodes to candidate nodes, said method further comprises:
and controlling each slave node to enter a standby state, wherein the standby state lasts 150 ms-300 ms.
3. The method of claim 1, wherein if the current candidate node's latest log submission time is earlier than the current voting node's latest log submission time, controlling the current voting node whose tenure and log length are less than the current candidate node to vote on the current candidate node.
4. The method of claim 1, wherein the current candidate node is elected as the master node if its ticket number satisfies the following relationship:
wherein a is the ticket number of the current candidate node, and b is the node number of the Redis cluster.
5. The method for election based on Raft protocol of claim 1 wherein upon electing a master node, ending the election mode and controlling the dis cluster to enter a normal mode.
6. A distributed system comprising a plurality of nodes, the nodes being dis servers operating in a cluster mode and the nodes being divided into master and slave nodes;
The distributed system is used for executing the competing method based on Raft protocol according to any one of claims 1-5 when the main node is abnormal.
7. The distributed system of claim 6 wherein the nodes include N master nodes and N x N slave nodes, any one master node corresponding to each N slave nodes.
8. A computer readable storage medium, wherein the computer readable storage medium stores a computer program, and wherein the computer program when executed controls a device in which the computer readable storage medium is located to perform the Raft protocol-based election method according to any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111409153.8A CN114268532B (en) | 2021-11-24 | 2021-11-24 | Games method based on Raft protocol, distributed system and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111409153.8A CN114268532B (en) | 2021-11-24 | 2021-11-24 | Games method based on Raft protocol, distributed system and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114268532A CN114268532A (en) | 2022-04-01 |
| CN114268532B true CN114268532B (en) | 2024-08-30 |
Family
ID=80825517
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111409153.8A Active CN114268532B (en) | 2021-11-24 | 2021-11-24 | Games method based on Raft protocol, distributed system and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114268532B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114448769B (en) * | 2022-04-02 | 2022-07-01 | 支付宝(杭州)信息技术有限公司 | Node election voting method and device based on consensus system |
| CN114844891B (en) * | 2022-04-21 | 2024-04-12 | 浪潮云信息技术股份公司 | Block chain consensus method and system based on Raft algorithm |
| CN115002116A (en) * | 2022-05-30 | 2022-09-02 | 紫光建筑云科技(重庆)有限公司 | Distributed redis cluster on cloud platform and reliability detection method |
| CN115051913B (en) * | 2022-08-12 | 2022-10-28 | 杭州悦数科技有限公司 | Method and device for changing Raft configuration |
| CN115794478B (en) * | 2023-02-06 | 2023-06-23 | 天翼云科技有限公司 | System configuration method, device, electronic equipment and storage medium |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107105032A (en) * | 2017-04-20 | 2017-08-29 | 腾讯科技（深圳）有限公司 | node device operation method and node device |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107528710B (en) * | 2016-06-22 | 2021-08-20 | 华为技术有限公司 | Method, equipment and system for switching leader nodes of raft distributed system |
| CN106656624B (en) * | 2017-01-04 | 2019-05-14 | 合肥康捷信息科技有限公司 | Optimization method based on Gossip communication protocol and Raft election algorithm |
| CN108616566B (en) * | 2018-03-14 | 2021-02-23 | 华为技术有限公司 | Main selection method of raft distributed system, related equipment and system |
| CN112202834B (en) * | 2020-09-03 | 2024-04-23 | 金证财富南京科技有限公司 | Data processing method, data processing device and node server |
| CN112261135A (en) * | 2020-10-22 | 2021-01-22 | 腾讯科技（深圳）有限公司 | Node election method, system, device and equipment based on consistency protocol |
-
2021
- 2021-11-24 CN CN202111409153.8A patent/CN114268532B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107105032A (en) * | 2017-04-20 | 2017-08-29 | 腾讯科技（深圳）有限公司 | node device operation method and node device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114268532A (en) | 2022-04-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114268532B (en) | Games method based on Raft protocol, distributed system and storage medium | |
| CN108616566B (en) | Main selection method of raft distributed system, related equipment and system | |
| US10614098B2 (en) | System and method for determining consensus within a distributed database | |
| US10346430B2 (en) | System and method for determining consensus within a distributed database | |
| CN111475576B (en) | Block chain-based distributed database storage method and system | |
| US7856480B2 (en) | Method and apparatus for exchanging heartbeat messages and configuration information between nodes operating in a master-slave configuration | |
| US7478114B2 (en) | Failure tolerant transaction processing system | |
| US7035858B2 (en) | System and method dynamic cluster membership in a distributed data system | |
| US7139925B2 (en) | System and method for dynamic cluster adjustment to node failures in a distributed data system | |
| US8700760B2 (en) | Method and systems for redundant server automatic failover | |
| US7024483B2 (en) | System and method for topology manager employing finite state automata for dynamic cluster formation | |
| EP3326065B1 (en) | Leaderless consistency protocol | |
| US20050132154A1 (en) | Reliable leader election in storage area network | |
| US8583958B2 (en) | Systems and methods of providing fast leader elections in distributed systems of simple topologies | |
| CN112328421B (en) | System fault processing method and device, computer equipment and storage medium | |
| CN115102839B (en) | Master-slave node election method, device, equipment and medium | |
| CN112799867B (en) | Election method based on distributed storage system and distributed storage system | |
| CN115277712B (en) | Distributed lock service providing method, device and system and electronic equipment | |
| CN110635941A (en) | Database node cluster fault migration method and device | |
| CN114172680A (en) | Block chain system based on node credit mechanism and operation method thereof | |
| Choumas et al. | When raft meets SDN: How to elect a leader over a network | |
| CN109412940B (en) | Router management method and router management system | |
| CN112367373B (en) | Node determination method and device for distributed system and storage medium | |
| CN116107706A (en) | Transaction processing method and device of distributed database, electronic equipment and storage medium | |
| CN117061519A (en) | Main node election method and device of target cluster and electronic equipment |
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 |