Zookeeper in Action: Config Management, Distributed Locks, Queues & Load Balancing

1. Introduction

Previously I wrote about Zookeeper basics; it is a high‑performance coordination service widely used in distributed applications. The following sections illustrate concrete use cases such as configuration management, distributed locks, queues, and load balancing.

2. Practical Applications

2.1 Consistent Configuration Management

When many servers need shared configuration (e.g., database connection info) that may change at runtime, updating each instance manually is cumbersome. Zookeeper can store the configuration centrally and let applications read or modify it.

2.1.1 Idea

Store public configuration in Zookeeper nodes; applications connect to Zookeeper to read or update those nodes (with optional permission checks).

2.1.2 Example

Java class representing configuration:

public class CommonConfig implements Serializable {
    // database connection configuration
    private String dbUrl;
    private String username;
    private String password;
    private String driverClass;
    // getters, setters, constructors, toString omitted for brevity
}

Configuration management center:

Get local configuration information

Modify configuration and synchronize

Synchronize configuration to Zookeeper server:

public class ZkConfigMng {
    private String nodePath = "/commConfig";
    private CommonConfig commonConfig;
    private ZkClient zkClient;
    public CommonConfig initConfig(CommonConfig commonConfig) { /* ... */ }
    public CommonConfig update(CommonConfig commonConfig) { /* ... */ }
    public void syncConfigToZookeeper() { /* ... */ }
}

Client to fetch these configurations:

public class ZkConfigClient implements Runnable {
    private String nodePath = "/commConfig";
    private CommonConfig commonConfig;
    public void run() { /* ... */ }
}

Main function to start the service and modify configuration:

public static void main(String[] args) throws InterruptedException {
    SpringApplication.run(ZookeeperApiDemoApplication.class, args);
    ZkConfigMng zkConfigMng = new ZkConfigMng();
    zkConfigMng.initConfig(null);
    zkConfigMng.syncConfigToZookeeper();
    TimeUnit.SECONDS.sleep(10);
    zkConfigMng.update(new CommonConfig("jdbc:mysql://192.168.1.122:3306/mydata?...", "root", "wxh", "com.mysql.jdbc.Driver"));
}

2.2 Distributed Lock

For cross‑process or cross‑machine resource contention, traditional synchronized blocks are insufficient. Zookeeper can implement a fair distributed lock using temporary sequential nodes.

2.2.1 Idea

Create a persistent node /distributed_lock.

Each contender creates an ephemeral sequential child such as /distributed_lock/task_00000000008.

All children are sorted; the smallest node holds the lock.

If not the smallest, watch the predecessor node and block until it disappears.

Workflow diagram:

2.2.2 Example

public class DistributedLock {
    static class Constant {
        static final int SESSION_TIMEOUT = 10000;
        static final String CONNECTION_STRING = "127.0.0.1:2181";
        static final String LOCK_NODE = "/distributed_lock";
        static final String CHILDREN_NODE = "/task_";
    }
    private ZkClient zkClient;
    public DistributedLock() { /* connect and create LOCK_NODE if absent */ }
    public String getLock() { /* createEphemeralSequential and acquireLock */ }
    public Boolean acquireLock(String lockName) throws InterruptedException { /* sort children, check position, watch predecessor */ }
    public void releaseLock(String lockName) { zkClient.delete(lockName); }
    public void closeZkClient() { zkClient.close(); }
}

2.3 Distributed Queue

In a distributed environment the classic BlockingQueue cannot be shared across processes. Zookeeper’s temporary sequential nodes provide a FIFO queue mechanism.

2.3.1 Idea

Producers create an ephemeral sequential node under a parent (e.g., /mailbox/mail_) if the queue size is below a limit.

Consumers watch the parent, retrieve the smallest child, process it, and delete the node.

2.3.2 Example

public interface AppConstant { static String ZK_CONNECT_STR = "127.0.0.1:2181"; static String NODE_PATH = "/mailbox"; static String CHILD_NODE_PATH = "/mail_"; static int MAILBOX_SIZE = 10; }

public class MailConsumer implements Runnable, AppConstant { /* watches child changes, waits when empty, consumes smallest mail */ }

public class MailProducer implements Runnable, AppConstant { /* watches child changes, waits when full, produces mail */ }

2.4 Load Balancing

Zookeeper can also serve as a service registry and enable load‑balanced service invocation. Providers register their address under a common path; consumers retrieve the list and apply a balancing algorithm.

2.4.1 Idea

Each service instance creates an ephemeral node like /service/myService/192.168.1.10. Consumers subscribe to /service/myService to keep an up‑to‑date list.

Structure diagram:

2.4.2 Example

public class ServiceProvider {
    static String ZK_CONNECT_STR = "127.0.0.1:2181";
    static String NODE_PATH = "/service";
    static String SERVICE_NAME = "/myService";
    private ZkClient zkClient;
    public ServiceProvider() { /* connect and ensure NODE_PATH exists */ }
    public void registryService(String localIp, Object obj) { /* create persistent service node and an ephemeral node for the instance */ }
}

public class ServiceConsumer {
    static String ZK_CONNECT_STR = "127.0.0.1:2181";
    static String NODE_PATH = "/service";
    static String SERVICE_NAME = "/myService";
    private List<String> serviceList = new ArrayList<>();
    private ZkClient zkClient;
    public ServiceConsumer() { /* connect and ensure NODE_PATH exists */ }
    public void subscribeSerivce() { /* get children and watch for changes */ }
    public void consume() { /* pick a random instance from serviceList */ }
}

3. Summary

Zookeeper is a powerful coordination service; beyond the examples above it also supports naming services, distributed notifications, and many other scenarios.