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

This article introduces the knowledge of "how to implement distributed locks based on Redis cache". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is a distributed lock?

First of all, let's take a brief look at what a distributed lock is.

Before the introduction of distributed locks, everyone should know that the classical CAP theory mentioned that no system can satisfy Consistency, Availability and Partition tolerance at the same time, and only two can be satisfied at the same time. In this case, distributed locks appear, and distributed locks are used to solve the problem of data consistency.

In the previous single application environment, Java's API provides many interfaces to control concurrency, including synchronized and some implementations under JUC. But in a distributed environment, these API do not have the opportunity to exert their capabilities, because applications are deployed in multiple instances, and many instances are not even on the same host, so it is impossible to use API in Java at all. At this time, distributed locks are born.

Therefore, to put it simply, what is a distributed lock? distributed lock is a technical scheme used to solve the consistency of multi-instance data access in a distributed environment.

Working with scen

In the actual environment, we use distributed locks in many scenarios, such as global counters, as long as multiple instance processes are involved to modify the same data and other operations will require distributed locks. Distributed locks are also used in scenarios such as placing orders, updating caches, and reducing inventory.

Characteristics of distributed locks

Before we look at the implementation of distributed locks, let's take a look at what features the next distributed lock should have:

In a distributed environment, it can only be obtained by a single thread at the same time.

Reentrant, which means that the thread that has acquired the lock does not need to acquire the lock again during execution

Automatic deletion of exception or timeout to avoid deadlock

High performance, good performance in distributed environment

Mode of realization

There are three popular ways to implement distributed locks, which are based on cache Redis, temporary sequential nodes based on ZK and row locks based on database. Here is a simple implementation idea, do not repeat the wheel because there are already many good open source solutions on the Internet.

Implementation based on Redis caching

First of all, let's take a look at the distributed lock based on Redis cache. Redis supports the SETNX command, which means that the value of a key can be set successfully only if the schedule Key does not exist. For example, execute the following command: set ziyou 18 NX PX 10000 means that the value of key named ziyou is set to 18, if and only if there is no key named ziyou, and the expiration time is set to 10 seconds.

Setnx command is the core of Redis to achieve distributed lock, this command operation is atomic operation, must not be divided into two steps to first use set and then use expire, so separate operation is not atomic, can not achieve the effect.

Then Redis distributed lock has an open source implementation [Redission] (https://github.com/redisson/redisson)) on the Internet, the specific implementation can be referred to.

Baidu also has an open source distributed Redis lock called [dlock] (https://github.com/baidu/dlock), this is what we adopted, and there is no problem with using it for so long. Use it in a manner similar to the following:

Advantages and disadvantages

Advantages:

1. Easy to implement

two。 Understand the logic is simple.

3. Good performance, after all, is caching.

Disadvantages:

1. Redis is prone to single point of failure and cluster deployment

2. The expiration time of key is not clear and can only be adjusted according to the actual situation.

Implementation based on ZK

The core of Redis mentioned earlier is the SETNX command, so for ZK, the core of implementing distributed locks is temporary sequential nodes. First of all, we have the opportunity to introduce the knowledge of ZK to you later. At present, we only need to know that one of the node types of ZK is called temporary sequential node, and there are two keywords: temporary, sequential.

Temporary means that after the client creates a node, if the client loses its heartbeat with the server after a period of time, the node will be automatically deleted (which is similar to the expiration time of Redis key). Sequence means that the child nodes generated under a node are in order, each with a unique number, and the number is increased sequentially.

Temporary sequential nodes plus ZK listening mechanism can achieve distributed locks. Curator is an open source client of ZK, and it also provides the implementation of distributed locks. I have not actually used this, but there are many people who use it on the Internet, so you can study it yourself.

Advantages and disadvantages

Advantages:

1. ZK itself is a cluster deployment to avoid stand-alone failure

two。 Sequential nodes, so you don't have to worry about setting the expiration time.

Disadvantages:

1. The implementation is more complex.

two。 Non-caching mechanism, frequent creation and deletion of a large number of nodes will affect the performance of ZK clusters

Implementation based on database

Database-based distributed lock personal feel that the performance is not very good, in the case of high concurrency on the database server too much pressure, will affect the business, it is not recommended to use. However, from the perspective of learning, it is still necessary for us to understand the specific implementation. There are two ways to implement distributed lock based on database. Here we take MySQL as an example. The implementation of both scenarios requires an additional table and a unique index field.

1. Blocking statement select xxx for update

two。 Non-blocking test insert into xxx; delete from

Explain:

When the first scheme is implemented, you need to turn off the automatic commit of the transaction, and then execute SQL to obtain the lock. If the lock is successful, execute the following business logic. If the lock is not acquired here, it will block and wait. After the business execution is finished, commit the transaction manually. Here, if the program fails to commit the transaction, exception or service outage, the database will automatically release the lock to avoid deadlock. But there is a problem here, that is, in the case of high concurrency, many threads do not get the lock and are blocking and waiting, which will lead to excessive pressure on the server of the database and affect the service of the database. This is to pay attention to, this is also what I do not recommend, prone to bottlenecks, after all, not as efficient as caching.

The second solution is similar to the first, except that the data of a unique index is inserted into the specified table through the first step. If the insert is successful, the lock is obtained, and if the insertion fails, the lock is not acquired. After the lock is successfully acquired, the business logic can be executed, and the executed record can be deleted after the business logic is executed. If the insert fails, the action to acquire the lock needs to be triggered again. However, the problem with this scheme is that the expiration time of the lock cannot be set, other means are needed to clean up the timeout data, and in order to support reentrant, the information of the host and the service needs to be saved together.

Advantages and disadvantages

Advantages

1. Easy to understand and implement, but pay attention to the details

Disadvantages:

1. Poor performance in the case of high concurrency, and many links will be dragged down the database service if they are not released in the case of blocking.

two。 Time-out data needs to be cleaned regularly, please

3. The row lock of the database will fail because of the query optimization of MySQL

This is the end of "how to implement distributed locks based on Redis cache". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.