ZooKeeper is a distributed coordination service that allows distributed applications to synchronize data and configuration. It provides a simple API for applications to read, write, and watch a shared hierarchical data structure called a znode tree that is replicated across servers. ZooKeeper addresses the need for distributed applications like Hadoop and Kafka to coordinate tasks and share configuration through a common data store that remains available even if individual servers fail.

1. Apache ZooKeeper
Leo’s Notes
• Those slides are Leopold Gault’s notes, when reading the Overview section of the
doc: https://zookeeper.apache.org/doc/r3.4.8/zookeeperOver.html
• I am not a ZooKeeper expert; those notes are just my understanding of the
aforementioned section of the doc

3. In a nutshell

4. What problem it addresses
(purple = Leo’s assumptions)
Distributed applications such as Hadoop and Kafka need to be able to share their configuration, and
coordinate their tasks.
The nodes of a distributed application would therefore need to use a “common TODO list”, that
each server could edit (a bit like a Google Doc). On this “common TODO list”, they would write the
tasks they should distribute between each other. They’d use it to let the other nodes know when
they pick up a task, and let them know which task they have already completed.
This common TODO list could be centralized on a single machine, but it would end up being a single
point of failure for our distributed app. So this TODO list needs to be distributed too.
And sure, instead of using a common TODO list, the servers of the distributed app could use a
messaging service, in order to let each other know what they are doing. Actually, that’s probably
what would happen under the hood of such “common TODO list”.
ZooKeeper implement such “common TODO list”, and provides developers a very simple API to read
and write in this “common TODO list”.

5. What it is
Logical view
“under the hood” view
ZooKeeper allows to maintain a distributed store (this store is
a tree of nodes), and provides a very simple programming
interface (client side API) to interact with this store.
distributed store
API

6. What it is for
This store is meant to be used by distributed apps (e.g. Kafka
cluster, Hadoop cluster, etc.) for coordination of tasks and
synchronization of configuration.
My understanding is that each node of the distributed app:
• writes in the Zookeeper store which task it is going to work on,
• may notify others when it has completed its task (e.g. by releasing a “lock” in
the store –see last slide),
• reads on what task the others are working,
• reads and writes its configuration, and modifies the other’s conf.
But it is up to the distributed app to implement the aforementioned usecases. All
that the Zookeeper service provides is a distributed store with a simple client-side
API to interact with it. The ZooKeeper clients (i.e. distributed apps) do whatever
they want from this distributed-store service.
The tree is read from memory, so read operations are fast, and the size of the store is
limited (by the size of the RAM). This makes it especially adapted for the aforementioned
use.
A distributed app (e.g. Kafka cluster, Hadoop cluster),
distributed on 4 nodes.
ZooKeeper Service
“under the hood” view
Logical view
API API API API
distributed store

7. More details

8. Simple API
API
The API is very simple, and supports only these operations:
 create: creates a znode at a location in the tree
 delete: deletes a znode
 exists: tests if a znode exists at a location
 get data: reads the data from a znode
 set data: writes data to a znode
 get children: retrieves a list of children of a znode
 Sync: waits for data to be propagated

9. Z-node tree
• ACL
• Timestamp
• Version nb
• Data
• sub-znodes
ACL
Timestamp
Version number
Data
ACL
Timestamp
Version number
Data
Sub-znodes
ACL
Timestamp
Version number
Data
ACL
Timestamp
Version number
Data
ACL
Timestamp
Version number
Data
/
/znode1 /znode2
/znode3
/znode3/sub1 /znode3/sub2
Unlike typical trees, nodes can also contain data, and
leaves can also become nodes.
ACL: Access Control List

10. What all ZooKeeper servers maintain
Transaction Log
snapshots
I think
ZooKeeper server

11. ZooKeeper Service
The ZooKeeper Service (cluster)
Servers all know about each other’s existence, and a majority of them have to be running for the ZooKeeper service to work.
Leader
The messaging layer takes care of:
 replacing leaders on failures
 and syncing followers with leaders

12. All client connections go to followers
Every client is connected to only one server at a time. Those connections are TCP connections (-is there no
Application-level protocol above ? I think not.).
When the client is connected to the server a session is established. This session is kept open by sending heartbeat
messages to the server. After some amount of idle time, if the server has not heard from the client then it will close
its session.
On the other client side, if the connection break, the client will establish a session with another follower.

13. ZooKeeper Service
Read operations are directly answered to, using the in-memory replica of the store
Leader
Read
request
Direct
response
client
API

14. ZooKeeper Service
All write operations must be negotiated with the leader
Leader
Write
request
negotiation negotiation
Acknowledgement?
1
2
3 3
4
5
API

15. ZooKeeper Service
Roles of clients
Leader
A client has a TCP connection with only one server;
and this server can probably only be a follower.
Clients :
 send requests (for reads, writes, or to set up watch events ),
 get responses,
 get watch events,
 send heart beats (to keep the session alive with the server).
 If the TCP connection to the server breaks, the client will connect to a different server.
API API API

16. About watch events
Every client can set up an event listener on a specific znode, to be notified when the
znode’s state changes.
ZooKeeper service
Logical view
API

17. About Ephemeral znodes
“under the hood” view
Logical view
Leader
Ephemeral znode
Alive, while the TCP
connection is maintained
with the client who created it
Client who created the
ephemeral znode
API

18. Leo’s assumptions about some
use-cases
This section is no longer based on the documentation

19. Usecase: implementation of a lock
With an ephemeral znode and watches
“under the hood” view
Logical view
Leader
Client who created the
ephemeral lock
Lock znode (Ephemeral)
Data = “locked_znodes:{/znode1, /znode2}”
API
API
API
TCP
connection
TCP
connection
TCP
connection

20. Example of use: using ZooKeeper as a broker enabling the transactional aspect of
writes on a cluster of a NoSQL DB that doesn’t support transactions
ZooKeeper Service
“under the hood” view
Logical view
API API API API
distributed store
API
Cluster of a NoSQL DB instance
An application willing to
perform a transaction
in the NoSQL DB
instance
Add a znode (containing the write instructions
for the NoSQL DB), and wait for the
acknowledgement of the propagation of this
znode in the ZooKeeper Cluster
Acknowledgement of the
propagation
1
2
4Each NoSQL node applies the write instructions contained in the znode,
without making sure before committing that the other NoSQL nodes
successfully simulated the instructions.