Database Reference
In-Depth Information
There are a number of predefined ACLs in the
ZooDefs.Ids
class, including
OPEN_ACL_UNSAFE
, which gives all permissions (except
ADMIN
permission) to every-
one.
In addition, ZooKeeper has a pluggable authentication mechanism, which makes it pos-
sible to integrate third-party authentication systems if needed.
Implementation
The ZooKeeper service can run in two modes. In
standalone mode
, there is a single
ZooKeeper server, which is useful for testing due to its simplicity (it can even be embed-
ded in unit tests) but provides no guarantees of high availability or resilience. In produc-
tion, ZooKeeper runs in
replicated mode
on a cluster of machines called an
ensemble
.
ZooKeeper achieves high availability through replication, and can provide a service as
long as a majority of the machines in the ensemble are up. For example, in a five-node en-
semble, any two machines can fail and the service will still work because a majority of
three remain. Note that a six-node ensemble can also tolerate only two machines failing,
because if three machines fail, the remaining three do not constitute a majority of the six.
For this reason, it is usual to have an odd number of machines in an ensemble.
Conceptually, ZooKeeper is very simple: all it has to do is ensure that every modification
to the tree of znodes is replicated to a majority of the ensemble. If a minority of the ma-
chines fail, then a minimum of one machine will survive with the latest state. The other
remaining replicas will eventually catch up with this state.
The implementation of this simple idea, however, is nontrivial. ZooKeeper uses a protocol
called Zab that runs in two phases, which may be repeated indefinitely:
Phase 1: Leader election
The machines in an ensemble go through a process of electing a distinguished member,
called the
leader
. The other machines are termed
followers
. This phase is finished once
a majority (or
quorum
) of followers have synchronized their state with the leader.
Phase 2: Atomic broadcast
All write requests are forwarded to the leader, which broadcasts the update to the fol-
lowers. When a majority have persisted the change, the leader commits the update, and
the client gets a response saying the update succeeded. The protocol for achieving con-
sensus is designed to be atomic, so a change either succeeds or fails. It resembles a
two-phase commit.
