Database Reference
In-Depth Information
An Example
Imagine a group of servers that provide some service to clients. We want clients to be able
to locate one of the servers so they can use the service. One of the challenges is maintain-
ing the list of servers in the group.
The membership list clearly cannot be stored on a single node in the network, as the failure
of that node would mean the failure of the whole system (we would like the list to be
highly available). Suppose for a moment that we had a robust way of storing the list. We
would still have the problem of how to remove a server from the list if it failed. Some pro-
cess needs to be responsible for removing failed servers, but note that it can't be the servers
themselves, because they are no longer running!
What we are describing is not a passive distributed data structure, but an active one, and
one that can change the state of an entry when some external event occurs. ZooKeeper
provides this service, so let's see how to build this group membership application (as it is
known) with it.
Group Membership in ZooKeeper
One way of understanding ZooKeeper is to think of it as providing a high-availability
filesystem. It doesn't have files and directories, but a unified concept of a node, called a
znode
, that acts both as a container of data (like a file) and a container of other znodes (like
a directory). Znodes form a hierarchical namespace, and a natural way to build a member-
ship list is to create a parent znode with the name of the group and child znodes with the
names of the group members (servers). This is shown in
Figure 21-1
.
Figure 21-1. ZooKeeper znodes
In this example we won't store data in any of the znodes, but in a real application you could
imagine storing data about the members, such as hostnames, in their znodes.
