ZooKeeper

Chapter 9. ZooKeeper Internals

This chapter is a bit special compared to the others. It is not going to explicitly explain anything related to building applications with ZooKeeper. Instead, it explains how ZooKeeper works internally, by describing its protocols at a high level and the mechanisms it uses to tolerate faults while providing high performance. This content is important because it gives some deeper insight into why things work the way they work with ZooKeeper. This insight is relevant if you’re planning on running ZooKeeper. It consequently serves as background for Chapter 10.

As we saw in earlier chapters, ZooKeeper runs on an ensemble of servers while clients connect to these servers to execute operations. But what exactly are these servers doing with the operations the clients send? We hinted in Chapter 2 that we elect a distinguished server that we call the leader. The remaining servers, who follow the leader, are called followers. The leader is the central point for handling all requests that change the ZooKeeper system. It acts as a sequencer and establishes the order of updates to the ZooKeeper state. Followers receive and vote on the updates proposed by the leader to guarantee that updates to the state survive crashes.

The leader and the followers constitute the core entities guaranteeing the order of state updates despite crashes. There is a third kind of server, however, called an observer. Observers do not participate in the decision process of what requests ...