Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you all the questions about ZooKeeper. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

1. Interviewer: have you ever used Zookeeper at work? Do you know what it is and what's its use?

"I am a small vegetable chicken:"

Some have used ZooKeeper as the "registry of dubbo" and ZooKeeper for "distributed locks".

ZooKeeper, an open source "distributed coordination service", is a cluster manager that provides easy-to-use interfaces to users.

Functions such as data publish / subscribe, load balancing, naming services, distributed coordination / notification, cluster management, Master election, distributed locking and distributed queues can be implemented based on Zookeeper.

The purpose of Zookeeper: naming service, configuration management, cluster management, distributed lock, queue management

Doesn't the use and function mean the same thing? Give me a look and let me feel it.

two。 Interviewer: what is naming service, what is configuration management, and what is cluster management?

"I am a small vegetable chicken (fortunately, I have brushed the interview questions), and I am fearless."

"naming service is":

Naming service refers to obtaining the address of a resource or service through a "specified name". Zookeeper can create a "globally unique path" that can be used as a name. The named entity can be "the machine in the cluster, the address of the service, or a remote object" and so on. The list of service addresses in some distributed service frameworks (RPC, RMI). By using naming services, client applications can obtain the entity, service address and provider information of resources according to specific names.

Configuration Management:

In actual project development, we often use .properties or xml to configure a lot of information, such as database connection information, fps address port, and so on. Because your program is generally distributed deployed on different machines (if you are a stand-alone application when I did not say), if you put these configuration information "saved in zk's znode node", when you want to modify the configuration, that is, znode will change, you can change the configuration by changing the contents of a directory node in zk, using "watcher to notify each client", thus changing the configuration.

"Cluster management"

Cluster management includes cluster monitoring and cluster control, which is actually monitoring the status of cluster machines, eliminating machines and adding machines. Zookeeper can facilitate the management of cluster machines. It can monitor the changes of znode nodes in real time. Once a machine is found to be dead, the machine will be disconnected from zk, the corresponding temporary directory node will be deleted, and all other machines will be notified. The addition of new machines is similar, and all machines are notified that a new brother directory has been added.

3. Interviewer: you mentioned the znode node. How many types of znode do you know? what is the data model of zookeeper?

"I'm a little vegetable chicken (let me think about it first):"

Data Model of zookeeper

ZooKeeper's view data structure, much like the Unix file system, is also tree-like, making sure that each path is unique. The node of zookeeper is called "znode". It can be identified by "path". The structure diagram is as follows:

Four types of znode

According to the life cycle of nodes, znode can be divided into four types: persistent node (PERSISTENT), persistent sequential node (PERSISTENT_SEQUENTIAL), temporary node (EPHEMERAL) and temporary sequential node (EPHEMERAL_SEQUENTIAL).

Persistent node (PERSISTENT)

Once such nodes are created, they will always exist on the Zk server. Until it is manually deleted.

Persistent sequential node (PERSISTENT_SEQUENTIAL)

Its basic characteristics are the same as persistent nodes, but the difference is that it increases sequency. The parent node maintains a self-increasing number for the order in which the child nodes are created.

Temporary node (EPHEMERAL)

The life cycle of the temporary node is bound to the client session, and once the client session fails (non-TCP connection is disconnected), the node is automatically cleaned up. Zk specifies that temporary nodes can only be leaf nodes.

Temporary sequential node (EPHEMERAL_SEQUENTIAL)

The basic characteristics are the same as temporary nodes, adding sequential properties.

Interviewer: do you know what is stored in the znode node? What is the maximum data size of each node?

"I am a small vegetable chicken:"

What is stored in the znode node?

The code for the Znode data node is as follows

Public class DataNode implements Record {byte data []; Long acl; public StatPersisted stat; private Set children = null;}

Haha, Znode contains "storage data, access permissions, child node references, node status information", as shown in the figure:

Business data information stored by "data:" znode

"ACL:" records the client's access to znode nodes, such as IP, and so on.

"child:" the child node reference of the current node

"stat:" contains the status information of the Znode node, such as "transaction id, version number, timestamp", and so on.

What is the maximum data size of each node?

To ensure high throughput and low latency, as well as data consistency, znode is only suitable for storing very small data, no more than 1m, preferably less than 1K.

Interviewer: do you know the monitoring mechanism on the znode node? Talk about the Zookeeper watch mechanism.

"I am a small vegetable chicken:"

