Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to understand Redis locks, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

When it comes to Redis locks, the following three words are the most frequently used words:

Setnx

RedLock

Redisson

Setnx

At present, the commonly mentioned Setnx command does not only refer to the setnx key value command of Redis.

Generally speaking, it refers to the use of Set command plus NX parameter in Redis. Set command already supports so many optional parameters:

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

Of course, do not write API in the article, the basic parameters are not clear, you can jump to the official website.

The above picture is the general principle of Setnx drawn by the author, which is mainly based on the fact that its Key does not exist to make Set successful. Process A gets the lock, and process B naturally fails to acquire the lock when there is no Key to delete the lock.

So why use PX 30000 to set a timeout? Is afraid that process An is unreasonable, the lock is not waiting for release, in case of collapse, directly take the lock away in place, resulting in no one in the system can get the lock.

Even so, it is not guaranteed to be foolproof. If process An is unreasonable and the operation of the resources in the lock exceeds the timeout set by the author, it will cause other processes to get the lock, and when process A returns, the lock of other processes will be deleted, as shown in the figure:

In the same picture, the T5 moment is changed to a lock timeout and is released by Redis.

Process B happily got the lock in T6 for less than a while, and process A completed its operation, returned a Del, and released the lock.

When process B completes and releases the lock (T8 moment in the figure):

Can not find the lock is actually good, in case T7 has a process C to lock successfully, then process B will release the lock of process C.

And so on, process C may release the lock of process D, process D. (no nesting dolls), the exact consequences are unknown.

So when using Setnx, although Key is the main role, but Value can not be idle, you can set a unique client ID, or use a random number like UUID.

When unlocking, first acquire the Value to determine whether the lock is added by the current process, and then delete it. Pseudo code:

