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

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

Preface

In the past, when I did small projects at school, I used Redis, which was basically used as a cache. But A Fan in the work found that Redis in production is not just as simple as cache. In the project that Ah Fan came into contact with, Redis played the role of a distributed lock, as follows:

The project, which is responsible for a certain business in a financial platform, is a distributed system, with about 10 instances running online. One of the steps requires the user to pay a fee, in which the Redis distributed lock is in a position like this:

You can see that after the distributed lock, the system makes two query checks, then inserts an order record into the database, and then unlocks it into the payment process.

From a business point of view, it is easy to understand the distributed lock, which ensures the atomicity of the whole process of querying and inserting data, prevents dirty data from being found during query verification, and makes the operation of pre-payment order information table serialized.

Although it is easy to understand from a business point of view, using Redis as a distributed lock is a new knowledge for me, and Ah Fan intends to dig deeper into this knowledge with the code in the project.

Text 1. Why use distributed locks

After seeing distributed locks in actual projects, it is not difficult to understand why distributed locks are used: to sum up, distributed systems need to access shared resources. In order to avoid errors caused by concurrent access to resources, we add a lock to shared resources to make each access mutually exclusive and ensure the security of concurrent access. This is the reason for using distributed locks.

2. Implementation of distributed lock in Redis

Using distributed locks in redis is simple, as long as you use the setnx instruction to lock a key:

Setnx lock test / / locked

Del lock test / / unlock

When a key is not occupied, the setnx instruction returns 1, otherwise 0, which is how distributed locks are used in Redis.

Of course, we can also use the expire instruction to set the expiration time of the lock after it is locked.

See here you may have questions, if our program flow does not use instructions to unlock, rely on redis setting time expiration to unlock, it seems that there will be a problem. If our service process dies after executing the setnx and before executing the expire instruction, will the lock never be released?

Yes, this is a problem, and at that time a bunch of solutions were proposed in the open source community of Redis to solve the problem, all of which were extremely complex to implement. Later, the authors of Redis added an extension parameter to the set instruction in Redis version 2.8, so that the setnx instruction and the expire instruction can be executed at the same time, as shown below:

Set lock test ex 5 nx

Ex: sets the expiration time of the key

Nx: set the key only when the key does not exist

Since then, Redis has become the darling of distributed locks.

3. The trouble of distributed Lock in Redis Cluster

After learning about the use of distributed locks in Redis, we soon discovered new problems. In enterprises, Redis is basically deployed in clusters, and cluster deployment cannot avoid the problem of node downtime.

Let's consider such a situation: suppose we add a distributed lock to the master node of redis. Unfortunately, the master node is dead, and the lock on the master node has not been synchronized to the slave node. If a client requests to obtain the same lock at this time, it will successfully acquire the lock, and the previous lock will be mercilessly ignored. This is the trouble encountered by distributed locks in the Redis cluster.

In order to solve this problem, the author of Redis proposed an algorithm called Redlock. Its principle is as follows: when locked, the set instruction is sent to more than half of the nodes, as long as more than half of the lock set is successful, the lock is considered successful; when unlocked, the del instruction will be sent to all nodes.

From the principle of this algorithm, we can see that because Redlock needs to read and write to multiple nodes at the same time, the performance of using Redlock plus distributed lock is much lower than that of stand-alone Redis. Because the probability of fault in master-slave replication is very low, if there is a certain fault tolerance rate for distributed locking process, you can consider using set instruction directly; if you pursue high availability, you can consider using Redlock algorithm.

Of course, high availability distributed locks are not limited to Redis's Redlock. We can also use zookeeper or a database that supports transactions to do distributed locks.

❝

This paper briefly describes the distributed lock principle of zookeeper: suppose zk uses a node as a distributed lock, and when different clients compete for the lock to zk, zk will create a child node for different clients in order, hanging under the node as a distributed lock. Suppose the first client is A, and the second is B. An is the first node hanging under the distributed node, and B will monitor the life state of A. when A releases the lock, A will be deleted. At this time, B listens that An is deleted, and B receives the distributed lock.

❞

In the company's project, although Redis is deployed as a cluster, it still uses the most basic set instructions to obtain distributed locks, because the performance of this method is much higher than that of Redlock algorithm and zk, database and other distributed lock implementations.

Although high performance is selected among high-performance and low-probability errors, other work has been done in the project to cover up the error situation, such as throwing an exception to the error condition of master-slave replication in the company's project. then some retry operations will be carried out based on the exception.

After reading the above, do you have any further understanding of the principle of Redis distributed 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.