Zookeeper medium
What is the primary motivation for using 'Container' Znodes (introduced in 3.5.x) when designing complex distributed coordination recipes?
- A To provide a sandboxed environment for running specialized Docker workflows inside the ensemble's memory space.
- B To handle automatic cleanup; if a Container node's last child is deleted, the Container itself is eventually reaped by a background task.
- C To allow for Znodes that can exceed the default 1MB storage limit by mapping their data to external S3 buckets.
- D To enable the Leader node to prioritize reads based on the specific 'category' of the hierarchical namespace.
Answer: B. To handle automatic cleanup; if a Container node's last child is deleted, the Container itself is eventually reaped by a background task.
This is useful for 'Leader Latch' recipes. You create a path `/latch/candidate_1`. If you delete the candidates, you don't want the empty `/latch` parent to linger forever.
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?