Paxos (chubby) vs Zab (Zookeeper)

Reference:

Zookeeper Consistency protocol: Zab

The principle of chubby&zookeeper and its application in distributed environment

Paxos vs. viewstamped Replication vs. Zab

Zab vs. Paxos

Zab:high-performance Broadcast for Primary-backup systems

Chubby: Locking service for loosely coupled distributed systems

Understanding of Chubby and zookeeper

The zookeeper selection process uses Paxos, which uses Zab (Zookeeper Atom Broadcast) for data replication.

Zab is the main standby system design, the more clusters of machines, write performance will be reduced, read performance has been horizontally expanded. The premise of consistency has certain qualifications, generally from the follower directly read data, although not guaranteed up-to-date, but in its application domain configuration, distributed transactions, such as business is already strong consistency. Zookeeper is not suitable for systems that require a lot of write operations.

Why use Zab instead of Paxos?

From the zookeeper to provide the API, the write operation needs to get TXID first, the write conflict is retrieved Txid retry by the business layer, that is, each operation contains invisible transactional, there are transactions to let zookeeper have more scenarios. This also requires the synchronization protocol to guarantee the causal sequence. Paxos is unable to guarantee the sequence of causality between multiple writes, the implementation can only be executed serially, inefficient and non-line.

Of course, the Zookeeper transaction functionality can be implemented from a business level based on Paxos, but Zab is much more efficient to design.

Specifically, the following description is more clear:

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.

Paxos can used for primary-backup replication by letting the primary is the leader. The problem with Paxos are, if a primary concurrentlyproposes multiple state updates and fails, the new primary may AP Ply uncommitted updates in 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 update only After 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.

Chubby VS Zookeeper:

Zookeeper provides stronger data consistency (causal order) and less performance than chubby. Chubby no open source, but from its paper, zookeeper a lot of design from chubby, zookeeper is enhanced version.

Paxos (chubby) vs Zab (Zookeeper)