Article Directory
foreword
A distributed system is a system in which multiple nodes work together to provide high-availability , high-performance , and high-scalability services. However, distributed systems also face many challenges, such as network delay, node failure, data consistency, etc. To solve these problems, distributed systems need a coordination service to manage communication and collaboration among nodes.
ZooKeeper is a high-performance distributed application coordination service. It provides some commonly used services, such as naming, configuration management, synchronization and group services. In a simple interface, you don't have to write it from scratch, you can directly use it to implement functions such as consensus, group management, leader election and existence agreement. Of course, you can also build your own specific needs on top of it.
ZooKeeper is an open source tool library written in java, which natively provides a Java API to access and manipulate data in the ZooKeeper cluster. You can use ZooKeeper as a dependency library for Java applications or frameworks to implement distributed functions or integrate other distributed components.
The origin of the name ZooKeeper: "From Paxos to ZooKeeper" Chapter 4 Section 1
ZooKeeper originated from a research group in Yahoo Research. At that time, researchers found that many large systems within Yahoo basically needed to rely on a similar system for distributed coordination, but these systems often had distributed single-point problems. Therefore, Yahoo's developers tried to develop a general distributed coordination framework without a single point of problem, so that developers can concentrate on processing business logic.
There is actually an interesting anecdote about the name of the "ZooKeeper" project. In the initial stage of the project, considering that many internal projects were named after animals (such as the famous Pig project), Yahoo engineers hoped to give this project an animal name. Raghu Ramakrishnan, the chief scientist of the institute at the time, jokingly said: "If this continues, our place will become a zoo!" Putting the components together, Yahoo's entire distributed system looks like a large zoo, and ZooKeeper is just used to coordinate the distributed environment—thus, the name of ZooKeeper was born.
This article will introduce the architecture and working principle of ZooKeeper as a Java open source tool library, the Java API provided by ZooKeeper, and the use cases of ZooKeeper in some distributed systems or applications.
Official website: https://ZooKeeper.apache.org/
github：https://github.com/apache/ZooKeeper
pom dependencies:
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.7.0</version>
</dependency>
1. Structure and working principle
1.1 Cluster structure
Zookeeper is an ensemble composed of multiple servers, each of which stores the same data, and ensures data consistency through the ZAB (ZooKeeper Atomic Broadcast Protocol) protocol. A client (client) can connect to any server and read or modify data by sending a request (request). The server will process according to the request type and return a response (response). If the request involves modifying data, the server will forward the request to the leader, and the leader will broadcast the request to other followers, and wait for them to agree before executing the request and returning a response.
A Zookeeper cluster is composed of multiple server nodes, and each node can provide coordination services. In order to ensure data consistency, the nodes in the Zookeeper cluster are divided into three roles: leader, follower and observer.
- The Leader node is the master node in the cluster, responsible for processing client write requests and coordinating the status of follower nodes. Leader nodes are elected through voting, and there can only be one leader node in a cluster.
- The follower node is a slave node in the cluster, which is responsible for processing the client's read request and synchronizing the data of the leader node. Follower nodes can participate in voting for leader nodes.
- The Observer node is an observer node in the cluster, which is responsible for processing the client's read request and synchronizing the data of the leader node. Observer nodes do not participate in voting for leader nodes, and do not affect the availability and consistency of the cluster.
A Zookeeper cluster usually requires an odd number of nodes (at least three) so that it can still function properly in the event of a failure. For example, in a five-node cluster, even if two nodes go down, there are still three nodes that can continue to provide services.
ZooKeeper needs an odd number of nodes because it needs a majority to elect a leader node and ensure data consistency. If there is an even number of nodes, then when half of the nodes fail, a majority cannot be formed and services cannot continue to be provided. Moreover, adding an even number of nodes does not improve availability, but increases communication overhead. Therefore, ZooKeeper usually uses 3 or 5 nodes to build a cluster.
1.2 Data Model
The data stored by ZooKeeper is a node (node) organized in a tree structure, each node has a unique path (path) identification, and contains some metadata (metadata) and optional values (value). Each node can also have child nodes, forming a hierarchical relationship. Clients can access or operate nodes through paths.
Zookeeper's data model is a hierarchical namespace (similar to a file system), where each node is called a ZNode. Each ZNode can store some data and may have child nodes. Paths to ZNodes are separated by slashes and must be absolute paths (relative paths cannot be used). The name of a ZNode can contain Unicode characters.
For example: /app/config/db/url is a valid ZNode path.
)
Each ZNode has a state structure (stat), which is used to record the metadata information of the ZNode, such as creation time, modification time, version number, number of child nodes, etc. The ZooKeeper client can use this information to judge the change of ZNode and make corresponding operations.
ZooKeeper supports two types of ZNodes: persistent and ephemeral.
- A persistent ZNode means that it exists in ZooKeeper after it is created until it is deleted or renamed.
- Temporary ZNodes are meant to exist only in ZooKeeper for a period of time after creation, and are automatically deleted after the session in which they were created ends.
1.3 Session Management
A session is maintained between ZooKeeper and the client, and the client needs to periodically send a heartbeat packet (ping) to the server to keep the session valid. If the client loses contact with the server for more than the specified time, the session will be invalidated, and the ephemeral node created or held by the client will also be deleted. A temporary node is a special type of node that only exists within the validity period of the client that created it or holds it, and disappears automatically after the client disconnects. Ephemeral nodes cannot have child nodes.
A ZooKeeper session refers to a connection state between the client and the server, which is used to ensure the consistency of the client's request and response. Each ZooKeeper session has a unique 64-bit identifier (session id), and a timeout (session timeout).
- Session id is assigned to the client by the server when the client connects for the first time, and is used to identify the client. If the client disconnects and reconnects to another server, it will send its own session id to the new server in order to continue the previous session.
- Session timeout is specified by the client when creating a ZooKeeper instance, and is used to tell the server how long the client has not sent a heartbeat packet before it is considered invalid. If the server does not receive any message from the client within the session timeout time, it will consider the client disconnected and delete its related temporary ZNode and listener events.
The ZooKeeper client needs to periodically send a heartbeat packet (ping) to the server to maintain its own session state. If the client cannot communicate with the current server due to network failure or other reasons, it will try to connect to other available servers and restore its own session state.
The ZooKeeper client can monitor the change event of ZNode by registering Watcher, and be notified when the event occurs. Watcher can only be triggered once. If the client wants to continuously monitor the changes of ZNode, it needs to re-register Watcher. The registration and triggering of Watcher are performed in the ZooKeeper session. If the ZooKeeper session fails, the registration and triggering of Watcher will be invalid.
1.4 Consistency Guarantee
ZooKeeper is a distributed coordination service that needs to synchronize data among multiple server nodes and ensure that clients can access the latest data. To achieve this goal, ZooKeeper provides the following consistency guarantees:
- Atomicity: Every update operation (create, delete, modify ZNode) is atomic and either succeeds or fails.
- Ordering: Each update operation has a globally unique transaction number (zxid), which is used to indicate the order of the operation in the entire cluster. The client can judge the change of ZNode through zxid.
- Single System Image: No matter which server node a client connects to, it sees the same view of data.
- Reliability: If an update operation completes successfully, it will be persisted on all server nodes and will not be revoked.
- Timeliness: The client can access the latest data within a limited time.
The consistency guarantee of ZooKeeper is based on leader election and ZAB protocol. Leader election means that server nodes in the cluster select a leader node through a voting mechanism, which is responsible for processing all write requests and coordinating the status of other nodes. The ZAB protocol refers to the ZooKeeper atomic broadcast protocol, which is used to transmit and synchronize data between leader and follower nodes.
The consistency guarantee of ZooKeeper is not strong consistency (Strong Consistency), but sequential consistency (Sequential Consistency). This means that different clients may see different versions of the data, but they see changes in the same order. Doing so can improve read efficiency and fault tolerance, but it may also bring some problems, such as split brain. Therefore, you need to pay attention to avoid these problems when using ZooKeeper, and set parameters such as timeout and retry times reasonably.
The split-brain phenomenon refers to the fact that the nodes in the ZooKeeper cluster are divided into two or more subsets due to network partition, and each subset may produce a leader node, resulting in data inconsistency.
ZooKeeper prevents split-brain phenomenon by using Quorum algorithm. The basic idea of the Quorum algorithm is to require most nodes (more than half) in the cluster to be able to communicate and work normally in order to perform leader election and state change broadcasting. Therefore, the number of nodes in a ZooKeeper cluster should be odd to avoid ties. If the number of nodes in a certain subset does not satisfy the Quorum condition, then it cannot generate a leader node, nor can it process client requests. See the source codeorg.apache.zookeeper.server.quorum.flexible.QuorumMaj.java
private int half;
public QuorumMaj(Map<Long, QuorumServer> allMembers) {
this.allMembers = allMembers;
for (QuorumServer qs : allMembers.values()) {
if (qs.type == LearnerType.PARTICIPANT) {
votingMembers.put(Long.valueOf(qs.id), qs);
} else {
observingMembers.put(Long.valueOf(qs.id), qs);
}
}
half = votingMembers.size() / 2;
}
public boolean containsQuorum(Set<Long> ackSet) {
return (ackSet.size() > half);
}
ZooKeeper guarantees the following three orders:
- Global order: All servers execute the same requests in the same order.
- Causal ordering: If an event A occurs before another event B, then any client that observes B must also observe A.
- Client order: For the requests sent by the same client, any server will execute them in the order in which the client sends the requests.
二、Java API
Common java APIs provided by ZooKeeper, such as creating, reading, updating, deleting nodes, monitoring node changes, asynchronous operations, etc.
2.1 Basic node CRUD
Data in ZooKeeper is stored in a tree structure, and each node is called a ZNode. ZNode can store some metadata and user data, and can have multiple child nodes. ZNode also has some attributes, such as version number, timestamp, access control list, etc.
ZooKeeper provides some basic operations (CRUD) to create, read, update and delete ZNodes. These operations are atomic and either succeed or fail.
- Create: Create a new ZNode and specify its path, data and access control list. You can choose whether to create ephemeral nodes or sequential nodes.
- Read: Read the data and attributes of an existing ZNode. You can choose whether to register Watcher to monitor the change event of this ZNode.
- Update: Update the data or ACL of an existing ZNode. The expected version number needs to be specified, if it does not match the current version number, the update will fail.
- Delete: Delete an existing ZNode and all its child nodes. The expected version number needs to be specified, if it does not match the current version number, the deletion will fail.
The ZooKeeper client can use different languages and frameworks to call these basic operations, such as Java, Python, C++, etc. The following is a sample code for basic node CRUD using the java client:
Watcher watcher = event -> System.out.println("Watch event: " + event);
// 创建一个 ZooKeeper 实例并连接到服务器，指定 Watcher 和超时时间
ZooKeeper zk = new ZooKeeper("localhost:2181", 3000, watcher);
// 检查父节点是否存在，如果不存在就先创建父节点
Stat stat = zk.exists("/test", false);
if (stat == null) {
String parent = zk.create("/test", "test".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
System.out.println("创建父节点成功：" + parent);
}
// 创建一个新的 ZNode /test/node123，并设置其数据为 hello，
String path = zk.create("/test/node123", "hello".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
System.out.println("Created node: " + path);
// 读取 /test/node2 的数据和属性，并注册 Watcher 监听其变化事件
stat = new Stat();
byte[] data = zk.getData("/test/node123", watcher, stat);
System.out.println("Get node data: " + new String(data));
System.out.println("Get node stat: " + stat);
// 更新 /test/node2 的数据为 world，并指定期望的版本号为 -1 （表示忽略版本检查）
stat = zk.setData("/test/node123", "world".getBytes(), -1);
System.out.println("Set node stat: " + stat);
// 删除 /test/node2 及其所有子节点，并指定期望的版本号为 -1 （表示忽略版本检查）
zk.delete("/test/node123", -1);
System.out.println("Delete node success");
// 关闭 ZooKeeper 连接
zk.close();
2.2 Monitor node changes
ZooKeeper provides a mechanism called Watcher for clients to monitor ZNode change events. When a ZNode's data or child nodes change, ZooKeeper will send a notification to the client registered with Watcher.
A Watcher can be registered when reading ZNode data or a list of child nodes, or when checking for the existence of a ZNode. Watcher can only be triggered once. If the client wants to continuously monitor the changes of ZNode, it needs to re-register Watcher.
There are several types of Watchers:
- NodeCreated: Triggered when a non-existent ZNode is created.
- NodeDeleted: Triggered when an existing ZNode is deleted.
- NodeDataChanged: Triggered when the data of an existing ZNode is modified.
- NodeChildrenChanged: Triggered when the child node list of an existing ZNode changes.
Watcher also has the following features:
- The client can set multiple Watchers to monitor the same ZNode or different ZNodes.
- ZooKeeper guarantees that a client will not see changes to a node it sets a Watcher on until it first sees a Watcher event.
- ZooKeeper does not guarantee that every client will receive every Watcher event, because there may be network delays or other factors that cause events to be lost.
- ZooKeeper does not guarantee that the order of Watcher events is consistent with the order of actual changes, because there may be concurrent updates or other factors that may cause the order to be out of order.
The following is a sample code that uses the Java API to monitor node changes:
// 创建一个 ZooKeeper 实例并连接到服务器，指定超时时间
ZooKeeper zk = new ZooKeeper("localhost:2181", 3000, null);
// 创建一个 Watcher 实例，用于监听 /test/node3 的变化事件
Watcher watcher = new Watcher() {
@Override
public void process(WatchedEvent event) {
System.out.println("Watch event: " + event);
// 如果是 NodeCreated 或 NodeDataChanged 类型，则重新读取数据并注册新的 Watcher
if (event.getType() == Event.EventType.NodeCreated || event.getType() == Event.EventType.NodeDataChanged) {
try {
byte[] data = zk.getData("/test/node3", this, null);
System.out.println("New data: " + new String(data));
} catch (Exception e) {
e.printStackTrace();
}
}
}
};
// 检查父节点是否存在，如果不存在就先创建父节点
Stat stat = zk.exists("/test", false);
if (stat == null) {
String parent = zk.create("/test", "test".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
System.out.println("创建父节点成功：" + parent);
}
// 检查 /test/node3 是否存在，并注册 Watcher 监听其创建和修改事件
stat = zk.exists("/test/node3", watcher);
System.out.println("Check node stat: " + stat);
// 创建 /test/node3，并设置其数据为 hello
String path = zk.create("/test/node3", "hello".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
System.out.println("Created node: " + path);
// 更新 /test/node3 的数据为 world
stat = zk.setData("/test/node3", "world".getBytes(), -1);
System.out.println("Set node stat: " + stat);
// 关闭 ZooKeeper 连接
zk.close();
2.3 Asynchronous operation
The ZooKeeper Java API provides some asynchronous methods to perform some operations without blocking the main thread, and obtain the operation results through callback functions. Asynchronous methods usually end with async and need to pass in a StringCallback or DataCallback parameter as the callback function. For example:
// 创建一个 ZooKeeper 实例并连接到服务器，指定超时时间
ZooKeeper zk = new ZooKeeper("localhost:2181", 3000, null);
// 检查父节点是否存在，如果不存在就先创建父节点
Stat stat = zk.exists("/app", false);
if (stat == null) {
String parent = zk.create("/app", "test".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
System.out.println("创建父节点成功：" + parent);
}
// 异步创建 /app/config 节点，并设置数据为 "hello"
zk.create("/app/config", "hello".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT, (rc, path, ctx, name) -> {
// 处理创建结果
System.out.println("Create result: " + rc);
System.out.println("Create path: " + path);
System.out.println("Create name: " + name);
}, null);
// 异步读取 /app/config 节点的数据和状态
zk.getData("/app/config", false, (rc, path, ctx, data, state) -> {
// 处理读取结果
System.out.println("Get result: " + rc);
System.out.println("Get path: " + path);
System.out.println("Get data: " + new String(data));
System.out.println("Get stat: " + state);
}, null);
try {
Thread.sleep(200);
} catch (InterruptedException e) {
e.printStackTrace();
}
2.4 Session Management
ZooKeeper's session management is mainly through SessionTracker, which uses a bucketing strategy (managing similar sessions in the same block) for management, so that ZooKeeper can isolate sessions in different blocks and the same block Unified processing.
The default external service port of ZooKeeper is 2181. When the client starts, it first establishes a TCP connection with the server. From the first connection establishment, the life cycle of the client session also begins. Through this connection, the client can maintain a valid session with the server through heartbeat detection, and can also send requests to the ZooKeeper server and receive responses, and can also obtain the latest data change notifications from the server.
There are two types of ZooKeeper sessions: ephemeral and persistent. A short-lived session ends automatically when the client disconnects or times out, while a persistent session requires the client to explicitly close or delete it. Short-lived sessions can be used to implement functions such as distributed locks and Master election, while persistent sessions can be used to implement functions such as data publishing/subscribing and naming services.
import org.apache.zookeeper.*;
import org.apache.zookeeper.data.Stat;
// 定义一个类实现Watcher接口，用于监听会话状态和节点变化
public class EphemeralSessionExample implements Watcher {
// 定义一个ZooKeeper对象，用于连接和操作ZooKeeper服务器
private ZooKeeper zk;
// 定义一个构造方法，传入ZooKeeper服务器的地址和端口，并创建连接
public EphemeralSessionExample(String hostPort) throws Exception {
zk = new ZooKeeper(hostPort, 3000, this); // 设置会话超时时间为3秒
}
// 定义一个方法，用于创建或更新一个短暂节点，并设置数据和权限
public void createOrUpdate(String path, byte[] data) throws Exception {
Stat stat = zk.exists(path, false); // 检查znode是否存在，不设置监听器
if (stat == null) {
// 如果不存在，则创建znode
zk.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL); // 创建短暂的znode，并设置数据和权限
} else {
// 如果存在，则更新znode的数据
zk.setData(path, data, -1); // 更新znode的数据，并忽略版本号
}
}
// 定义一个方法，用于获取并打印当前会话的ID和状态
public void printSessionInfo() {
long sessionId = zk.getSessionId(); // 获取会话ID
String sessionState = zk.getState().toString(); // 获取会话状态
System.out.println("The session ID is: " + sessionId); // 打印会话ID
System.out.println("The session state is: " + sessionState); // 打印会话状态
}
// 实现Watcher接口中的process方法，用于处理事件通知
@Override
public void process(WatchedEvent event) {
System.out.println("Received a watch event: " + event); // 打印事件信息
if (event.getType() == Event.EventType.None && event.getState() == Event.KeeperState.SyncConnected) {
System.out.println("The client is connected to the server"); // 如果是连接成功的事件，打印连接信息
} else if (event.getType() == Event.EventType.None && event.getState() == Event.KeeperState.Expired) {
System.out.println("The session is expired"); // 如果是会话过期的事件，打印过期信息
try {
zk.close(); // 关闭ZooKeeper对象
} catch (Exception e) {
e.printStackTrace();
}
}
}
// 定义一个主方法，用于测试短暂会话的创建和更新
public static void main(String[] args) throws Exception {
EphemeralSessionExample ese = new EphemeralSessionExample("localhost:2181"); // 创建一个EphemeralSessionExample对象，并连接到本地的ZooKeeper服务器
ese.printSessionInfo(); // 打印当前会话的信息
ese.createOrUpdate("/test", "Hello".getBytes()); // 创建或更新一个短暂节点，并设置数据为"Hello"
Thread.sleep(5000); // 睡眠5秒，模拟客户端断开连接
ese.printSessionInfo(); // 打印当前会话的信息，此时应该是过期状态
}
}
3. Application scenarios and case analysis
3.1 Advantages and disadvantages
advantage
- Simple distributed coordination process: ZooKeeper provides a simple data model based on znode nodes in tree structure, which can store data and metadata, and supports temporary nodes, sequential nodes and other types. ZooKeeper also provides some primitive operations, such as create, delete, read, write, etc., and some advanced functions, such as listeners, subscribers, etc.
- Highly synchronized working mode: ZooKeeper guarantees data consistency among all nodes, and implements leader election and transaction log replication through the ZAB protocol. ZooKeeper also supports mutual exclusion and cooperation between server processes.
- Diversified distributed scenario applications: ZooKeeper can be used to implement functions and services in various distributed scenarios, such as configuration management, naming services, cluster management, load balancing, lock services, queue services, etc.
- Mature open source community and ecosystem: ZooKeeper is one of Apache's top projects, with a broad user base and an active developer community. ZooKeeper also has many frameworks and libraries developed based on it, such as Curator (a Java library), which provides many implementations of distributed ZooKeeper modes.
shortcoming
- Inefficient write performance: Since ZooKeeper needs to ensure strong consistency among all nodes, each write operation needs to be confirmed by the leader node and copied to all follower nodes. This adds latency and overhead to write operations and reduces throughput.
- Limited storage capacity: Since ZooKeeper data is stored in memory, it is limited by the size of the memory. If the amount of data is too large or the number of nodes is too large, it may cause insufficient memory or excessive GC pressure.
- Lack of dynamic expansion capability: Since ZooKeeper needs to maintain state information between all nodes and ensure the normal operation of mechanisms such as leader election and transaction log replication, the number of nodes cannot be increased or decreased arbitrarily. If you need to expand or reduce the size of the cluster, manual operations are required, which may affect the stability of the cluster.
3.2 Applicable Scenario Analysis
- Data publish/subscribe : It can be used as a configuration center to realize centralized management and dynamic update of configuration information. Publishers publish data to ZooKeeper nodes, and subscribers obtain data changes through listeners, thereby realizing data synchronization and sharing.
- Load balancing : It can be used as a service registry to realize service discovery and load balancing. The service provider registers its address information on the ZooKeeper node, and the service consumer obtains the available service list through ZooKeeper, and selects the appropriate service provider according to a certain strategy.
- Naming service : It can be used as a naming service to realize the generation and management of unique identifiers in distributed systems. Using ZooKeeper's sequential node feature, each node can be guaranteed to have a globally unique and ordered name.
- Distributed coordination/notification : A distributed coordination/notification mechanism can be implemented to realize collaboration and state synchronization among components in a distributed system. Using the temporary node feature of ZooKeeper, fault detection and recovery can be realized; using the listener feature of ZooKeeper, event-driven and message notification can be realized.
- Cluster management : It can be used as a cluster management tool to monitor and manage each node in the cluster. Using ZooKeeper's metadata storage feature, you can store the state information of each node in the cluster; using ZooKeeper's ZAB protocol feature, you can ensure data consistency between each node in the cluster.
- Master election : The Master election mechanism realizes the selection and switching of the master node in the master-slave mode in the distributed system. Using ZooKeeper's temporary sequential node feature, it can be guaranteed that only one of multiple candidates can become the master node, and re-election will be carried out when the master node fails.
- Distributed lock : It can be used as a distributed lock service to realize mutually exclusive access to shared resources in a distributed system. Using ZooKeeper's temporary sequential node feature, it can be guaranteed that only one of the multiple requesters can acquire the lock, and the lock will be released when the requester holding the lock releases or disconnects.
- Distributed queue : It can be used as a distributed queue service to implement first-in-first-out (FIFO) or priority processing of tasks or messages in a distributed system. Using ZooKeeper's sequential node feature, you can ensure that the elements in the queue are arranged in the order of insertion or priority, and support concurrent insertion or deletion operations.
3.3 Actual case
- Data publishing/subscribing : Distributed systems such as Hadoop, HBase, and Kafka all use ZooKeeper as the configuration center to realize centralized management and dynamic update of configuration information. For example, the HMaster node in HBase will store the metadata information of the cluster (such as the RegionServer list, Region distribution, etc.) on the ZooKeeper node, and the client and other RegionServer nodes can obtain this information through ZooKeeper, and timely renew.
- Load balancing : Microservice frameworks such as Dubbo and Spring Cloud all use ZooKeeper as a service registry to realize service discovery and load balancing. For example, service providers in Dubbo will register their address information on ZooKeeper nodes, and service consumers will obtain a list of available services through ZooKeeper, and choose according to certain strategies (such as random, polling, least active, etc.) suitable service provider.
- Naming service : SolrCloud is a distributed search platform that uses ZooKeeper as a naming service to realize the generation and management of unique identifiers in distributed systems. For example, each collection in SolrCloud has a unique name, each shard has a unique number, and each replica has a unique ID. These names, numbers, and IDs are all generated and stored through ZooKeeper's sequential node feature.
- Distributed coordination/notification : Storm is a distributed real-time computing framework that uses ZooKeeper as a distributed coordination/notification mechanism to achieve collaboration and state synchronization between components in a distributed system. For example, a Nimbus node in Storm is responsible for managing the entire cluster and assigning tasks to multiple Supervisor nodes; Supervisor nodes are responsible for starting and stopping Worker processes; Worker processes are responsible for performing specific computing tasks. These nodes need to communicate and coordinate through ZooKeeper.
- Cluster management : Redis is a high-performance memory database that supports master-slave replication and sentinel mode to achieve high availability. Redis uses ZooKeeper as a cluster management tool to monitor and manage each node in the cluster. For example, in sentinel mode, the sentinel node will register itself to the temporary node of ZooKeeper and send heartbeats to it periodically; when the master node fails, the sentinel node will conduct leader election through ZooKeeper and notify other sentinel nodes to switch slave nodes as the master node.