ZooKeeper - Hadoop: The Definitive Guide - page 731

Chapter 21. ZooKeeper
So far in this topic, we have been studying large-scale data processing. This chapter is dif-
ferent: it is about building general distributed applications using Hadoop's distributed co-
ordination service, called ZooKeeper.
Writing distributed applications is hard. It's hard primarily because of partial failure. When
a message is sent across the network between two nodes and the network fails, the sender
does not know whether the receiver got the message. It may have gotten through before the
network failed, or it may not have. Or perhaps the receiver's process died. The only way
that the sender can find out what happened is to reconnect to the receiver and ask it. This is
partial failure: when we don't even know if an operation failed.
ZooKeeper can't make partial failures go away, since they are intrinsic to distributed sys-
tems. It certainly does not hide partial failures, either. [ 140 ] But what ZooKeeper does do is
give you a set of tools to build distributed applications that can safely handle partial fail-
ures.
ZooKeeper also has the following characteristics:
ZooKeeper is simple
ZooKeeper is, at its core, a stripped-down filesystem that exposes a few simple opera-
tions and some extra abstractions, such as ordering and notifications.
ZooKeeper is expressive
The ZooKeeper primitives are a rich set of building blocks that can be used to build a
large class of coordination data structures and protocols. Examples include distributed
queues, distributed locks, and leader election among a group of peers.
ZooKeeper is highly available
ZooKeeper runs on a collection of machines and is designed to be highly available, so
applications can depend on it. ZooKeeper can help you avoid introducing single points
of failure into your system, so you can build a reliable application.
ZooKeeper facilitates loosely coupled interactions