"Reprint" distributed series article--paxos algorithm principle and derivation

Reprint: http://linbingdong.com/2017/04/17/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0%E2%80%94% e2%80%94paxos%e7%ae%97%e6%b3%95%e5%8e%9f%e7%90%86%e4%b8%8e%e6%8e%a8%e5%af%bc/

The Paxos algorithm has a very important position in the distributed field. But the Paxos algorithm has two obvious drawbacks: 1. Difficult to understand 2. Engineering is more difficult to achieve.

There are many articles on the Internet that explain the Paxos algorithm, but the quality is uneven. Read a lot of information about Paxos found that learning Paxos the best information is the paper "Paxos Made Simple", followed by the Chinese and English version of Wikipedia on the introduction of Paxos. This article attempts to take everyone step by step to uncover Paxos mysterious veil.

What is Paxos?

Paxos algorithm is one of the most effective algorithms to solve the distributed consistency problem, which is based on the message-passing and highly fault-tolerant consistency algorithm .

Google Chubby author Mike Burrows said there is only one consistency algorithm in the world, that is Paxos, the other algorithms are defective .

Although Mike Burrows is a bit exaggerated, at least it illustrates the position of the Paxos algorithm. However, the Paxos algorithm is notorious for its arcane and obscure knowledge. The purpose of this article is to lead everyone to understand the Paxos algorithm, not only understand its implementation process, but also understand the derivation process of the algorithm, the author is how step by step thinking of the final plan. Only by understanding the derivation process can we grasp the essence of the algorithm deeply. and understanding the derivation process for our thinking is also very helpful, may bring us some ideas to solve the problem, we have some inspiration.

The context in which the problem arises

In common distributed systems, there will always be situations such as machine downtime or network anomalies (including message latency, loss, duplication, chaos, and network partitioning). The problem that the Paxos algorithm needs to solve is how to agree the value of a data within the cluster quickly and correctly in a distributed system where the above anomalies occur, and ensure that no matter what happens above, it will not compromise the consistency of the whole system.

Note: the value of some data here is not just a certain number in the narrow sense, it can be a log, or it can be a command ... Depending on the scenario, the value of a data has a different meaning.

The context in which the problem arises

Related concepts

In the Paxos algorithm, there are three types of roles:

• Proposer
• Acceptor
• Learners

In a specific implementation, a process may act as multiple roles at the same time . For example, a process may be both proposer and acceptor and learner.

There is also a very important concept called the proposal (proposal). The final agreed value is in the proposal.

Note:

• Consider, for the moment, " proposal =value", i.e. the proposal contains only value. In our next derivation we will find that if the proposal contains only value, there will be a problem, so we re-design the proposal.
• for the moment, "proposer can make proposals directly ". In our next derivation, we will find that if proposer directly raises a proposal, there is a need to add a learning proposal process.

Proposer can propose (propose) a proposal, acceptor can accept the proposal, and if a proposal is selected (chosen), then the value of the proposal is selected.

Go back to just saying "agree on the value of a certain data", meaning that proposer, acceptor, and learner all think the same value is selected (chosen). So, under what circumstances can proposer, acceptor, and learner consider a value to be selected?

• Proposer: As long as the proposer proposal is acceptor accepted (first think only need a acceptor to accept, in the derivation process will find that more than half of the acceptor agreed to), Proposer that the value in the proposal was chosen.
• Acceptor: As long as acceptor accepted a proposal, acceptor thought the value in the proposal had been chosen.
• Learner:acceptor tells learner which value is selected, learner thinks that value is selected.

Related concepts

Problem description

Suppose there is a set of processes that can present (propose) value(value in the proposal proposal). A consistency algorithm needs to ensure that so much of the value is raised that only one value is selected (chosen). If no value is raised, no value should be selected. If a value is selected, then all processes should be able to learn (learn) to this selected value. For the consistency algorithm, the security (safaty) requirements are as follows:

• Only the value presented can be selected.
• Only one value is selected, and
• If a process considers a value to be selected, then this value must be the one that is really selected.

