What are the advantages of the raft algorithm compared to the Paxos algorithm, and what are the differences in usage scenarios? _paxos

The raft protocol is easier to understand and easier to implement than the Paxos advantage. It strengthens the position of leader, divides the whole protocol into two parts clearly, and makes some simplification by using the continuity of the log: (1) leader. By leader to the follower synchronization log (2) leader hung up, select a new leader,leader election algorithm.

But in essence, it is easy to place the process clear, the description is clearer, the key is to give a description of the pseudo-code level, can be directly used for implementation, and Paxos's original description is for the very theoretical consistency problem, really can be applied to engineering implementation of the Mulit-paxos, Lamport Grandpa made a ballpark figure, and then someone tried to make a more complete and detailed description of the Multi-paxos, but everyone described it in a very different way.

Zookeeper's zab,viewstamped Replication (VR), Raft,multi-paxos, can be called the leader-based consistency protocol. The difference is that Multi-paxos leader is proposed as an optimization of classical Paxos, by choosing a proposer as leader to reduce the frequency of conflicts caused by multiple proposer, merging phase one to reduce the average message cost of a resolution to the optimal two times, In fact, even if there are multiple leader exist, the algorithm is still safe, but degenerate into the classical Paxos algorithm. And the classic Paxos, from a proposal to be accepted into two stages, the first stage to ask for the value, the second stage according to the results of the query proposed value. These two stages are inseparable, each of the two stages of each detail is carefully designed, interrelated, together to ensure the consistency of the agreement. These vr,zab,raft, which emphasize the uniqueness of legal leader, directly describe the process of the Protocol from the point of view of leader, and demonstrate correctness from the angle of leader. But in fact they use exactly the same principle as Paxos to ensure the security of the Protocol, when there are multiple nodes at the same time to try to become leader or do not know a node to think of themselves when leader, in essence, they and the classical paxos of many proposer coexist in the situation is no different.

Paxos and raft are all once a entries (raft protocol called the log, Paxos called a proposal, call it) to get the majority of the favor, this entries will be fixed, not lost, the value does not change, eventually all nodes will agree to it. Paxos called the proposal was decided, RAFT,ZAB,VR called the log to be submitted, which is just a matter of saying. Once a log is submitted (or decided), it is not lost and cannot be changed, and the 4 agreements are consistent. Multi-paxos and raft all use a number to identify the legitimacy of leader, Multi-paxos called Proposer-id,raft called term, meaning is the same, Multi-paxos Proposer-id the biggest leader proposed resolution is valid, raft agreement term the biggest leader is legal. In fact, raft agreement in the leader election phase, because the old leader may also survive, there will be more than one leader situation, but there is no term the same two leader, because the electoral algorithm requires leader get the same term majority of the agreement, Members who agree will promise not to accept any message that term is smaller. This can be based on term size to distinguish who is the legal leader. Multi-paxos's legal strategy of distinguishing leader is the same, whose proproser-id is the most legitimate, and Proposer-id is the only one. So they are in fact at the same moment, there will only be a legal leader. At the same time, the leader election algorithm for the Raft protocol, the newly elected leader already has all the logs that can be submitted, and Multi-paxos does not need to guarantee this, which means that Multi-paxos requires additional processes to obtain the submitted logs from other nodes. Therefore, the raft protocol log can simply flow from leader to follower in the raft protocol, while Multi-paxos requires additional process completion of the submitted log. Note that the log can be submitted and the log has been submitted is two concepts, the difference is like I have a stone ahead and I learned that I have a stone ahead. But in fact, raft and Multi-paxos once the log can be submitted, can guarantee that it will not be lost, multi-paxos naturally guaranteed this, which is why the new leader for the log that has not been confirmed has been submitted to the need to perform the classic Paxos phase one, To complement all the potentially missing logs that have been submitted, the raft protocol first submits a no-op log of this term by forcing the new leader, in conjunction with the nature guaranteed by the leader election algorithm mentioned earlier,Make sure of that. Once a log is written to the local log file by a majority node, it can be submitted, but leader will only be able to commit the log when it is known, but the log is already submitted.

