Reproduced Zab vs. Paxos

original link: Https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab+vs.+PaxosIs Zab just a special implementation of Paxos?

No, Zab is a different protocol than Paxos, although it shares with it some key aspects, as for example:

• A leader proposes values to the followers
• Leaders wait for acknowledgements from a quorum of followers before considering a proposal committed (learned)
• Proposals include epoch numbers, which is similar to ballot numbers in Paxos

The main conceptual difference between Zab and Paxos are that it's primarily designed for primary-backup systems, like Zoo Keeper, rather than for state machine replication.

What's the difference between Primary-backup and state machine replication?

A state machine was a software component that processes a sequence of requests. For every processed request, it can modify its internal state and produce a reply. Deterministic in the sense, given, runs where it receives the same sequence of requests, it ALW Ays makes the same internal state transitions and produces the same replies.

A state machine replication system is a client-sever system ensuring this each state machine replica executes the same SEQ Uence of client requests, even if these requests is submitted concurrently by clients and received in different Orders by the replicas. Replicas agree on the execution order of client requests using a consensus algorithm like Paxos. Client requests that is sent concurrently and overlap in time can is executed in any order. If a leader fails, a new leader that executes recovery are free to arbitrarily reorder any uncommitted request since it is Not yet completed.

In the case of primary-backup systems, such as Zookeeper, replicas agree on the application order of incremental (delt A) State updates, which is generated by a primary replica and sent to its followers. Unlike client requests, state updates must is applied in the exact original generation order of the primary, starting from The original initial state of the primary. If A primary fails, a new primary that executes recovery cannot arbitrarily reorder uncommitted state updates, or apply th EM starting from a different initial state.

In conclusion, agreement on State updates (for Primary-backup systems) requires stricter ordering guarantees than agreemen T on client requests (for state machine replication systems).

What is the implications for agreement algorithms?

Paxos can used for primary-backup replication by letting the primary is the leader. The problem with Paxos are, if a primary concurrently proposes multiple state updates and fails, the new prim ARY may apply uncommitted updates on an incorrect order. An example are presented in our DSN paper (Figure 1). In the example, a replica should only apply the state update B after applying a. The example shows that, using Paxos, a new primary and its follows could apply B after C, reaching an incorrect state that H As not been reached by any of the previous primaries.

A workaround to this problem using Paxos are to sequentially agree on state Updates:a Primary proposes a state up Date only after the IT commits all previous state updates. Since there is at the most one uncommitted update at a time, a new primary cannot incorrectly reorder updates. This approach, however, results in poor performance.

Zab does not need this workaround. Zab replicas can concurrently agree on the order of multiple state updates without harming correctness. This was achieved by adding one more synchronization phase during recovery compared to Paxos, and by using a different numb Ering of instances based on Zxids.

Want to know more?

A look at our DSN-paper, or contact us!

Reproduced Zab vs. Paxos