We do not define its activity (liveness) requirements precisely. Our goal is to ensure that eventually there is a proposed value selected . When a value is selected, the process can eventually learn the value.

The goal of Paxos is to ensure that eventually a value is selected, and the process can eventually get to the selected value when value is selected.

Assuming that different roles can communicate by sending messages, then:

• Each role executes at any speed, may be stopped by an error, or may be restarted. After a value is selected, all roles may fail and then restart, unless the role that restarts after the failure can log some information, or the selected value cannot be determined after they restart.
• Messages may be delayed for any length of time during delivery, may be duplicated, or may be lost. But the message will not be corrupted, that is, the message content will not be tampered with (Byzantine general problem).

The simplest solution to the derivation process--only one acceptor

Assuming that there is only one acceptor (can have multiple proposer), as long as Acceptor accepts the first proposal it receives, the proposal is selected and value in the proposal is the selected value. This guarantees that only one value will be selected.

However, if the only acceptor down, then the whole system will not work !

Therefore, there must be more than one acceptor!

There's only one acceptor.

Multiple acceptor

Multiple acceptor situations such as. So, how do you ensure that you select a value in multiple proposer and multiple acceptor cases?

Multiple acceptor

Start looking for a solution below.

If we want even one proposer to present a value, the value is eventually selected.

Then, you get the following constraint:

P1: A acceptor must accept the first proposal it received.

However, this leads to another problem: if each proposer is presented with a different value, it is sent to a different acceptor. The value received by P1,acceptor, respectively, causes the different value to be selected. There was an inconsistency. Such as:

Slide 08.png

Just because "a proposal is accepted by a acceptor, then the value of the proposal is chosen" has led to an inconsistency of the above problem. Therefore, we need to add a provision:

Rule: A proposal is selected to be accepted by more than half of the acceptor

The rule also implies: "A acceptor must be able to accept more than one proposal!" "Otherwise it may result in no value being selected. such as the situation. V1, v2, and V3 were not chosen because they were only accepted by one acceptor.

The initial " proposal =value" was unable to meet the demand, so the proposal was redesigned to include a proposal number for each proposal, indicating the order in which the proposal was presented. " proposal = Proposal Number +value".

Although multiple proposals are allowed to be selected, it is important to ensure that all selected proposals have the same value values. Otherwise there will be inconsistencies.

The following constraints are then available:

P2: If a proposal for a value of V is selected, then the value of each higher-numbered selected proposal must also be v.

A proposal may be selected only if it is accepted by acceptor, so we can rewrite the P2 constraint as a constraint on the acceptor acceptance of the proposal P2A.

P2A: If a proposal for a value of V is selected, the value of the proposal that is acceptor accepted by a higher number must also be v.

As long as the P2A is satisfied, the P2 can be satisfied.

However, consider the following scenario: Assume that there is a total of 5 acceptor. Proposer2 proposed [M1,V1], acceptor2~5 (more than half) accepted the proposal, so for acceptor2~5 and Proposer2, they all thought V1 was selected. Acceptor1 had just recovered from the outage (before Acceptor1 had received no proposal), and Proposer1 sent a proposal to Acceptor1 (M2,V2 and V2≠v1), for M2>M1, That was the first proposal it had received. According to P1 (a acceptor must accept the first proposal it received.) ), Acceptor1 must accept the proposal! At the same time Acceptor1 thought that V2 was designated. There are two questions:

1. Acceptor1 thought that V2 was designated, acceptor2~5 and Proposer2 thought V1 was designated. There was an inconsistency.
2. V1 was selected, but the higher-numbered Acceptor1 accepted proposal [M2,V2] of the value of V2, and V2≠V1. This is with P2A (if a proposal of value V is selected, the value of each higher-numbered acceptor-accepted proposal must also be V) contradictory.

Slide 10.png

So we need to strengthen the P2A constraint!

P2A is binding on the proposal accepted by acceptor, but in fact the proposal is proposer, and all of us can constrain the proposal made by proposer. Get P2B:

P2B: If a proposal for a value of V is selected, then the value of any proposer proposed higher number must also be v.

By P2B can be launched P2A and then launched P2.

