Zookeeper Architecture and Basics

A Distributed Coordination Service for Distributed Applications

ZooKeeper is a distributed, open-source coordination service for distributed applications.

It provides services for

  • Distributed Synchronization
  • Configuration maintenance
  • Coordination service which does not suffer from RACE CONDITION, DEAD LOCKs
  • Naming Services
  • Groups Services

Why Zookeeper Required?

What we have seen in case of Non-Distributed application, we use multiple threads to process some task to achieve good performance and we ensure consistency of shared resources with the help of synchronization.

Synchronization of shared resources access is done via some logic, API etc. As we know that threads synchronization can be achieved in same process space not in between different set of process so if we want to synchronize our system in clustered environment OR between different process running on different machines, we need some coordination system/service to synchronize and monitor to provide consistency in distributed application and to achieve above goals ZooKeeper OR similar kind of system required.


ZooKeeper allows distributed processes to coordinate with each other through a shared hierarchal namespace which is organized similarly to a standard file system. The name space consists of data registers – called znodes, in ZooKeeper parlance – and these are similar to files and directories. Unlike a typical file system, which is designed for storage, ZooKeeper data is kept in-memory, which means ZooKeeper can achieve high throughput and low latency numbers.

The servers that make up the ZooKeeper service must all know about each other. They maintain an in-memory image of state, along with a transaction logs and snapshots in a persistent store. As long as a majority of the servers are available, the ZooKeeper service will be available.

Leader selection is done by majority of follower server and if leader get down all other follower selects another leader in zookeeper cluster.

Clients connect to a single ZooKeeper server. The client maintains a TCP connection through which it sends requests, gets responses, gets watch events, and sends heart beats. If the TCP connection to the server breaks, the client will connect to a different server.



Leader Selection

Leader selection is done by majority of follower server and if leader get down all other follower selects another leader in zookeeper cluster.

Atomic Broadcast
  • All write request forwarded to leader
  • Leader Broadcast the request to followers
  • When majority of followers persisted the change
    • Leader commits the updates
    • Client gets success response
  • Machines write to disk before memory.
  • Two-Phase commit protocol used for atomic operation


Data model and the hierarchical namespace

The name space provided by ZooKeeper is much like that of a standard file system. A name is a sequence of path elements separated by a slash (/) . Every node in ZooKeeper’s name space is identified by a path. it is similar to file or directory system.

Each node (also called as zNode) in a ZooKeeper namespace can have data associated with it as well as children.

The data stored at each znode in a namespace is read and written atomically. Reads get all the data bytes associated with a znode and a write replaces all the data. Each node has an Access Control List (ACL) that restricts who can do what.

ZooKeeper also has the notion of ephemeral nodes. These znodes exists as long as the session that created the znode is active. When the session ends the znode is deleted.



ZooKeeper supports the concept of watches. Clients can set a watch on a znode. A watch will be triggered and removed (watchers are triggered only once for multiple notification re-register required)when the znode changes. When a watch is triggered, the client receives a packet saying that the znode has changed. If the connection between the client and one of the Zoo Keeper servers is broken, the client will receive a local notification.

Simple API

One of the design goals of ZooKeeper is provide a very simple programming interface. As a result, it supports only these operations:

creates a node at a location in the tree

deletes a node

tests if a node exists at a location

get data
reads the data from a node

set data
writes data to a node

get children
retrieves a list of children of a node

waits for data to be propagated

To Check Server (Followers) status

use below commands after telnet


Example:- telnet ip:port for example telnet localhost:2181

after telnet commands default string type ‘ruok’


Server statistic details


Thank you a lot for visiting. Hope it clears zookeeper concept.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s