What is Paxos?
The Paxos algorithm is a consistent algorithm based on message passing and highly fault-tolerant. Chubby's design developer Burrows once said that all consistency protocols are essentially Paxos or variants of them.
What is Paxos used to solve?
In common distributed systems, situations such as machine downtime or network anomalies will always occur, which will result in failure to send messages and duplicate messages that disappear. The Paxos algorithm mainly solves these problems, that is, in a distributed environment, how to quickly reach agreement on a certain value and a certain data within the cluster to ensure the consistency of the entire system.
Paxos proposed
Lamport proposed a theoretical consistency solution in 1990, and at the same time gave a rigorous mathematical proof. To describe the algorithm, he virtualized a Greek island called Paxos. The island adopted a decree to pass the decree. The members of the parliament passed the messenger to transmit the message. Both the parliamentarian and the letter history were part-time. It may leave the parliament hall, and the history of the letter may repeat the message or it may never return. It is assumed here that there is no Byzantine general problem, that is, the message will not be tampered with. In such an environment, through the parliamentary agreement, a decree can still be guaranteed Will be passed and accepted by all MPs.
The principle and content of Paxos
What is consistency achieved through Paxos? Let's understand through an example in a university dormitory.
The four roommates in the bedroom want to have a group activity in the afternoon, so they need to agree on what to do.
Roommate A first proposed: "Let's go to the movies!"
Roommate B felt good, agreeing: "Well, yes, go to the movies."
At this time, Roommate C, who was playing the game, didn't hear the conversation between the two, and suddenly Say: "Let ’s go to dinner."
Roommate D agrees: "Yes, let ’s go to dinner."
To reach an agreement, some people have to change their minds, so Roommate B shakes first. Roommate A takes a look. , The minority obey the majority, let's go to dinner. In this way, the four roommates reached an agreement.
Here we can see the following points,
- Consistency is to get a unique result.
- Consistency follows the principle that the minority follows the majority.
- In the end everyone knew what was agreed.
- Everyone may agree on any one result, not necessarily their proposal.
- An error may occur between communications, that is, the message may be lost.
Why does the system need consistency?
Suppose you are working at home, you set up a server, and make it open, others will come to visit it, it looks very good. But as more and more people use it, your server is getting slower and slower, and your resources are not enough, so you upgraded the RAM and CPU, but the same thing happened, because for a single machine there is no Endless resources.
So you have to think of something else.
Method one is the master copy mode , where one node is the master node and the rest are replicas. Once someone wants to write a value, he will tell the master node that the master node will serialize the different proposals and pass them to the copy, so that the data will be written to each node.
Or you can consider a point-to-point model , where all nodes are the same. When they want to propose a new value, they pass the proposal to other nodes to reach agreement on the next topic, and then each node will respond to it.
For the first mode, if there is a problem with the master node, you need to select another master node in the copy, otherwise the entire system will crash. In the second mode, all nodes must continuously reach agreement to ensure that all operations are consistent everywhere.
Let ’s take a look at the basic principles of Paxos.
First, let ’s first understand the basic concept
ID in Paxos : Proposal number that does not conflict with each other
Value :
Proposer : Proposer , the content of the proposal: ID + value, for the same round of proposals, up to Propose a value. Acceptor : There are N proponents. Proposer's x = value proposal must be accepted by more than half (N / 2 + 1) Acceptor before being accepted.
Learner : Proposal learner. A proposal can be accepted if more than half of Accpetor passes, and other undetermined Acceptors can synchronize the results through the learner.
specific process
Proposer
perspective at the pre-proposal stage : Proposer selects a proposal number n and broadcasts Prepare n requests to all Acceptors.
Proponent's perspective : Acceptor receives a Prepare n request. If the proposal number n is larger than the previous request, it promises that it will not receive proposals with a proposal number smaller than n, and attach the previous Accept proposal with a number less than n. The value of the largest proposal. If n is smaller than the previously accepted proposal number, it will be ignored.
Proposer
's perspective at the proposal stage : Proposer received the acceptance of the Acceptor:
If not more than half of the Accpetor replied to the promise, this proposal failed;
if more than half of the Acceptor replied to the promise, it is divided into different situations:
if all (Acceptor) No value has been received, then send all your Acceptor values and proposal number n to all Acceptors.
If some Acceptor has received the value, then select the value with the largest proposal number from the accepted values as the value of the proposal. The proposal number is still n the
proponent's perspective : After the Acceptor receives the proposal, if the proposal number is not equal to itself The number of the current commitment). If the request is not accepted, the value of the proposal will be written to the local if they are equal.
Now let's discuss the specific details, first of all the majority commitment . Corresponding 2f + 1 Acceptors require the commitment of f of them.
Suppose we have 2 Proposers and 3 Acceptors.
Proposer1 sent PREPARE 5 to the three Acceptors, and received the promise of Acceptor1. At the same time, Proposer 2 sent the message PERPARE 4 to the three Acceptors. At this time, Proposer1 gets a PROMISE 5, which means it has received most of the promises. In this way, PREPARE 4 will be ignored by Acceptor. Even if PREPARE 4 is accepted by one of the Acceptors (out of time delay), Proposer 1 will continue to receive REQUEST 5.
Indeed, you may find that there may be competition here.
For example, Proposer1 may send a PREPARE 5 to most Acceptors, and they may make a commitment to this. Proposer 2 sends a PREPARE 6 message at the same time, and has also received the promise of most Acceptors, so that PREPARE 5 will be ignored. Proposer1 may try a higher ID, such as PREPARE 7, and get the promise of most Acceptors, so the ID 6 proposal will be ignored. Proposer2 may also try a higher ID. Several sets of such proposals will cause controversial hot spots.
A possible solution is to set an exponential backoff, which will give enough time for any proposal to be fully carried out. Proposer1 may wait for Proposer2 to process the ACCEPT REQUEST of ID 8, so that an agreement is reached and the Paxos process End.
Most accept
Proposer1 to send a PREPARE 5, a value of cat message to most Acceptor, they will make a commitment to this. Proposer2 also sends a PREPARE 6 message at the same time, and has also received the promise of most Acceptors.
