Zookeeper medium
In a robust Distributed Lock recipe, why does each client only watch the Znode with the sequence number *immediately preceding* its own?
- A To mitigate the 'Herd Effect' by ensuring that a lock release only triggers a single notification event rather than waking every waiting client.
- B Because the ZooKeeper ZAB protocol prohibits a single Znode from having more than three active watch triggers registered concurrently.
- C To ensure that the client can verify the geographical location of the specific replica that previously held the lock.
- D It is a performance optimization to allow the leader node to batch session heartbeats with lock release events.
Answer: A. To mitigate the 'Herd Effect' by ensuring that a lock release only triggers a single notification event rather than waking every waiting client.
This optimization turns an O(N) wake-up storm into an O(1) event. Client 5 only cares if Client 4 releases the lock. It doesn't care if Client 1 releases it.
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?