Watcher mechanism

How the monitoring mechanism works

Summary of Watcher characteristics

Watcher snooping mechanism

Zookeeper allows the client to register a Watcher snooping with a Znode on the server. When some specified events on the server trigger the Watcher, the server will send an event notification to the designated client to implement the distributed notification function, and then the client will make business changes according to the Watcher notification status and event type.

Watcher can be understood as a trigger in which the client registers on a Znode. When the Znode node changes (add, delete, modify and check), the registration event corresponding to the Znode will be triggered, and the registered client will receive an asynchronous notification and make business changes.

How Watcher snooping mechanism works

The Watcher mechanism of ZooKeeper mainly includes three parts: client thread, client WatcherManager and Zookeeper server.

When the client registers the Watcher with the ZooKeeper server, the Watcher object is stored in the client's WatchManager.

When the zookeeper server triggers the watcher event, it sends a notification to the client, and the client thread fetches the corresponding Watcher object from the WatcherManager to execute the callback logic.

Summary of Watcher characteristics

A Watch event is an one-time trigger. Once triggered, the client will only receive such a message once.

"Asynchronous:" the Zookeeper server sends watcher notification events to the client asynchronously, and can not be expected to monitor every change of the node. Zookeeper can only guarantee the final consistency, but not strong consistency.

"lightweight:" the Watcher notification is very simple, just notifying that an event has occurred, not passing the contents of the event object.

"client serial:" the process of performing a client Watcher callback is a serial synchronization process.

GetData, exists, getChildren methods are used to register watcher

Create, delete and setData methods are used to trigger watcher

Interviewer: you have some knowledge of the data structure of Zookeeper, so tell me about the characteristics of Zookeeper.

"I am a little vegetable chicken: (I have memorized books, ah )"

Zookeeper guarantees the following distributed consistency features:

"Sequential consistency": transaction requests from the same client will eventually be applied to the ZooKeeper in strict order.

Atomicity: the processing results of all transaction requests are consistent on all machines in the cluster, that is, either all the machines in the cluster successfully apply a transaction, or none of them are applied.

"single view": no matter which ZooKeeper server the client connects to, it sees the same server-side data model.

"Reliability:" once the server successfully applies a transaction and completes the response to the client, the server state change caused by the transaction will be retained forever.

"Real-time (ultimate consistency):" Zookeeper only ensures that the client will eventually be able to read the latest data status from the server within a certain period of time.

Interviewer: you just mentioned order consistency, so how does zookeeper ensure the order consistency of transactions?

"Little vegetable Chicken me: (finished with this question will not)"

You can take a look at this article (the answer to this question comes from this article): talk about the order consistency of ZooKeeper [1] https://time.geekbang.org/column/article/239261

You need to understand the transaction ID, that is, zxid. ZooKeeper selects a new master node by comparing the zxid of each node with the machine ID during the election. The zxid is generated by the Leader node. When there is a new write event, the Leader generates a new zxid and broadcasts with the proposal. Each node locally stores the zxid,zxid of the most recent transaction, so the larger the zxid, the latest data.

The rules for generating ZXID are as follows:

ZXID consists of two parts:

Term of office: after the completion of this election, until the next election, the same Leader will be responsible for coordinating the writing

Transaction counter: monotonously increments, adding one to each write that takes effect.

The low 32 bits of ZXID are counters, so during the same term, the ZXID is continuous, and each node keeps its own newly effective ZXID. By comparing the difference between the newly proposed ZXID and its latest ZXID, to ensure that transactions take effect in strict order.

Interviewer: you mentioned Leader. Do you know how many roles there are in Zookeeper server? what are the working states of Server under Zookeeper?

"I am a small vegetable chicken:"

Zookeeper server role

There are three roles in Zookeeper cluster: Leader, Follower and Observer.

"Leader"

Leader server is the core of the whole working mechanism of ZooKeeper cluster, and its main work is as follows:

The only scheduler and processor of transaction requests to ensure the sequence of cluster transactions

Scheduler of each service within the cluster

"Follower"

The Follower server is a follower of ZooKeeper cluster status, and its main work is as follows:

Handle client non-transaction requests and forward transaction requests to the Leader server

Vote to participate in transaction request Proposal

Vote in the Leader election

"Observer"

Observer is a server role introduced in version 3.3.0 that acts as an observer-observing the latest state changes in the ZooKeeper cluster and synchronizing those state changes. Its work:

