A step-by-step understanding of the Paxos algorithm

A step-by-step understanding of the Paxos algorithm

background

Paxos algorithm is a kind of consistency algorithm based on message passing in Lamport in 1990. Because the algorithm is difficult to understand at first did not arouse people's attention, so that lamport in eight years after the re-published to the TOCs. Even so the Paxos algorithm is not paid attention to, 2001 Lamport with the more readable descriptive language to give the algorithm description. It can be seen that Lamport has a unique feeling for Paxos algorithm. In recent years, the general use of Paxos algorithm has proved its important position in distributed consistency algorithm. 06 Google's three papers at the beginning of the "cloud", wherein the chubby lock service using Paxos as a chubby cell consistency algorithm, Paxos's popularity from now on all the way.

What is Paxos?

The problem solved by the Paxos algorithm is how a distributed system can agree on a value (resolution). A typical scenario is that in a distributed database system, if the initial state of each node is consistent, each node executes the same sequence of operations, then they can finally get a consistent state. To ensure that each node executes the same sequence of commands, it is important to implement a "consistency algorithm" on each instruction to ensure that each node sees the same instructions.

Two principles of Paxos safety principles---guarantee that you can't do anything wrong.

1. Only one value can be approved and the second value cannot appear the first coverage case

2. Each node can only learn the values that have been approved and cannot learn the values that are not approved

The survival principle---as long as most servers survive and communicate with each other eventually.

1. A proposed value will eventually be approved

2. One value is approved, and the other server will eventually learn this value

Paxos's two components proposer

The proposed initiator, which processes the client request, sends the client's request to the cluster in order to determine whether the value can be approved.

Acceptor

The proposed approver is responsible for handling the received proposals, and their response is a vote. Stores some state to decide whether to receive a value

Paxos definition

The next step in an example is to explain some of the problems that Paxos must solve in order to achieve consistency. Here for the convenience of explanation, assume that each server is a proposer, is also a acceptor

A acceptor

Start with the simplest way, assuming there is only one acceptor, let it decide whether to approve a value

For example, each proposer proposes a value for acceptor to approve, and then acceptor approves a value as the final value.

But this simple way, there is no way to solve the problem of acceptor crash, if the only acceptor crash, there is no way to know which value is selected, you need to wait for it to restart, this is a violation of the principle of survival, this time there are 4 servers to survive, But there's no way to work anymore.

Multiple acceptor

In order to solve this problem, it is necessary to use a method of most choices. Use a collection of acceptor. Then only the majority of them approve a value, and this value can indeed be finally approved. Some skills are needed to achieve the goal.

Approve the first reached value

First, specify that each acceptor must approve the first arriving value. Which value reaches most approvals is the final approved value

But there is a problem, for example, because no value is approved by the majority, and a final value cannot be approved. This requires acceptor to approve a value and then approve the different values according to a certain rule.

back to topApprove the value of each proposal

The next step is to acceptor approve each proposed value, but this also poses a problem that multiple values may be approved

, S1 issued a proposal that S1,S2,S3 approved red as the final approved value. S5 subsequently issued a proposal, S3,S4,S5 approval, and blue for the final approval of the value. At this point S1,s2 finally approves the RED,S3,S4,S5 final approval of blue, which violates our principle of consistency and ultimately only one value is chosen.

back to topTwo paragraph submission principle

To solve this problem, it is necessary to S5 before sending its own proposal, first check whether there are already approved values, if there should be proposed already approved values and discard their values, that is, to abandon their own blue to propose red, so that ultimately only one value is approved is red. This is the classic two-paragraph submission principle.

Unfortunately, there is another problem with the two-paragraph submission.

, S1 check that no value was approved before sending the offer, so suggest red. But at the same time before all acceptor approved, S5 also to make proposals, this time also check out no value was approved, so it also sent their blue as a proposal to acceptor. Next S5 's proposal reached S3,s4,s5, the acceptor first approved blue, and the majority so blue was finally approved. But then S1,S2,S3 received red for approval. So there's a problem with approving multiple values.

back to topProposal sort

To solve this problem, the other conflicting values should be rejected once acceptor has approved a value. That is to say, the red that S3 then arrives should be rejected in order to do this. The proposer needs to be sorted, sorted before the high priority is given, the acceptor approves the high priority value, and the value is rejected after sorting.

In order to sort the proposals, each proposal can be given a unique ID, which specifies that the higher the ID, the higher the priority

Before the proposer sends the proposal, it needs to generate a unique ID, and it needs to be larger than previously used or generated.

Proposed ID generation algorithm

In Google's chubby paper, there is a way to assume that there are n proposer, each with a number of IR (0<=ir<n), and that any value of the proposor number should be greater than the maximum value it knows, and satisfies: s%n = IR = = M*n + IR

Proposer the maximum known value is from two parts: Proposer own value after the number increment and the reject received after acceptor

Take 3 proposer P1, P2, P3 for example, start m=0, numbering 0,1,2 respectively

1. P1 submitted the time found P2 has been submitted, P2 number 1 > P1 0, so P1 recalculate number: new P1 = 1*3+0 = 4

2. P3 was submitted with number 2 and found 4 less than P1, so P3 re-numbered: new P3 = 1*3+2 = 5

Paxos algorithm

To this stage, to ensure that the Paxos of the two principles have been satisfied, Paxos also smoothly achieved.

Two-paragraph submissionback to topPrepare stage:

1. Proposer Select a proposal number n and send the prepare request to a majority in acceptors;

2. Acceptor receives the prepare message, if the proposal has a number greater than all of the prepare messages it has replied to, Acceptor replies to Proposer's last accepted proposal and commits to no longer respond to proposals less than N;

back to topAcceptor stage:

1. When a proposer receives a response from most acceptors to prepare, it enters the approval phase. It sends an accept request to the acceptors that responds to the prepare request, including the number n and the value determined by the prepare stage (if no value has been accepted based on the prepare, then it is free to determine value).

2. Without violating its commitments to other proposer, Acceptor accepts the request upon receipt of the request.

The prepare stage has two purposes, the first check whether there is a value approved, and if so, the approved value is used instead. Second, if the previous proposal has not been approved, then block them so that they do not compete with us, but ultimately by the size of the proposal ID. The whole process such as

A step-by-step understanding of the Paxos algorithm