Zookeeper hard
The ZooKeeper Atomic Broadcast (ZAB) protocol is often compared to a Two-Phase Commit (2PC). How does ZAB's commit logic specifically bypass the 'blocking' problem inherent in standard 2PC?
- A ZAB utilizes a three-phase commit (3PC) structure that introduces a 'pre-commit' state to handle leader failure without data loss.
- B ZAB relaxes the consensus requirement to a simple Quorum; the Leader commits as soon as a majority (`N/2+1`) of followers acknowledge the proposal.
- C ZAB uses an optimistic concurrency model that allows followers to acknowledge proposals based on local CPU availability rather than disk fsync.
- D ZAB leverages the Raft 'joint consensus' algorithm to allow for asynchronous shard rebalancing during the commit phase.
Answer: B. ZAB relaxes the consensus requirement to a simple Quorum; the Leader commits as soon as a majority (`N/2+1`) of followers acknowledge the proposal.
Standard 2PC is a blocking protocol; if one node fails, the system hangs. ZAB prioritizes Availability/Partition Tolerance by proceeding once the Quorum is satisfied, allowing slow followers to catch up later.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What is the primary technical function of a ZooKeeper 'Watch'?
- A system administrator increases `jute.maxbuffer` to 5MB on every ZooKeeper server to store large configuration objects. However, write operations larger than 1MB still fail. What is the most likely cause?
- By default, `forceSync` is enabled. If you disable it, what trade-off are you making?
- If the specific ZooKeeper node a client is connected to crashes, what should the client do?
- Which cluster configuration has *worse* availability: A 3-node cluster or a 4-node cluster? (Assuming simple majority quorum)
- According to the CAP Theorem, how is ZooKeeper classified?