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

This article mainly introduces the example analysis of Redlock in Redis, which has a certain reference value, and interested friends can refer to it. I hope you will gain a lot after reading this article.

Why use a lock?

At a K12 education company I worked with, we had a business scene that looked like this. The business side has to schedule classes for students, and occasionally feedback that the class hours of the students are obviously sufficient, but they are prompted that the class hours are insufficient, and so on to refresh the page but find that the class hours of the students are not enough. What is even more frightening is that occasionally some students' class hours are deducted into negative numbers (the company is whoring class hours).

For example, the following example

Both of the above questions are brought about by the business that has been sent to us. The core of solving this problem is that only one request can be allowed to read and write to these sensitive (important) data at a time. So at this time, distributed locks are used to limit the concurrent execution of the program.

What are the problems with setnx?

Let's first take a look at how to implement distributed locks with Redis, which you must be familiar with. For example, with regard to the problem of students' course scheduling at the beginning of my article, we can lock it in this way.

This is how we routinely use setnx to implement locks.

Now let's assume that there is such a scene. A request to get the lock to step 2 when the program failed to schedule lessons for the students, the lock was not released. Then the lock becomes a deadlock, and the next request to operate the same student will never get the lock, so the student cannot be scheduled. At this time, you need to release the lock manually.

In order to solve the problem of deadlock, we add an expiration time to the lock.

After adding the expiration time, if the A request does not actively release the lock, it will also be released actively after the lock expires, so that the B request can also obtain the lock processing business logic. But if you add expiration time, that is, between steps 1 and 2, the program crashes. Then there will still be a deadlock problem. The root of this problem is that setnx and expire are not atomic instructions. So it would be nice if setnx and expire could execute either all or none at all.

To this end, a large number of expansion packs have emerged in the community before Redis2.8 to solve this problem. In order to control the mess, officials added an extension parameter to the set instruction in version 2.8 so that the setnx and expire instructions can be executed together, so it should be like this now that we use distributed locks.

This seems perfect, and our expectations have been met, "if only setnx and expire could either execute all or none at all." Let's assume that there are now the following scenarios:

A request has now acquired the lock, and the timeout for the lock is set to 5 seconds. When the business logic is executed in step 2, for some reason, the business logic is not finished after 5 seconds, and the lock is automatically released due to a timeout. At this time, the B request also comes, and after getting the lock, the business logic begins to be executed. A request at this time the business logic is finished, start to execute the third step, and release the lock. At this time, the lock was acquired by B request, and was released by A request. Then the C request can get the lock. At this point, B and C requests will cause concurrency problems. So it can be seen from this example that setting the expiration time in a distributed lock is very important, and concurrency problems will still occur if the set time is less than the response time of this interface. So we can refer to the monitoring of the response time of the interface to set the expiration time of the lock.

Redlock

Our above solutions are based on the implementation of a single point of Redis. The distributed lock implemented by a single point of Redis can basically meet 95% of the business scenarios. The remaining 5% are business scenarios with extremely stringent data consistency requirements and zero tolerance for lock loss. At this point, you have to think about Redlock. As for the single point of Redis, even if it is highly available through sentinel, if the master node has master-slave switching for some reason, and if the master-slave data synchronization is not timely, then there is bound to be data loss, then the lock will be lost.

Assuming that there are multiple Redis instances, these nodes are completely independent and do not need to use replication or any system to coordinate data, we assume that there are five Redis master nodes, and the steps for the client to obtain the lock will be as follows:

Get the current server time in milliseconds

Try to use the same key and random values to acquire the lock. The client should have a timeout for each machine when acquiring the lock. For example, the expiration time of the lock is 10s, then the timeout for acquiring a single node lock should be about 5 to 50 milliseconds. The purpose of this is to ensure that the client does not spend extra time connecting with the failed machine! If the data is not obtained within the timeout period, the node is abandoned, thus going to the next Redis node to get it.

After the acquisition is completed, the current time minus the time acquired in step 1 is obtained. If and only if the client acquires the lock from more than half of the Redis nodes (here are 3 nodes) and the acquisition time is less than the lock amount timeout time, the lock is proved to be effective!

If the lock is taken, the true effective time of the key is equal to the effective time minus the time it takes to acquire the lock (the result of the calculation in step 3).

If the machine that acquired the lock does not satisfy more than half, or if the timeout of the lock is negative and other abnormal operations, the system will try to unlock all instances, even if some Redis instances are not locked successfully at all, preventing some nodes from acquiring the lock but the client does not get a response, so that the lock cannot be re-acquired for the following period of time

So we can see that redlock is actually a more reliable lock than a single point of Redis.

If you are a Node.js programmer like me, then you happen to have a third-party library redlock to use directly.

Do we really need redlock?

In fact, there is another voice about redlock. Martin Kleppmann (a researcher at the University of Cambridge who works on the TRVE DATA project in the cross-cutting field of database, distributed systems and information security) wrote an article on blog and expressed some views on redlock. Redis author Salvatore also made some interesting responses to the questions raised in this article. The main points of the author's blog are as follows:

There are no more than two uses for distributed locks:

Efficiency: using locks can avoid doing the same job twice unnecessarily (for example, some expensive calculations). If the lock fails and the two nodes end up doing the same job, the result is a slight increase in cost (you end up paying AWS 5 cents more than otherwise) or a slight inconvenience (for example, users end up receiving the same email notification twice).

Correctness: using locks can prevent concurrent processes from interfering with each other and destroy the state of the system. If the lock fails and two nodes process the same piece of data at the same time, the result is file corruption, data loss, permanent inconsistency, incorrect drug dose given to the patient, or some other very serious problem.

If it is for efficiency, there is no need to bear the cost and complexity of Redlock, and the loss of locks results in several more emails than the cost of running five Redis servers, it is best to use only a single Redis instance. If you are using a single Redis instance, the Redis node suddenly loses power or crashes, or other problems, of course, the lock will be lost. But if you just use locks for efficiency optimization, and such crashes don't happen very often, it's no big deal. This "no big deal" scene also happens to be the best thing about Redis. At least if you rely on a single Redis instance, everyone who looks at the system can more easily locate the problem.

If it is for correctness, then strictly speaking, redlock does not have strong consistent rigor at all. Some examples are given.

Timing and system clocks make dangerous assumptions and are strongly dependent on the clock of each server. Because there is a system with the existence of GC, when doing GC, the whole server is rammed, and time comes to a standstill, so we can not be strongly dependent on the clock.

No token. Every time the client acquires the lock, the server does not issue a token, and the server should verify that the token of the client must be consistent with the current token of the server before it is difficult to operate the lock.

Thank you for reading this article carefully. I hope the article "sample Analysis of Redlock in Redis" shared by the editor will be helpful to you. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.