Using Zookeeper for Middleware: Implementing Distributed Locks and Service Registry in Spring Boot

1. Overview

1.1 What is Zookeeper?

Zookeeper (literally “zoo keeper”) is an open‑source distributed coordination service that acts as a cluster manager, monitoring node status and providing simple APIs with high performance and stability. It enables data publish/subscribe, load balancing, naming service, leader election, distributed locks, queues, and more.

1.2 Design and implementation

Zookeeper follows the Observer pattern: it stores data that observers can register for; when data changes, Zookeeper notifies the registered observers.

Key characteristics:

Cluster consists of one Leader and multiple Followers.

Cluster works as long as a majority of nodes are alive, so an odd number of servers is recommended.

All servers keep identical data copies; clients see consistent data.

Update requests are processed in the order they are received from the same client.

Updates are atomic; either succeed or fail.

Clients can read the latest data within a bounded time.

Data model: Zookeeper = file system + notification mechanism. Data is stored in a hierarchical tree of ZNodes, similar to a Unix file system. Each ZNode can hold up to 1 MB, suitable for configuration and cluster metadata rather than large payloads.

2. Installation and deployment

Download Apache Zookeeper 3.5.7 from the official site and extract the tarball on a Linux host with JDK installed.

[root@shepherd-master ~]# java -version
openjdk version "1.8.0_302"
OpenJDK Runtime Environment (build 1.8.0_302-b08)
OpenJDK 64-Bit Server VM (build 25.302-b08, mixed mode)

Unpack and rename the sample configuration file:

tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz
mv zoo_sample.cfg zoo.cfg
dataDir=/zookeeper/zookeeper-3.5.7/zkData

Create the data directory and start the server:

cd /zookeeper/zookeeper-3.5.7
mkdir zkData
bin/zkServer.sh start

Verify the process with jps (look for QuorumPeerMain) and connect with the client:

[root@shepherd-master ~]# jps
110384 QuorumPeerMain
18270 Jps

Cluster deployment follows the same steps on each node, plus a myid file containing the server ID (1, 2, 3). The zoo.cfg file must list each server:

#######################cluster##########################
server.1=10.10.0.10:2888:3888
server.2=10.10.0.22:2888:3888
server.3=10.10.0.26:2888:3888

Format: server.A=B:C:D where A is the server number, B the address, C the follower‑to‑leader communication port, and D the election port.

Start each node with bin/zkServer.sh start. The leader election process is described next.

3. Leader election mechanism

A new leader is elected when a server starts for the first time or when an existing leader becomes unreachable. In a five‑node example, the election proceeds as follows:

Server 1 starts, votes for itself (1 vote, not a majority).

Server 2 starts, votes for itself; Server 1 sees Server 2’s higher ID and switches its vote, resulting in 0 votes for Server 1 and 2 votes for Server 2 (still not a majority).

Server 3 starts, both previous servers switch to vote for Server 3, giving Server 3 three votes – a majority, so it becomes Leader.

Subsequent servers (4, 5) join as Followers.

If the current leader fails, the remaining servers repeat the same voting rules. The election decision uses the following ordering:

Higher epoch wins.

If epochs are equal, higher ZXID (transaction ID) wins.

If both are equal, higher server ID wins.

4. Watcher mechanism

Watchers allow clients to register callbacks on specific ZNodes. When the node’s data changes, is deleted, or its children list changes, the server sends a NodeDataChanged or NodeChildrenChanged event to the client. A watcher fires only once; to receive further notifications the client must re‑register.

Example of a data‑change watcher:

[zk: localhost:2181(CONNECTED) 5] get -w /shepherd
MeiYing
...
WatchedEvent state:SyncConnected type:NodeDataChanged path:/shepherd

Example of a children‑change watcher:

[zk: localhost:2181(CONNECTED) 2] ls -w /shepherd
[]
[zk: localhost:2181(CONNECTED) 0] create /shepherd/car "tesla"
Created /shepherd/car
WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/shepherd

5. Zookeeper in Spring Boot applications

5.1 Service registry

Zookeeper can serve as a service registry for producers and consumers, similar to Eureka. In a Dubbo architecture, services register themselves in Zookeeper and clients discover them via the ZNode tree. Zookeeper provides CP guarantees (consistency + partition tolerance) whereas Eureka provides AP (availability + partition tolerance).

5.2 Distributed lock

Using Zookeeper’s temporary sequential nodes, a lock can be built under a /locks path. Apache Curator simplifies this with high‑level APIs. The following example creates two threads that contend for the same lock, demonstrating lock acquisition, re‑entrancy, and release.

import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
...
InterProcessLock lock1 = new InterProcessMutex(getCuratorFramework(), "/locks");
InterProcessLock lock2 = new InterProcessMutex(getCuratorFramework(), "/locks");
...
lock1.acquire();
System.out.println("Thread 1 acquired lock");
lock1.release();
System.out.println("Thread 1 released lock");
...

Running the program prints the lock acquisition order, confirming that Curator correctly serializes access.

6. Summary

Zookeeper is a core component in many middleware solutions, providing reliable coordination, service discovery, and distributed locking. Mastering its design, deployment, watcher, and integration with Spring Boot equips developers to build robust distributed systems.