So, how do you make sure that when a proposal with a value of V is selected, the value of the higher-numbered proposal that proposer raises is V?

As long as you meet P2C:

P2C: for arbitrary N and V, if the proposal [N, v] is presented, then there is a set of more than half of the acceptor consisting of s, which satisfies any of the following two conditions:

• Each acceptor in S has not received a proposal with a number less than N.
• The value of the proposed maximum number of acceptor received in S is v.

Proposer generate proposal

In order to satisfy the P2B, there is a more important idea: before proposer generates a proposal, it should first "Learn" the value that has been selected or may be selected, and then use that value as the value of the proposed proposal. If no value is selected, proposer can determine the value for itself. So that we can agree. This stage of learning is achieved through a "prepare request" .

So we got the following proposal generation algorithm :

1. Proposer selects a new proposal number nand then sends a request to a acceptor collection (more than half), requiring each acceptor in the collection to respond as follows (response).
   (a) commitment to proposer to ensure that no proposal of any number less than n is accepted .
   (b) If Acceptor has already accepted the proposal, it responds to the proposal that the Proposer has accepted a maximum number that is less than N.

   We refer to this request as a prepare request with number n .

2. If proposer receives more than half of the acceptor response , it can generate a proposal with a number of n,value to V [n,v]. Here V is the value of the proposal that has the largest numberin the response. If there is no proposal in all responses, then v can be selected by proposer.
   After the proposal was generated, proposer sent the proposal to more than half of the acceptor collection and expected the acceptor to accept the proposal. We call this request an accept request . (Note: The Acceptor collection that accepts the accept request at this time is not necessarily the acceptor collection that previously responded to the prepare request)

Acceptor accept the proposal

Acceptor can ignore any requests (including prepare requests and accept requests) without worrying about the security of the destruction algorithm. So, what we're going to discuss here is when acceptor can respond to a request.

We are bound by the acceptor acceptance of the proposal as follows:

P1a: A acceptor, as long as it has not yet responded to any prepare request with a number greater than n , then he can accept the proposal with the number n .

If Acceptor receives a prepare request with number N, it has previously responded to a prepare request with a number greater than N. According to P1a, the acceptor is unlikely to accept a proposal numbered N. Therefore, the acceptor can ignore prepare requests that are numbered n. Of course, you can also reply to an error, let proposer early know that his proposal will not be accepted.

So, a acceptor just remember : 1. Proposal 2 with the largest number accepted. The maximum number of requests that have been responded to.

Small optimization

Paxos algorithm Description

After the above deduction, we summarize the process of the Paxos algorithm.

The Paxos algorithm is divided into two stages . Specific as follows:

• Phase One:

  (a) Proposer selects a proposal number nand then sends a prepare request with a number of N to more than half of the acceptor.

  (b) If a acceptor receives a prepare request with number n, and N is greater than the number of all prepare requests that the acceptor has responded to, then it will have The largest-numbered proposal, if any, was received as a response to proposer, while the acceptor promised not to accept any proposal with a number less than n .

• Stage Two:

  (a) If proposer receives more than half of Acceptor's response to a prepare request with a number N issued, it sends a proposal for [n,v] Accept requests to more than half of the acceptor. Note: V is the value of the proposal with the largest numberin the received response , and if no proposal is included in the response, then V is determined by proposer itself .

  (b) If Acceptor receives an accept request for a proposal of number N, as long as the acceptor has not responded to a prepare request with a number greater than n , it accepted the proposal .

Paxos algorithm Flow

Learner Learning the selected value

Learner Learning (Acquisition) The selected value has the following three scenarios:

Slide 17.png

How to ensure the activity of Paxos algorithm

Slide 18.png

By selecting the main proposer, the activity of the Paxos algorithm can be ensured. At this point, we get a distributed consistency algorithm --Paxos algorithm , which can guarantee the security and ensure the activity .

Resources

• Paper "Paxos Made Simple"
• Paper "The Part-time Parliament"
• The English version of Wikipedia Paxos
• Paxos of the Chinese version of Wikipedia
• Books from Paxos to zookeeper

"Reprint" distributed series article--paxos algorithm principle and derivation