preface

Redlock is a concept that must be understood in distributed locking.

So this article will first introduce what Redlock is, when you have a basic understanding of Redlock. Then look at how RedLock is implemented in Reddisson.

Redisson Redlock recommends not to use it!! Redisson Redlock recommends not to use it!! Redisson Redlock recommends not to use it!!

Important things to repeat three times!

What is Redlock?

Redlock, which can be searched from the Internet to a lot of information, this article also briefly introduced, as literacy.

Single-instance locking

SET resource_name my_random_value NX PX 30000

You only need to use this command for single-instance Redis.

  • NX: Executes successfully only if no key exists;
  • PX: Failure time, pass in 30000, it will automatically release the lock after 30s;
  • My_random_value: It’s just a random value, it could be a thread number or something like that. In order to release the lock more safely, the script tells Redis that only the key exists and the stored value is the same as the value I specified.

Lock release can be implemented with the following Lua script:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

Why do you set random values?

This is mainly to prevent the lock from being deleted by other clients. Here’s a situation:

  1. Client A has acquired the lock and has not finished executing, but the lock timeout is released automatically.
  2. Client B can obtain the lock if it comes over at this time, and the lock is successful.
  3. At this point, client A finishes executing and needs to release the lock. If it does not compare the random value, client B will be released.

“My_random_value” contains a string similar to 931573de-903e-42fd-baa7-428ebb7eda80:1 composed of UUID:ThreadId.

When the lock encounters failover

Surely a single instance is not very reliable? After the lock was successful, the Redis service went down, which is not cool

At this point, it will come up to deploy Redis master and slave. Even if it is master and slave, there is a coincidence!

There is an obvious race state in the master-slave structure:

  1. Client A gets the lock from master
  2. Before the master can synchronize the lock to the slave, the master fails.
  3. The slave node is promoted to the master node
  4. Client B acquires another lock on the same resource already acquired by Client A. Security failure!

Sometimes the program is so clever, for example, when a node fails, multiple clients pick the lock at the same time. If you can live with such a small probability of error, then there is no problem with this replication-based scheme.

What if I use clusters?

If you remember from the previous section, you know that when you lock a cluster, you use CRC16’s hash function to modulo the key and route the result to the corresponding node that has been allocated slots.

Found that it was actually sent to a single node!

RedLock concept

At this time, the author of Redis proposed the concept of Redlock

If most (N/2+1) locks successfully, the lock is considered to have been acquired successfully.

The problem of RedLock

Looks like Redlock solved the problem:

  1. Client A locks most (more than half) of the cluster;
  2. Client B also locks most of them;
  3. There must be a conflict, so client B failed to lock.

Does that actually solve the problem?

I recommend reading two articles:

  • Martin Kleppmann: How to do distributed locking
  • Salvatore（Redis 作者）：Is Redlock safe?

In the end, the two sides disagreed and came to no conclusion.

Since this article is mainly about the analysis of Redlock in Redisson, I will not do any additional details. If you are interested in Redlock, you can read it yourself.

Redlock source code in Redisson

Here we will briefly examine the RedLock source code in Reddisson, and then explain why we don’t recommend using RedLock in Reddisson at the beginning of this article.

use

At first glance, it looks very similar to the use of interlocking MultiLock.

Actually, it’s a lot like RedsOnRedLock, which is a completely subclass of RedsOnMultiLock.

It simply overrides the failedLocksLimit method.

In MultiLock, all locks must be successfully locked.

In Redlock, you need more than half of the locks to succeed.

The rest of the source code is the same as Multilock, which will not be repeated.

The problem with Redlock in Reddisson

1. The problem of locking key

Lock1, Lock2, Lock3. How does RedsonRedlock guarantee that these three keys are on different masters that belong to the Redis cluster?

According to the theory of Redlock, it is necessary to lock more than half of the master nodes successfully.

RedissonRedLock is a subclass of RedissonMultiLock, but it overwrites the failedLocksLimit method to ensure that more than half of the locks are successful.

So these three keys, you need the user to make sure that they’re scattered on different nodes.

https://github.com/redisson/r…

In Redisson’s issues, the same fellow raised this issue, and the developer replied that the user should ensure that the keys are scattered among different masters.

https://github.com/redisson/r…

More friends proposed to use 5 clients.

So I’m going to use 5 single node clients, and then I’m going to use red lock, which sounds like it’s going to work, and I’m going to use RedLock in this way.

But what does that have to do with Redis Cluster?

Therefore, my problem is still not solved, and the user still needs to “manually locate the lock”.

Manual locator lock, this… I thought about it and decided not to use Redlock.

Of course, Darrenjiang1990 should be with the mood of breaking the clay pot to ask the end, so he published another issue.

https://github.com/redisson/r…

Do not close my issues. In #2436, it is possible to “manually locate lock”, but how can I manually locate lock?

Later, this issue was replied in October.

2. RedissonRedlock is deprecated

Yes, that’s right, now RedSon RedLock is enabled.

If you read the English document, you will find:

And the Chinese document, should be not updated in time.

Take a look at the update record:

Look for it again.

https://github.com/redisson/r…

The developers of Reddisson argue that Redis’ red lock is also controversial, but to ensure availability, every Redis command executed by the RLock object is synchronized through the WAIT command introduced in Redis 3.0.

The WAIT command blocks the current client until all previous writes have been successfully transmitted and confirmed by a specified number of copies. If the timeout specified in milliseconds is reached, the command returns even if the specified number of copies has not been reached.


Wait command synchronous replication also does not guarantee strong consistency, but after the primary node goes down, it just chooses the best Slaves as possible.

The source code is in this section.

WAIT 1 1000 to Redis

conclusion

Redisson Redlock is based on interlocking MultiLock, but in the process of use, you need to judge which node the key falls on, which is not very friendly to users.

Redisson Redlock has been deprecated, using a normal lock. Locks are synchronized to slave nodes based on a wait mechanism, but there is no guarantee of consistency. It’s just about maximizing consistency.

Related to recommend

  • Redisson distributed lock source 08: Multilock lock and lock release
  • Redisson distributed lock source 07: fair lock release
  • Redisson distributed lock source code 06: fair lock queue lock