Zookeeper-1-Introduction

Zookeeper-1-Introduction

1 Overview

 Zookeeper is a project that provides coordination services for distributed applications

 From the perspective of design patterns, it is a distributed service management framework based on the observer pattern design. It is responsible for storing and managing widely watched data (observed), and at the same time accepting the registration of observers. When the observed data changes, Zookeeper is responsible for notifying those observers registered on Zookeeper

 This is similar to the Leader / Follower management mode in the cluster

 Simply put, Zookeeper is the file system and notification mechanism

2. Features

1. The Zookeeper cluster consists of a master (Leader) and multiple followers (Follower)

   The master node is responsible for the initiation and resolution of voting, as well as updating the system status

   The slave node is responsible for receiving the client's request and returning the response to the client. And participate in voting in the voting master node

2. As long as more than half of the nodes in the Zookeeper cluster survive, the cluster can provide services normally

3. Each node stores the same copy of data, no matter which node the client accesses, the data obtained is the same

4. Multiple update requests from the same client are executed in the order in which the requests are sent

5. An update operation either succeeds or fails, ensuring the transactional characteristics of data update

6. Within a certain time frame, the client can always read the latest data (the amount of data stored on ZK is not large, and each node is notified that the update speed is fast)

3. Data structure

 The data model of Zookeeper is similar to the Unix file system and is also a tree structure. Each node on it is called ZNode

 Each ZNode stores 1MB of data by default, and it can be found through a unique path

 ZNode is divided into two categories: persistent nodes and temporary nodes

 A persistent node means that the node will not be deleted when the client and server are disconnected. For temporary nodes, when the client and server are disconnected, the node will delete itself

 ZNode has 4 types of directory nodes:

1. Persistent Directory Node (PERSISTENT)

   After the client and server are disconnected, the directory still exists

2. Persistent ordered directory node (PERSISTENT_SEQUENTIAL)

   Zookeeper will sequentially number the node. At the same time, the directory still exists after the client and server are disconnected

3. Temporary Directory Node (EPHEMERAL)

   After the client and server are disconnected, the directory is deleted by itself

4. Temporary ordered directory node (EPHEMERAL_SEQUENTIAL)

   Zookeeper will sequentially number the node. After the client and server are disconnected, the directory still exists

4. Election mechanism

 Due to Zookeeper's half mechanism, that is, more than half of the machines in the cluster survive, the cluster can provide services normally. So the number of Zookeeper cluster nodes is suitable for odd numbers

 Although Zookeeper does not explicitly specify Leader and Follower in the configuration file, its internal election mechanism will temporarily select a master node, and then the remaining nodes are slave nodes

 The election mechanism is that when the number of votes obtained by a node exceeds half of the cluster nodes, the node is the master node

 Start each node in sequence, and then the votes are determined by the number of the node machine. For example: Now there are 3 nodes, which are started from small to large according to the machine number. When the second node is started, since its number is greater than the previous node, it now has 2 votes, and the number of votes exceeds the number of cluster nodes. Half (1.5), so it becomes the master node

5. Applicable scenarios

[1] Unified configuration file management

 Centralized configuration center, suitable for multiple devices to share configuration information, and the configuration information will dynamically change

 When the application starts, the client takes the initiative to obtain configuration information on the ZK cluster, and registers Watcher to monitor (pull)

 When a configuration file is changed, ZK will actively push the change information to the client, and start the callback function monitored by Watcher (push)

 According to the business logic, the client actively obtains the latest configuration information and updates its status (pull)

[2] Load balancing (soft)

 When the server node is started, register the relevant domain name information on the ZK cluster. When the request arrives at the server, the ZK cluster resolves the requested domain name, and according to the latest server node status, selects the appropriate machine to process the request, and returns a response

 ZK cluster regularly monitors and scans the status of each server node, and dynamically updates node information

 At the same time, a console is provided to facilitate management of ZK cluster

[3] Cluster monitoring

 By registering the server cluster to ZK, you can easily know how many servers are currently providing services and the working status of each server. At the same time, you can conveniently perform offline operations on a node, and add new nodes, etc.