The raft protocol emphasizes the continuity of the log, and Multi-paxos allows the log to be empty. The continuity of the log contains such a property: If two different nodes on the same number of logs, as long as term the same, then the two logs must be the same, and this is the same as the previous log, which makes leader want to follower synchronization log, compared to the log is very fast and convenient At the same time, the raft protocol in the log of the commit (submission) is also continuous, a log was submitted, representing the log before all the logs have been submitted, a log can be submitted, representatives of all previous logs can be submitted. The continuity of the log makes it very simple to know the log of a node in the raft protocol, just to get the serial number and term of its last log. Can give an example, A,b,c three machines, C is leader,term is 3,a tell c their last log serial number is 4,term is 3, then C know that a must have a serial number of 1,2,3,4 log, and C in the serial number for the 1,2,3,4 of the same, This is emphasized by the continuity of the Raft protocol log, well then leader know that the log 1,2,3,4 has been owned by the majority (A,C) and can be submitted. At the same time, this also guarantees the raft agreement in the leader election, a majority must have a node has all the submitted logs, this is because the last committed log, at least by the majority record, and due to the continuity of the log, A log with the last commit also means that there is a full commit log, that is, at least one majority has all the commit logs. And only need to choose from a majority of the last log term the largest and the largest number of nodes as leader, the new leader must have all the committed log (the argument on this point, you can think through contradiction, Most central Node A has the last commit log, but B is not, and B is elected leader. According to the law of the elect, there can be only two possibilities (1) The term of the last log is less than B; (2) a The last log is term equal to B, but the log of a is less than B. 1,2 maybe. For Multi-paxos, the log is empty, and each log needs to be individually confirmed as a commit or as a separate commit. So when the new leader is generated, it has to reconfirm each uncommitted log, determine if they can be committed, or even the new leader may be missing the log that can be submitted, and need to learn through the Paxos phase of the other nodes to the missing log that can be submitted, Of course, this can be done by asking a majority to do it (this process has a great space for optimization, for exampleIf you can merge this process into the leader election phase, you can combine confirmation and learning of all the logs into a round of messages, reducing the number of messages, and so on. However, both raft and Multi-paxos, the new leader for those uncommitted logs, need to resubmit, cannot be overridden, because neither can determine whether these uncommitted logs have been submitted by the previous leader. So essentially, the two are the same. A log is owned by the majority, then it can be submitted, but leader needs to know this in some way, and the new leader needs to have all the logs submitted (or can be submitted) in order for the logs that have been submitted not to be overridden by the new leader. Because sometimes there is no way to know whether a log can be submitted has been submitted, for example, when only the old leader submitted the log, and returned to the client successfully, but the old leader hang up, then the normal work, and need to resubmit all uncommitted logs. The difference between the two is that leader confirm submitting and fetching all the methods that can be submitted to the log, and the way the difference is due to the continuous log, the raft protocol simplifies the process by using log continuity.

In the principle of raft and Multi-paxos protocols to ensure security, it goes a step further, all the algorithms that meet the number of nodes that are alive in the cluster can also constitute a majority, consistency can satisfy the algorithm, raft protocol, Paxos,zab, Viewstamp all use the same property: There is a public member between two majority sets. For a consistency protocol, once the value of a variable is determined, the value of the variable should be unique and no longer changed. Raft,paoxos and other protocols, for a variable V, a N1 proposed by the node is only a number of Q1 recognized and recorded, will formally make v=a, if the other node N2 want to modify the value of the variable V is B, also need a number of sets Q2 recognition, While Q1 and Q2 must have at least one common member p, node p has been recorded in V=a. So just by adding a few constraints, let P be able to tell the node N2 This fact: v=a, make N2 give up their offer, or let the node P reject the node N2 to give v the value of B This behavior, all can ensure that the consistency of the variable v is not broken. This idea is the same for the four Protocols, and 4 protocols use a unique integer as an identifier to indicate the legality of the leader, Paxos called Proposer-id,zab Epoch,vr called View,raft. Think of leader as a node that wants to give a value to a variable v n1,n2, in the case mentioned above, if N2 is the current legitimate leader, then N2 needs to know v=a this fact, for raft is to choose N2 is the node that has recorded V=a, For Multi-paxos, the value of the next V is reconfirmed. If N1 is the current legal leader,n2 is the old leader,p will reject the N2 proposal according to the leader identifier, the N2 proposal will be invalidated by the lack of a majority acceptance. The most direct theoretical explanation of this principle is the classical Paxos algorithm, the more specific elaboration of this principle can see how I explain the Paxos algorithm in a straightforward way. Under the answer. So it is true that, to some extent, RAFT,ZAB,VR are an improvement of the Paxos algorithm, a simplification, an optimization, a representational. Lamport old people or Diao Diao Diao ... It is worth mentioning, however, that the authors of Zab and raft are indeed inspired by the Paxos that VR is almost simultaneously independent of Paxos.

Raft is easy to implement in that its description is very normative and includes all the implementation details. As the above people say is like pseudo code. And the description of Paxos focus on the theory, the project to achieve according to Google Chubby in the paper, everyone from the Paxos appeared, wrote, dealing with the details of the actual n many, has become another algorithm, this time the correctness of the theory can not be guaranteed. So it's very difficult to implement because the consistency protocol is very subtle. In small detail, the consistency of the entire agreement collapses, and the discovery and correction of details is difficult without exhaustive reference, which requires a deep understanding of the agreement. and consensus:bridging theory and PRACTICE, a doctoral dissertation in the Raft agreement, taught you how to use the raft protocol to build a replication state machine. I mean, college students with a normal IQ can read. I believe that in the future consistency is brought up now, certainly not now, most people find it difficult ah, to achieve more difficult .... Should be a common technique.

https://www.zhihu.com/question/36648084