Multi paxos: Evolution of basic paxos

Based on basic paxos, multi paxos simplifies the original 2-phase process to 1-phase, thus speeding up the submission. Multi paxos requires that each proposer has a unique leader and the leader must submit the value to each acceptor for voting. If only one leader in the system submits the value, the prepare process can be skipped, and the leader election can be completed by paxos lease.

In fact, multi paxos does not completely skip phase-1. When the system selects a new leader, it must follow the 2-phase process in the initial submissions, after reaching a "stable" status, you can skip phase-1 and directly send acceptrequest to each acceptor for submission. There are two key issues here.

First, why must the newly selected leader be submitted in the 2-phase process in the initial state? This should begin with the process of learner's value. Each round of voting (that is, an instance) corresponds to an instanceid, which increases monotonically. When learner processes the value, it must follow the sequence of instanceid increments continuously (to ensure data consistency). If the final voting result of a round is unknown for some reason, learner needs to query the value corresponding to the instanceid from each acceptor. In this case, the following scenario exists: when the original leader suddenly goes offline after half of the submission, if the newly elected leader is submitted directly through acceptrequest, this round of voting may fail to pass any final resolution (for example, a total of four acceptor, the original leader just submitted the value to two of them and then went offline. After the new leader went online, it submitted different values to the other two accptors, which will eventually lead to a situation of 2: 2 ), the learner is stuck in processing the instance.

Second, how to ensure that the instanceid submitted by the new leader is continuously increasing? In this regard, on the one hand, the leader can tell each acceptor about its current instanceid during each lease renewal. After the new leader is elected, it can get a value closer to the current instanceid from the acceptor; after the new leader is elected, in the first several rounds of voting, use the 2-phase process to submit some "null" operations (that is, if learner finds that the voting result is null, no action is taken ), after the current instanceid is exceeded or exceeded, the 1-phase process is used for submission. At this point, another problem occurs: How many rounds of 2-phase process submission should be executed to enter the "stable" status? In code implementation, to speed up algorithm performance, the proposer and learner can each maintain a queue, and the acceptor maintains a buffer zone, to achieve a method of "unordered submission-unordered voting-ordered execution ,:
In this case, if the queue length of Proposer is queue_size, As long as proposer knows that there are queue_size instances, it can be determined that they have reached the "stable" state. For example, when the queue length is queue_size = 2, the original leader suddenly goes offline when submitting 5th and 6th values, after the new leader is selected, the following two-phase submissions need to be performed three times (4th instace cannot be finally submitted, but 5th and 6th instace can be voted) and then reaches the "stable" status.