What problem is Paxos solving?
How does Paxos apply in distributed storage systems?
What is the core idea of the Paxos algorithm? What does the first stage do? What does the second stage do?
Paxos is used to determine the value of an immutable variable. The value can be a binary data, which is somewhat certain that it cannot be changed and can be obtained (immutability, readability).
In the application of Paxos in a distributed storage system, the data itself is variable, and multiple copies are used for storage (network delays and failures may lead to inconsistent copies). The update operation sequence of multiple copies [op1, OP, ..., opn] is the same and unchanged (what each copy does in the first step and what the second step does is unchanged). Use Paxos once to determine the value of Opi of an immutable variable (that is, what the ith operation is). After each Opi is determined, let each data copy execute Opi, and so on. Google's Ghubby, Megastor, and Spannner all employ Paxos to agree on the sequence of updates to replicas of data.
How Paxos determines the value of an immutable variable
Set up a system to store variables named var. The system consists of multiple Acceptors, which are responsible for storing and managing var variables. There are multiple external proposer machine tasks calling the API concurrently and submitting different var values to the system. The value of var can be any binary data. The external API library interface of the system: propose(var,V)=><ok,f>or<error> (if the current request is successfully called, then f=V, otherwise f is equal to the value submitted by other proposers). The system needs to ensure that the value of var is consistent . If the value of var is not determined, the value of var is null. Once the value of var is determined, it cannot be changed. And can always get this value. The system needs to meet the fault-tolerant characteristics , can tolerate the failure of any proposer machine, and can tolerate a small number of Acceptor failures (less than half). For the sake of simple understanding, the information of var will be lost without considering network differentiation and Acceptor failure for the time being.
The difficulty of determining an immutable variable
Manage concurrent execution of multiple Proposers
Consider first the composition of a single Acceptor. Concurrent proposer operations are managed through a mechanism similar to a mutual exclusion lock. The Proposer first applies to the Acceptor for mutually exclusive access to the Acceptor, and then can request the Acceptor to receive its own value. The Acceptor issues mutually exclusive access rights to the proposer, and whoever applies for the mutually exclusive access rights receives the value submitted by whomever. Once the Acceptor receives the value of a Proposer, the value of var is considered to be determined, and other Proposers are not changing.
Determine the value of an immutable variable----Scheme 1
Implementation of Acceptor Based on Mutually Exclusive Access
The Acceptor holds the variable var and a mutex lock. Acceptor::prepare() This function is used to add a mutex lock, give var the exclusive access right, and return the current value f of var. Acceptor::release() This function is used to unlock the mutex and reclaim the mutex access right of var. Acceptor::accept(var, V) If it has been locked and var has no value, set var to V. and release the lock.
Two-phase implementation of propose(var,V)
The first stage: Obtain mutually exclusive access rights and the value of the current var through Acceptor::prepare. If not, return <error> (lock is occupied).
The second stage: According to the current value f of var, choose to execute. If f==null, submit data V via Acceptor::accept(var, V). If f! =null, the access is released via Acceptor::release(). The release function returns <ok,f>.
Determining the Value of an Immutable Variable----Scenario 1 Continued
Let the Proposer sequence run through the Acceptor mutual exclusive access rights, which can simply achieve the consistency of var values. But the Proposer fails before releasing the access rights, which can lead to a deadlock of the system. Arbitrary proposer machine failures cannot be tolerated. To solve this problem see solution 2
Determine the value of an immutable variable----Scheme 2
Introducing preemptive access rights, the acceptor can invalidate the access rights obtained by a proposer and no longer receive his access. After that, you can send access rights to other proposers to allow other proposers to access the acceptor
The Proposer specifies the numbered epoch when applying for the access right to the Acceptor (the larger the epoch, the newer). After obtaining the access right, the value can be submitted to the Acceptor.
Acceptor adopts the principle of liking the new and disliking the old. Once a larger new epoch is requested, the old access rights are immediately invalidated, and the values submitted by them are no longer accepted. Then grant access to the new epoch and only receive the values submitted by the new epoch.
The new epoch can preempt the old epoch, invalidating the access rights of the old epoch. The proposer of the old epoch will fail to run, and the proposer of the new epoch will start running.
In order to ensure consistency, the principle of "the latter agrees with the former" is adopted between proposers of different epochs. When it is certain that the old epoch cannot generate a definite value, the new epoch will submit its own value without conflict. Once a deterministic value is formed for an epoch, the new epoch can definitely obtain this value, and will agree with this value without destroying it.
Determine the value of an immutable variable----Continued from scheme 2
Implementation of Acceptor Based on Preemptive Access
The state maintained by the Acceptor, the value of the current var <accepted_epoch, accepted_value>
The latest epoch for which access rights were issued (latest_prepared_epoch)
Acceptor::prepare(epoch), only accepts epochs larger than latest_prepared_epoch and gives access,
Record latest_prepared_epoch=epoch and return the value of the latest var.
Acceptor:: accept(var, prepared_epoch, V), judge latest_prepared_epoch==prepared_epoch, if it is not equal, it means that other proposers have already obtained access rights, so this submission will be invalid. If they are equal, set the value of var <accepted_epoch,accepted_value>=<prepared_epoch,v>
Two-phase implementation of Propose(var,V)
The first stage: Obtain the access rights of the epoch round and the value of the current var. (principle)
Simply select the current timestamp as epoch, and obtain the epoch round access rights and the current var value through Acceptor::prepare(epoch). If it cannot be obtained (indicating that the same or greater epoch has obtained access rights), return <error>. (accomplish)
The second stage: adopt the principle of "the latter agrees with the former". When it is certain that the old epoch cannot generate a deterministic value, the new epoch will submit its own value without conflict. Once the old epoch's itinerary is determined deterministically, the new epoch can definitely obtain this value, and will agree with this value without conflict. (principle)
If the value of var is empty, it is certain that the old epoch cannot generate a deterministic value, and the data V is submitted through Acceptor::accept(var, epoch, V). Returns <ok, V> after success, and returns <error> if accept fails (preempted by new epoch or acceptor failure). If the value of var exists, the value must be a deterministic value. At this time, it is agreed that it is not changing, and <ok,accepted_value> is directly returned (implementation)
Determine the value of an immutable variable----Continued from scheme 2
Based on the core idea of preemptive access rights, Proposer will preemptively run in the order of increasing epoch, and the latter agrees with the former.
The deadlock problem caused by the failure of the proposer machine can be avoided, and the consistency of the var value can be guaranteed.
It is still necessary to introduce multiple acceptors. The acceptor of the stand-alone module is faulty, causing the entire system to go down and unable to provide services.
Determine the value of an immutable variable----Paxos
Paxos introduces multiple Acceptors on the basis of Scheme 2. The implementation of Acceptor remains the same and still operates on the principle of "loving the new and disliking the old". Paxos adopts the idea of "the minority obeys the majority". Once the value f of an epoch is received by more than half of the acceptors, it is considered that the value of this var is determined to be f and is not changed.
The first stage of Propose (var, V): select epoch, obtain epoch access rights and the corresponding var value. Obtain the access rights of more than half of the acceptors and the corresponding set of var values.
The second stage of Propose(var, V): adopt the principle of "the latter agrees with the former". When it is certain that the old epoch cannot generate a deterministic value, the new epoch will submit its own value. will not conflict. Once the old epoch becomes a deterministic value, the new epoch can definitely obtain this value, and will not agree with this value and will not be destroyed.
If the obtained var values are all empty, the old epoch cannot be deterministically evaluated. At this point, try to make <epoch, V> a deterministic value.
1. Submit the value <epoch, V> to all acceptors corresponding to the epoch.
2. If more than half of the received is successful, return <ok, V>
3. Otherwise return <error> (preempted by new epoch or acceptor failure)
If the value of var exists, agree with the value f corresponding to the largest accepted_epoch, and try to make <epoch, f> a deterministic value. If more than half of f appears, it means that f is already a deterministic value, and returns <ok,f> directly. Otherwise, submit the value <epoch,f> to all acceptors corresponding to epoch
