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

This article will explain in detail the reasons why redis single thread needs to be locked. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

Personally, although redis is single-threaded, it can be accessed by multiple clients at the same time, each client having a thread. There is competition between client access.

Because there is multi-client concurrency, the atomicity of the operation must be guaranteed. For example, the problem of bank card deduction, obtaining the balance, judging, deducting money, and writing back must constitute a business, otherwise it may go wrong.

In the case of stand-alone deployment of traditional monolithic applications, Java concurrency-related locks, such as ReentrantLcok or synchronized, can be used for mutex control. However, with the needs of business development, the original single machine deployment system is gradually deployed on multi-machine and multi-JVM to provide services at the same time, which makes the concurrency control lock strategy invalid under the original single machine deployment. In order to solve this problem, we need a cross-JVM mutual exclusion mechanism to control the access of shared resources, which is the problem to be solved by distributed lock.

Implementation conditions of distributed Lock

1. Mutual exclusion. As with single applications, only one client can hold the lock at any time.

2. Reliability, to ensure the stability of the system, can not produce deadlock

3. Consistency, it is necessary to ensure that the lock can only be unlocked by the locking person, and that the locking of A cannot be unlocked by the B user.

Different people who implement distributed locks in Redis may have different implementation logic.

In the distributed environment, the problem of data consistency has always been an important topic, which is different from the case of single process. The biggest difference between distributed and stand-alone is that it is not multithreaded but multi-process. Because multithreading can share heap memory, it can simply take memory as the mark storage location. Processes may not even be on the same physical machine, so you need to store tags in a place where all processes can see them.

A common scenario is the second kill scenario, in which multiple instances are deployed for the order service. For example, there are 4 products, the first user buys 3, and the second user buys 2. Ideally, the first user can purchase successfully, the second user prompts that the purchase fails, and vice versa. What may actually happen is that both users get an inventory of 4, and the first user buys three. Before updating the inventory, the second user places an order for 2 items and updates the inventory to 2, resulting in an error.

The reason why redis single thread needs to be locked is shared here. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.