Apache ZooKeeper is a kind of high available data-store for small objects. A ZooKeeper cluster consists of some nodes which all keep the whole dataset in their memory. The dataset is called “always-consistent”, so every node has the same data at every time.
Zookeeper read/write operators.
Reads
are always answered locally by the node, so no communication with the cluster is involved.
Writes
are forwarded to a designated “Leader” node, which forwards the write-request to all nodes and waits for their replies. If at least half of the nodes answers, the write is considered successful.
weak-consistency/strong-consistency
In order to achieve high read-availability, Zookeeper guarantees a weak-consistency over the replicates: a read can always be answered by a client node, and the answer returned may be a stale value (even a new version has been committed through the leader).
Then it is the users’ responsibility to decide whether the answer for a read is “stale-able” or not, since not all applications require the up-to-date information. So the following choices are provided:
If your application does not need up-to-date values for reads, you can get high read-availability by requesting data directly from the client.
If your application requires up-to-date values for reads, you should use the “sync” API before your read request to sync the client-side version with the leader.
So as a conclusion, Zookeeper provides a customizable consistency guarantee, and users can decide the balance between availability and consistency.
More Info
If you want to know more about the internals of Zookeeper, I recommend this paper: ZooKeeper: Wait-free coordination for Internet-scale systems. The above strategy is described in Section 4.4.
