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

This article mainly explains "the implementation of Zookeeper's distributed lock". The explanation in this article is simple and clear, easy to learn and understand. Please follow the ideas of Xiaobian and go deep into it slowly to study and learn "the implementation of Zookeeper's distributed lock" together.

1. background

Recently learning Zookeeper, when I first came into contact with Zookeeper, I didn't know what Zookeeper was used for. And a lot of the literature describes Zookeeper as a "Unix/Linux-like file system" middleware, which makes it difficult for me to associate Unix/Linux-like Zookeeper with distributed applications. Later, after reading the two books "Zookeeper Distributed Process Collaborative Technology Detailed Explanation" and "From Paxos to Zookeeper Distributed Consistency Principles and Practice", and writing some CURD demos, I had a preliminary understanding of Zookeeper. But more superficial, in order to further deepen the understanding of Zookeeper, I used my spare time to write the corresponding demo of this article-distributed lock implementation based on Zookeeper. By writing this distributed lock demo, I have a better understanding of Zookeeper's watcher mechanism, Zookeeper's purpose, etc. However, the distributed lock I wrote is still relatively simple, and the implementation is not elegant enough. It is only an exercise and is for reference only. Okay, that's enough digression, let's talk about distributed lock implementation based on Zookeeper.

2. Implementation of Exclusive Lock and Read-Write Lock

In this chapter, I will explain the detailed implementation process of exclusive lock and read-write lock respectively, and provide corresponding flow charts to help you understand the implementation process. Let's talk about exclusive lock implementation first.

2.1 Implementation of Exclusive Lock

Exclusive locks are also called exclusive locks, and their purpose is easy to understand literally. That is, if an operation O1 locks the process of accessing resource R1, other operations are not allowed to access resource R1 until operation O1 ends accessing resource R1. That's a simple definition of an exclusive lock, but how does it fit into Zookeeper's Unix/Linux-like file system structure? Before we lock the answer, let's look at a picture:

Figure 1: Zookeeper node structure for exclusive locks

As shown in the figure above, for exclusive locks, we can regard resource R1 as a lock node, operation O1 accessing resource R1 as creating a lock node, and releasing resource R1 as deleting a lock node. In this way, we will define the exclusive lock corresponding to the specific Zookeeper node structure, and obtain the lock by creating the lock node and releasing the lock by deleting the node. The detailed process is as follows:

Multiple clients compete to create a temporary lock node. One client successfully creates a lock node. Other clients set watchers on the lock node. The client holding the lock deletes the lock node or the client crashes. Zookeeper deletes the lock node. Other clients obtain the notification that the lock node is deleted. Repeat the above four steps until no client is waiting to acquire the lock. The specific implementation steps of the above exclusive lock are not complicated to understand, and will not be described here.

Figure 2: Acquisition of Exclusive Lock Flowchart 2.2 Implementation of Read-Write Lock After the implementation of exclusive lock, this section talks about the implementation of read-write lock. The read-write lock includes a read lock and a write lock. Operation O1 adds a read lock to resource R1 and obtains the lock. Other operations can set a read lock on resource R1 at the same time to perform shared read operations. If operation O1 places a write lock on resource R1 and obtains the lock, other operations that set different types of locks on resource R1 will be blocked. In summary, read locks are shared, while write locks are exclusive. So in Zookeeper, what kind of node structure can we use to implement the above operations?

Figure 3 Zookeeper node structure of read-write locks In Zookeeper, because the node structure of read-write locks and exclusive locks is different, clients of read-write locks do not have to compete to create lock nodes. So at the beginning, all clients create their own lock nodes. If nothing unexpected happens, all lock nodes can be successfully created, and the lock node structure is shown in Figure 3. After that, the client obtains all child nodes under/share_lock from Zookeeper and judges whether it can obtain the lock. If the client creates a read-lock node, the conditions for obtaining the lock (one of which can be satisfied) are as follows: The node number created by itself ranks before all other child nodes. The node created by itself has no write-lock node. If the client creates a write-lock node, because the write-lock is exclusive. So the conditions for acquiring locks are simpler, just make sure that the lock node you create is ranked before other child nodes. Unlike exclusive locks, read-write locks are a bit more complicated to implement. There are two ways to implement read-write locks, each with similarities and differences. Let's talk about these two ways. The first implementation of read-write lock is to set watcher on/share_lock node. When the child node under/share_lock is deleted, the client without lock receives notification of change of child node of/share_lock. After receiving the notification, the client rejudges whether the child node created by itself can acquire the lock, and if it fails, waits for the notification again. The detailed process is as follows: all clients create their own lock nodes, obtain all child nodes under/share_lock from Zookeeper, and set watcher on/share_lock node to determine whether the lock nodes they create can obtain locks, and if so, hold locks.

Otherwise, keep waiting.

The client holding the lock deletes its own lock node, and other clients receive the notification of the change of the/share_lock child node. Repeat steps 2, 3, and 4 until no client is waiting to acquire the lock. The flowchart of the above steps is as follows:

Figure 4: Acquire Read-Write Lock Implementation 1 Flowchart The process of acquiring read-write lock above is not complicated, but there are performance problems. For example, after the first lock node host1-W-00000001 is removed, Zookeeper will distribute notification of the change of the/share_lock child node to all clients. However, in fact, besides affecting the client corresponding to host2-R-00000002 node, distributing the child node change notification to other clients is useless, because other clients cannot obtain the lock even if they obtain the notification. Therefore, some optimization needs to be done here. The optimization measure is to let the client only acquire the lock when the node it cares about is deleted. The second implementation of read-write locks After understanding the disadvantages of the first implementation of read-write locks, we optimized this implementation. Here the client no longer monitors the/share_lock node, but only monitors the nodes it cares about. Still using the lock node structure of FIG. 3 as an example, client C2 corresponding to host2-R-00000002 only needs to monitor whether host1-W-00000001 node is deleted. Client C3 corresponding to host3-W-00000003 only needs to monitor whether host2-R-00000002 node is deleted. Only when host2-R-00000002 node is deleted can client C3 obtain the lock. When host1-W-00000001 node is deleted, the notification generated is useless to client C3, and even if client C3 responds to the notification, it cannot obtain the lock. To summarize, different clients care about lock nodes differently. If the client creates a read lock node, the client only needs to find the last write lock node with a lower serial number than the read lock node and set the watcher. If it is a write lock node, it is simpler. The client only needs to set the watcher on the node above it. The detailed process is as follows: all clients create their own lock nodes from Zookeeper to obtain all child nodes under/share_lock to determine whether the lock nodes they create can obtain locks, and if so, hold locks.

Otherwise, set watcher on the lock node you care about

The client holding the lock deletes its own lock node. A client receives the notification that the node is deleted and obtains the lock. Repeat step 4 until no client is waiting to obtain the lock. The flowchart for the above steps is as follows:

Figure 5 Get read-write lock implementation 2 Flowchart Thank you for reading, the above is the content of "Zookeeper distributed lock implementation", after learning this article, I believe that everyone has a deeper understanding of Zookeeper distributed lock implementation, the specific use of the situation still needs to be verified by practice. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

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.