In the previous article we talked about understanding distributed consistency: Multi-PaxOS of the Paxos protocol. In this article I will cover two other variations of the Paxos protocol: Cheap Paxos and Fast Paxos.
Cheap Paxos
Cheap Paxos is an inherited version of Basic Paxos. In fact, all Paxos variants come from Basic Paxos and are based on it. What are the characteristics of Cheap Paxos?
In Basic Paxos, we know that in order for consensus to work properly, the number of failed nodes must be less than N /2, that is, there must be more than N /2 nodes in order for consensus to succeed. Node operation will inevitably occupy resources, is there any way to save resources and ensure the normal consensus of nodes?
Cheap Paxos: In Cheap Paxos we introduced the concept of a secondary node, which starts only when it is necessary to reach a consensus. For example, if we have a total of N+1 nodes, then we can only tolerate N/2 errors, otherwise the system cannot reach a consensus. But when we introduce again N secondary node, even if there are N nodes go wrong, as long as the extra N secondary node is up and the normal work, can reach a consensus and ensure the normal operation of the system, the secondary node in the normal nodes will automatically stop after return to work, so only start the auxiliary resources when necessary, they were cancelled the cost of a distributed system, That’s why it’s called Cheap Paxos.
Message flow: Cheap Multi-Paxos
The following figure shows the process of 3 normal nodes +1 auxiliary node. If the number of consensus nodes stipulated by the system is 3, then when a normal node fails, the auxiliary nodes will get up to help complete the consensus work.
Fast Paxos
In the Paxos protocol mentioned earlier, a message finally reaches Learner through a Client >Proposer >Acceptor >Learner in three steps.
So is there a faster way to get the message to Learner? After all, Learner is really performing the task, and we hope that the task can be known more quickly. If a Proposer has no data of its own to confirm, then a Client can skip the Proposer step by sending an Accept request directly to an Acceptor.
If a Client sends a request to a Proposer to an Acceptor, it sends a request to the Leader directly, but if it sends a request to an Acceptor, it sends it to all Acceptors.
Message flow: Fast Paxos, non-conflicting
The following figure lists the normal operation, which is executed without conflicts.
Message flow: Fast Paxos, conflicting proposals
Conflicts can occur when multiple clients send Accept requests simultaneously. There are two solutions.
- After the Leader detects a conflict, it selects a data from the conflict according to the specified algorithm and resends the Accept request. As shown below:
- When a conflict is detected, if the Acceptors can resolve the conflict themselves, there is no need for the Leader to send another Accept request, thus saving another request and time. As shown below:
Message flow: Fast Paxos with uncoordinated recovery, collapsed roles
The following is a more concise implementation of all roles grouped into one Server.
This article is available at www.flydean.com
The most popular interpretation, the most profound dry goods, the most concise tutorial, many tips you didn’t know waiting for you to discover!
Welcome to pay attention to my public number: “procedures those things”, understand technology, more understand you!