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

This article is to share with you about the practical use of distributed locks in web projects. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

1. Watch lock

From update

4. Exclusive lock

Exclusive locks, also known as write locks, differ from shared locks in that other threads can neither read nor modify them.

7. Optimistic lock

Optimistic locks don't actually lock. As the name implies, it is optimistic that it defaults that other threads will not modify the data, so it will not be locked. Just before the update to determine whether other threads have modified the data during this period, if so, it will be handed over to the business layer to deal with.

At present, almost many large websites and applications are distributed, and the problem of data consistency in distributed scenarios has always been an important topic. Distributed CAP theory tells us that "no distributed system can satisfy Consistency, Availability and Partition tolerance at the same time, but only two at the same time." Therefore, many systems have to make a choice between these three at the beginning of their design. In the vast majority of scenarios in the Internet field, strong consistency needs to be sacrificed for high availability of the system, and systems often only need to ensure "ultimate consistency", as long as the final time is within the range acceptable to the user.

In many scenarios, in order to ensure the ultimate consistency of data, we need a lot of technical solutions to support, such as distributed transactions, distributed locks and so on. Sometimes we need to ensure that a method can only be executed by the same thread at the same time. In a stand-alone environment, Java actually provides a lot of API related to concurrent processing, but these API are powerless in distributed scenarios. In other words, Java Api alone does not provide the ability to distribute locks. Therefore, there are many schemes for the implementation of distributed locks:

Implementation of distributed Lock based on Database

Implementation of distributed Lock based on redis,memcached

Implementation of distributed Lock based on Zookeeper

Before analyzing these implementations, let's think about what kind of distributed locks we need. (here, take method lock as an example, resource lock is the same)

It can be guaranteed that in a distributed application cluster, the same method can only be executed by one thread on one machine at a time.

This lock is a reentrant lock (avoid deadlock)

This lock is preferably a blocking lock (consider this one according to business requirements)

Highly available lock acquisition and release functions

The performance of acquiring and releasing locks is better

The following is mainly for the pessimistic lock to introduce.

Second, to implement boolean lock () {

Update

Null) {

True

Catch (Exception e) {

Sleep (1000)

Return cache lock

Compared with the scheme of distributed lock based on database, the implementation based on cache will perform better in terms of performance. And many caches can be deployed in clusters to solve a single point of problem.

After redis2.6, the SET command supports timeout and key presence checking, which is an atomic operation

Get the lock and set the timeout:

SET key value [EX seconds] [PX milliseconds] [NX | XX]

Remove the lock:

DEL key

EX: unit is second

PX: unit is millisecond

NX: if key exists, nil is returned, but ok is not returned.

XX: if key exists, ok is returned, but nil is not returned (failed)

The advantage of cache locks is excellent performance, and the disadvantage is that the data is in memory, and once the cache service goes down, the lock data is lost. For example, redis has its own replication function, which can guarantee the reliability of data to a certain extent, but because replication is also completed asynchronously, it is still possible for master nodes to write locked data and lose locked data when they are not synchronized to slave nodes.

4. Distributed Lock-zookeeper

Distributed locking based on zookeeper temporary ordered nodes. The general idea is that when each client locks a method, a unique instantaneous ordered node is generated under the directory of the specified node corresponding to the method on the zookeeper. The way to determine whether or not to acquire a lock is simple, just to judge the one with the lowest sequence number in the ordered node. When the lock is released, you only need to delete the instantaneous node. At the same time, it can avoid the deadlock problem caused by the unreleased lock caused by service downtime.

Let's see if Zookeeper can solve the problem mentioned earlier.

The lock cannot be released: using Zookeeper can effectively solve the problem that the lock cannot be released, because when the lock is created, the client will create a temporary node in ZK, and once the client acquires the lock and suddenly hangs up (the Session connection is broken), then the temporary node will be deleted automatically. Other clients can acquire the lock again.

Non-blocking lock: the blocking lock can be realized by using Zookeeper. The client can create a sequential node in ZK and bind listeners on the node. Once the node changes, Zookeeper will notify the client that the client

The client can check whether the node it has created has the lowest sequence number of all the nodes. If so, it can acquire the lock and execute the business logic.

Non-reentrant: using Zookeeper can also effectively solve the problem of non-reentrant. When creating a node, the client writes the host information and thread information of the current client directly to the node, and next time you want to get the locked

Compare the time with the data in the current smallest node. If the information is the same as your own, then you get the lock directly, and if it is different, create a temporary sequential node to participate in the queue.

Single point problem: using Zookeeper can effectively solve the single point problem. ZK is deployed in a cluster. As long as more than half of the machines in the cluster survive, services can be provided.

Thank you for reading! This is the end of this article on "what is the use of distributed locks in the practical application of web projects?". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.