Handle non-transaction requests from the client and forward transaction requests to the Leader server

Do not participate in any form of voting

Working status of Server under Zookeeper

The server has four states, namely LOOKING, FOLLOWING, LEADING, and OBSERVING.

1.LOOKING: look for Leader status. When the server is in this state, it assumes that there is no Leader in the current cluster, so it needs to enter the Leader election state.

2.FOLLOWING: follower status. Indicates that the current server role is Follower.

3.LEADING: leadership status. Indicates that the current server role is Leader.

4.OBSERVING: observer status. Indicates that the current server role is Observer.

9. Interviewer: you said that the server role is based on ZooKeeper cluster, so why don't you draw the ZooKeeper cluster deployment diagram? how does ZooKeeper ensure the data consistency between master and slave nodes?

"I am a small vegetable chicken:"

ZooKeeper cluster deployment diagram

ZooKeeper cluster is an one-master and multi-slave structure:

If the data is written, it is first written to the master server (master node), and then the slave server is notified.

If you are reading data, you can read both the master server and the slave server.

How to ensure data consistency between Master and Slave nodes in ZooKeeper

We know that the cluster is a master-slave deployment structure, and there are only two main problems to ensure the consistency of master-slave nodes:

"the main server is down or rebooted."

"synchronize data between master and slave servers" ~

Zookeeper uses ZAB protocol (Zookeeper Atomic Broadcast,Zookeeper Atomic broadcast Protocol) to ensure the data consistency of master and slave nodes. ZAB protocol supports two modes of "crash recovery and message broadcasting", which solves these two problems very well.

Crash recovery: Leader is dead, enter this mode and choose a new leader

Message broadcast: synchronize updated data from Leader to all Follower

The Leader server hangs, and all the servers in the cluster enter the LOOKING state. First, they elect a new Leader server; then, the new Leader server synchronizes with the Follower service in the cluster, and when more than half of the machines in the cluster complete data synchronization with the Leader server, exit the recovery mode and enter the message broadcast mode. The Leader server begins to receive transaction requests from the client to generate transaction Proposal for transaction request processing.

Interviewer: Leader is dead and has entered a crash recovery. How do you elect Leader? Why don't you talk about the ZooKeeper election mechanism?

"I am a small vegetable chicken:"

When the server is started or the server is running (Leader is down), it will enter the Leader election. Let's take a look. Suppose there are five servers in the ZooKeeper cluster. They are servers 1, 2, 3, 4 and 5, respectively, as shown in the figure:

Leader election initiated by the server

During the initialization phase of zookeeper cluster, the server (myid=1-5) starts "in turn", and zookeeper elects Leader~.

Server 1 (myid=1) starts, currently has only one server, and cannot complete the Leader election

Server 2 (myid=2) starts, when the two servers can communicate with each other and begin to enter the Leader election phase

1. Each server sends out a vote

Both server 1 and server 2 vote as Leader servers. The basic elements of voting include: the myid and ZXID of the server, which we represent as (myid,ZXID). In the initial phase, both server 1 and server 2 will vote for themselves, that is, server 1 will vote (1d0), server 2 will vote (2d0), and then each will send the vote to all other machines in the cluster.

two。 Accept votes from various servers

Each server accepts votes from other servers. At the same time, the server will verify the validity of the vote, whether the current round of voting, whether from the LOOKING status of the server.

3. Deal with voting

If you receive votes from other servers, you will follow the PK,PK rules of other people's votes with your own votes:

Check ZXID first. Servers with larger ZXID are preferred as leader.

If the ZXID is the same, compare the servers with larger myid,myid as leader. Server 1's vote is (1d0), it receives a vote (2d0), and both zxid is 0, because the myid=2 received is larger than its own myid=1, so it updates its vote to (2d0), and then resends the vote. For server 2, you no longer need to update your vote, just send out the last vote information.

4. Statistical voting

After each vote, the server counts all the votes to determine whether more than half of the machines have received the same voting information. Server 2 receives two votes, less than 3 (nmax 2pm 1 is total server 5), so it continues to maintain LOOKING status

Server 3 (myid=3) starts and continues to enter the Leader election phase

In line with the previous process, servers 1 and 2 vote for themselves first, because server 3 has the largest myid, so everyone votes for it instead. At this point, the server has 3 votes (greater than or equal to nmax 2pm 1), so server 3 is elected as Leader. Server 1, 2, change state to FOLLOWING, server 3, change state to LEADING