String uuid = xxxx; / / pseudo code, the specific implementation depends on the connection tools used in the project / / some of the methods provided are called set and some are called setIfAbsent set Test uuid NX PX 3000 try {/ / biz handle.... } finally {/ / unlock if (uuid.equals (redisTool.get ('Test')) {redisTool.del (' Test');}}

Does it look steady this time? On the contrary, the problem this time is even more obvious. In the Finally code block, Get and Del are not atomic operations, but there are still process security issues.

Why do you talk so much when there are questions? There are two reasons:

Only by finding out where the disadvantages lie, can we improve them better.

The last piece of code above is still used by many companies.

Paradox of large and small projects:

Large companies achieve norms, but small companies and small projects are not rigorous, but the concurrency is not high, and the probability of problems is as low as that of large companies.

So one of the correct poses to delete a lock is to use the Lua script to run it through the Redis eval/evalsha command:

-- lua delete lock:-- KEYS and ARGV are the parameters passed in a collection, corresponding to Test and uuid above. -- if the corresponding value is equal to the incoming uuid. If redis.call ('get', KEYS [1]) = = ARGV [1] then-perform delete operation return redis.call (' del', KEYS [1]) else-unsuccessful, return 0 return 0 end

The reason for atomicity can be guaranteed through Lua scripts, to put it more popularly: even if you write flowers in Lua, execution is executed by a command (eval/evalsha), and a command is not seen by other clients until it is finished.

So since it's so troublesome, do you have any better tools? We're about to talk about Redisson.

Before introducing Redisson, the author briefly explains why the current Setnx default refers to the Set command with the NX parameter, rather than the Setnx command directly.

Because Set does not support the NX parameter before Redis version 2.6.12, if you want to complete a lock, you need two commands:

1. Setnx Test uuid 2. Expire Test 30

That is, putting in the Key and setting the expiration date are two separate steps. In theory, there will be one that has just been executed and the program is dead, so there is no guarantee of atomicity.

But as early as 2013, seven years ago, Redis released version 2.6.12, and the official website (Set command page) stated early that "SETNX,SETEX,PSETEX may be deprecated and permanently deleted in future versions."

The author has read a boss's article, in which there is a guide to the beginner's interview tricks, the specific text forgot, the general meaning is as follows: when it comes to Redis locks, you can start from Setnx, and finally slowly lead to the Set command can add parameters, can reflect their knowledge.

If you are predestined to read this article and learn this routine, as the author of this article, I would like to add a reminder: please pay attention to your working years! First, answer the order that the official website says is about to be abandoned, and then lead to the "new feature" of the Set command seven years ago. if a recent graduate says so, the interviewer will think he has gone through it.

If you set up the road interviewer, the interviewer will set you up.

-- vt Wozky Saud

Redisson

Redisson is one of the Redis clients of Java, which provides some API to facilitate the operation of Redis.

However, the Redisson client is a bit powerful. The author has captured only part of the picture on the official website:

This list of features can be said to be too many, do you also see some class names under the JUC package, Redisson helped us build a distributed version.

For example, AtomicLong, just use RedissonAtomicLong directly, and you don't even have to remember the class name. It's very humanized.

The lock is just the tip of the iceberg, and as you can see from its Wiki page, it supports master-slave, Sentinel, cluster and other modes, of course, single-node mode is certainly supported.

This article still focuses on locks, and others are not introduced too much. Redisson ordinary lock source code is mainly RedissonLock this class, have not seen its source code friends, might as well take a look.

Lock / release lock operations in the source code are completed with Lua scripts, the package is very perfect, out of the box.

Here is a small detail, locking can be achieved using Setnx, is it superfluous to use Lua scripts?

The author also thought about it very seriously: how can such a powerful thing write waste code?

In fact, the author looked at it carefully and found that the Lua script for locking and unlocking is very comprehensive, including the reentrant nature of the lock, which can be said to be very thoughtful. I also wrote the code to test it:

Indeed, it is as slippery as JDK's ReentrantLock, so the implementation of Redisson is so perfect, what is RedLock?

RedLock

RedLock is literally translated into Chinese, which is called Red Lock. Red lock is not a tool, but a distributed lock algorithm proposed by Redis officials.

Just after the introduction of Redisson, the RedLock version of the lock is implemented. That is to say, in addition to the getLock method, there are also getRedLock methods.

The author probably drew an understanding of the red lock:

If you're not familiar with Redis high-availability deployments, it doesn't matter. Although the RedLock algorithm requires multiple instances, these instances are deployed independently and there is no master-slave relationship.

The author of RedLock points out that the reason for using stand-alone is to avoid lock loss caused by Redis asynchronous replication, such as the failure of the master node and the failure to give the data just Set to the slave node.

Do some people think that bosses are leveraged and think about extreme situations every day? In fact, high available, the spelling is 99.999% of the digits after the decimal point.

Going back to the crude picture above, the red lock algorithm believes that as long as the 2N+1 nodes are successfully locked, then it is assumed that the lock has been acquired, and all instances will be unlocked when unlocked.

The process is as follows:

Request locking from five nodes sequentially

Infer whether to skip the node according to a certain timeout

Three nodes were locked successfully and the time spent is less than the validity period of the lock

The lock is determined to be successful.

In other words, assuming that the lock expires in 30 seconds, and it takes 31 seconds for the three nodes to add the lock, it naturally fails.

This is just an example. In fact, you should not wait as long as each node. As the official website said, assuming that the validity period is 10 seconds, then the operation timeout of a single Redis instance should be between 5 and 50 milliseconds (note the time unit).

Or suppose we set the validity period to 30 seconds, with two Redis nodes timed out in the figure. So it takes a total of 3 seconds for the successful node to lock, so the actual validity of the lock is less than 27 seconds.

That is, 3 seconds after successfully locking three instances and the total time spent waiting for timeout Redis instances. Seeing this, you may have some questions about this algorithm, so you are not alone.

Looking back at the description of the red lock on Redis's official website, at the bottom of this description page, you can see the famous immortal fight about the red lock.

The RedLock debate between Martin Kleppmann and Antirez. One is a highly qualified distributed architect, and the other is the father of Redis.

Official hanging up is the deadliest. Just kidding, if the doubt can be posted on the official website, it must be valuable.

So if you want to use a red lock in a project, you might as well read two more articles in addition to the introduction of the red lock, namely:

Query post of Martin Kleppmann

Counterattack paste of Antirez

After reading the above, do you have any further understanding of how to understand Redis locks? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.