Welcome to follow our wechat official account: Shishan100
My new course ** “C2C e-commerce System Micro-service Architecture 120-day Practical Training Camp” is online in the public account ruxihu Technology Nest **, interested students, you can click the link below for details:
120-Day Training Camp of C2C E-commerce System Micro-Service Architecture
First, write first
Redisson is an open source framework for implementing Redis distributed locks, and ZooKeeper is an open source framework for implementing Distributed locks. Redisson is an open source framework for implementing Distributed locks.
Similarly, I am directly based on the common open source framework for ZooKeeper (zK) distributed lock implementation.
Generally, in addition to large companies that package distributed lock frameworks by themselves, we suggest that you use these open source frameworks packaged distributed lock implementation, which is a relatively fast and cost-effective way.
ZooKeeper distributed lock mechanism
Let’s take a look at the whole process of multiple clients acquiring and releasing ZK distributed lock and the principle behind it.
First, let’s look at the following diagram. What would happen if two clients were fighting for a distributed lock on zK?
If you are not familiar with ZK, it is recommended to search for some basic concepts, such as what node types zK has and so on.
See the image above. Zk has a lock, and the lock is a node on ZK. Then, both clients need to acquire the lock. How do you do that?
Let’s assume client A gets ahead of zK and initiates A distributed lock request. This lock request uses A special zK concept called “temporary order node”. 台湾国
In simple terms, it is directly under the lock” my_lock” node, create a sequence node, this sequence node has a node number internal maintenance zK.
For example, the first client to create a sequence node, zK internal name will be: XXX-000001. Then the second client takes a sequence node, which ZK might call: XXX-000002. Notice that the last number is increasing, starting at 1. Zk will maintain this order.
So at this point, if client A initiates the request first, we’re going to get A sequence node, and if you look at the figure below, the Curator framework might look something like this:
So you see, client A initiates A lock request, and it’s going to put A temporary sequence node under the node that you’re trying to lock, and that’s A bunch of names that the Exhibit framework itself generated.
And then, that last number is “1”. Notice that client A is the first one to initiate the request, so the sequence node is numbered “1”.
Client A then creates A sequence node. That’s not all. He’ll look at all the children of the lock” my_lock”, and they’ll be sorted by order, and he’ll get something like this:
Then client A makes A critical judgment call, which says: Alas! Brother, is the sequence node I created the first in this set?
If it is, then I can lock it! Since I was the first person to create sequential nodes, I was the first person to try distributed locking.
Bingo! Lock successful! Let’s look at the picture below and get a sense of what’s going on.
Then, if client A is done locking and client B wants to lock, it will do the same thing: first, it will create A temporary sequential node under the lock” my_lock”, which will be named something like:
Take a look at the picture below:
Client B is the second to create the sequential node, so zK maintains the serial number “2” internally.
Client B then adds the lock judgment logic and queries all the children under the “my_lock” lock node, in order of ordinal, and sees something like:
Also check whether the sequence node you created is the first one in the collection.
Obviously not, the first node is the sequence node created by client A, the one numbered “01”. So lock failed!
When the lock fails, client B uses ZK’s API to add a listener to the first sequence node above his sequence node. ** ZK can naturally implement a node listening.
If you do not know the basic usage of ZK, you can search baidu, very simple. The sequential nodes of client B are:
Isn’t his last sequential node, this one down here?
The sequential node created by client A!
Therefore, client B will do the following:
This node plus a listener, listen to whether this node is deleted and other changes! Look at the picture below.
Then, client A, after locking, may process some code logic and release the lock. So, what is the process of releasing the lock?
In fact, it is very simple, is the sequence node created in zK, that is:
This node is deleted.
After the node is deleted, zK notifies the listener listening to the node, which is the listener added by client B, saying: Brother, the node you are listening to has been deleted. Someone has released the lock.
At this point, client B’s listener senses that the last sequential node has been deleted, that is, one of the clients before it has released the lock.
At this point, client B will be notified to try again to acquire the lock, that is, to obtain the set of children under the “my_lock” node, where:
The collection is now the only sequence node created by client B!
Client B then decides that it is the first sequential node in the set. Bingo! Lock it now! Directly complete the lock, run the subsequent business code, after running again release the lock.
Third, summary
In fact, if there are N clients such as client C and client D scrambling for a ZK distributed lock, the principle is similar.
- Everyone comes up and creates temporary sequential nodes one by one under a lock node
- If you are not the first node, add a listener to your previous node
- As long as the last node to release the lock, they will row to the front, equivalent to a queuing mechanism.
Another purpose of using the temporary order node is that if a client creates a temporary order node, it doesn’t matter if it goes down accidentally. Zk will automatically delete the corresponding temporary order node when it senses that the client is down, which is equivalent to automatically releasing the lock or unqueuing itself.
Finally, let’s look at a process for locking and releasing locks using the Curator framework:
In fact, open source framework is this good, convenient. The implementation principle of zK distributed lock of this Curator framework is actually that.
But if you’re going to implement a set of that code manually. It’s a bit of a hassle to figure out all the details, exception handling and so on. So if you consider using ZK distributed lock, you can refer to the idea of this article.
END
If there is any harvest, please help to forward, your encouragement is the biggest power of the author, thank you!
A large wave of micro services, distributed, high concurrency, high availability of original series of articles is on the way
Please scan the qr code belowContinue to pay attention to:
Architecture Notes for Hugesia (ID: Shishan100)
More than ten years of EXPERIENCE in BAT architecture