"Paxos Made Simple" translation

1 Introduction

Perhaps because the previous description is too Greek for most readers, Paxos as an algorithm for implementing a fault-tolerant distributed system is considered incomprehensible. But in fact, it's probably the simplest and most obvious distributed algorithm. Its essence is actually the consensus algorithm--the "synod" algorithm of. In the next section we will show that the consensus algorithm basically satisfies all the features we want it to satisfy. The last section shows the complete Paxos algorithm, which is supposed to be well-known because it is probably the most referenced field in Distributed system theory, by directly applying a consensual state virtual machine to build a distributed system.

2 The Consensus algorithm

2.1 The problem

Suppose some process can present value. The consensus algorithm guarantees that only one of the proposed value will be selected. If no value is present, then no value will be selected. If a value is selected, the other process should be able to obtain the value. The requirements for consensus are as follows:

• Only the value that has been raised can be selected
• Only one value can be selected
• Processes can only get those value that are actually selected

We will not attempt to specify the exact requirements. But our goal is to make sure that some of the value that is raised is selected, and if a value is finally selected, then the other process will eventually be able to get that value.

We use three types of agents to represent three types of roles in the consensus algorithm: Proposers, acceptors, and learners. In a specific implementation, a process may play more than one type of agent, but from the agent to the process of mapping we do not care here.

Suppose that agents can communicate with each other by sending a message. We use the customary asychronous,non-byzantine model, where:

• The agents executes at any speed, may fail, and may restart. Because all agents can fail and restart after a value has been selected, the general approach is not feasible unless the agent remembers some information, even if a failure or restart occurs.
• Messages sent can be of any length, may be duplicated, may be lost, but they will not be corrupted

2.2 Choosing a Value

The existence of a single acceptor agent is the simplest way to choose value. Proposer sent a proposal to acceptor, which received the first one received. Although it is very simple, this method is not sufficient because of the acceptor failure, because the failure of the acceptor will result in the subsequent operation is not possible.

So we need to try another way of choosing a value. This time we will have multiple rather than a acceptors. Proposer will send value to a acceptor collection. Acceptor may accept value. However, this value is selected only if enough acceptor have accepted it. So what's big enough? To ensure that only one value is selected, we can assume that a sufficiently large set of agents is composed of any agent majority. Since any two majority have at least one public agent, this approach is possible if an agent can receive at most one value.

In the absence of fault and message loss, we want to have a value that can be selected, even if only one proposer presents a value. This is required to meet the following requirements:

P1. Acceptor must receive the first one it receives proposal

But this requirement raises the question. Different proposer may present several different value at almost the same time, which leads to the case that each acceptor accepts a value, but no value is accepted by a majority. Even if only two value is presented, and each of them is received by half of the acceptor, then the failure of any single acceptor will make it impossible to obtain which value it chooses.

The requirement that P1 and value be counted only if accepted by a majority acceptor causes our acceptor to accept more than one proposal. We track different proposal by assigning a number to each proposal, so a proposal consists of a proposal and a value. To prevent ambiguity, we require different proposal to have different number. Here we just make this assumption, and the specific implementation may be different. When a proposal is received by a acceptor majority, we assume that value is selected. In this case, we say that the proposal (which also includes its value) is selected.

We can allow multiple proposal to be selected, but we must have the same value for the proposal to be selected.

"Paxos Made Simple" translation