Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, tutorials, and more.

Chapter 13. ZooKeeper

So far in this book, we have been studying large-scale data
processing. This chapter is different: it is about building general
distributed applications using Hadoop’s distributed coordination 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 systems. It certainly does not hide partial
failures, either.[97] But what ZooKeeper does do is give you a set of tools to
build distributed applications that can safely handle partial
failures.

ZooKeeper also has the following characteristics:

ZooKeeper is simple

ZooKeeper is, at its core, a stripped-down filesystem that
exposes a few simple operations, 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 ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, interactive tutorials, and more.