Server 4 starts and initiates an election.

At this time, the server 1 and 2 is no longer in the LOOKING state and will not change the ballot information. The result of ballot information: server 3 is 3 votes, server 4 is 1 vote. Server 4 and change the status to FOLLOWING

Server 5 starts and initiates an election.

Similarly, the server votes for server 3, server 5 and changes the status to FOLLOWING

Voting closes and server 3 is elected as Leader

Leader election during server operation

Five servers (myid=1-5) of the zookeeper cluster are running. Suddenly, Leader server 3 goes down, and the Leader election begins.

1. Change the state

After the Leader server dies, the remaining non-Observer servers change their server status to LOOKING and begin the Leader election process.

two。 Each server initiates a vote

Each server votes for itself, and because it is running, the ZXID for each server may be different. Assuming that the zxid of service 1Jing 2Jing 4Jing 5 is 333 Magi 666 respectively, 999 Jet 888, then a vote is generated (1333), (2666), (4999) and (5888), respectively, and then the vote is sent to all other machines in the cluster.

3. Accept votes from various servers

4. Deal with voting

The voting rules are the same as during the startup of the Zookeeper cluster, checking the ZXID first, and the large ones as Leader, so it is clear that the server zxid=999 has priority.

5. Statistical voting

6. Change the server state

Interviewer: you mentioned earlier that Zookeeper distributed locks were used in the project. Why don't you talk about the implementation principle of zk distributed locks?

"I am a small vegetable chicken:"

Zookeeper uses the temporary sequential node feature to implement distributed locks.

Get the lock process (create a temporary node and check the lowest serial number)

Release locks (delete temporary nodes, listen for notifications)

Lock acquisition process

When the first client requests, the Zookeeper client creates a persistent node / locks. If it (Client1) wants to acquire the lock, it needs to create a sequential node lock1. Lock1 under the locks node. As shown in the picture

Next, the client Client1 looks for all the temporary sequence child nodes under the locks to determine whether its own node lock1 is the one with the lowest sort, and if so, it successfully acquires the lock.

At this time, if another client client2 comes to try to acquire the lock, it will create another temporary node lock2 under locks.

The client client2 also looks for all the temporary sequence child nodes under the locks to determine whether its own node lock2 is the smallest. At this time, it finds that lock1 is the smallest, so it fails to acquire the lock. If it fails to acquire the lock, it will not be reconciled. Client2 registers the Watcher event with its ordered node lock1, which is used to listen for the existence of lock1, that is to say, the client2 lock grab failure enters the waiting state.

At this point, if another client Client3 tries to acquire the lock, it will create another temporary node lock3 under locks

Similarly, client3 will also find all the temporary sequence child nodes under the locks, determine whether their own node lock3 is the smallest, and find that they are not the smallest, and then fail to acquire the lock. It is also unwilling to register the Watcher event with the node in front of it, lock2, to listen for the existence of the lock2 node.

Release lock

Let's take a look at the lock release process. Zookeeper's "client business completion or failure" will delete the temporary node and release the lock. If the task is completed, Client1 explicitly invokes the instruction to delete lock1

If the client fails, the lock1 will be deleted automatically according to the characteristics of the temporary node.

After the lock1 node was deleted, Client2 was happy because it had been listening to lock1. When the lock1 node is deleted, the Client2 is notified immediately, and it also looks for all temporary sequential child nodes under the locks. When the lock2 is the minimum, the lock is obtained.

By the same token, after Client2 acquired the lock, Client3 was also eyeing it covetously, ah ~

twelve。 Interviewer: OK, last question, tell me about the relationship between dubbo and Zookeeper. Why did you choose Zookeeper as the registry?

I am a little vegetable chicken (after answering so many questions, will you not give it to me?):

The registry of dubbo can choose Zookeeper,memcached,redis and so on. Why did you choose Zookeeper because of its functional features?

Naming service, the service provider writes url to the specified node of the Zookeeper, and completes the service publication.

Load balancing, the carrying capacity of the registry is limited, but Zookeeper clusters with web applications can easily achieve load balancing.

Zk supports listening for events, which is especially suitable for publish / subscribe scenarios, such as dubbo producers and consumers.

The data model is simple, and the data is stored in memory, which can be described as high performance.

Other features of Zookeeper can be moved out to talk about.

These are the problems of ZooKeeper shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.