My personal understanding is that although redis is single-threaded, it can be accessed by multiple clients at the same time, and each client will have one thread. There is competition between client accesses.
Because there are multiple clients concurrently, the atomicity of the operation must be guaranteed. For example, when it comes to bank card deductions, obtaining the balance, judging, debiting, and writing back must constitute a transaction, otherwise errors may occur.
#In the case of traditional single application stand-alone deployment, you can use Java concurrency-related locks, such as ReentrantLcok or synchronized, for mutual exclusion control. However, with the needs of business development, the original single-machine deployment system was gradually deployed on multiple machines and multiple JVMs to provide services simultaneously, which made the concurrency control lock strategy in the original single-machine deployment invalid. In order to solve this problem, A cross-JVM mutual exclusion mechanism is needed to control access to shared resources. This is the problem that distributed locks want to solve. (Recommended learning: Redis video tutorial)
Implementation conditions of distributed lock
1. Mutual exclusivity, the same as single application, It is necessary to ensure that only one client can hold the lock at any time
2. Reliability, the stability of the system must be ensured, and deadlock cannot occur
3. Consistency, the lock must be ensured It can only be unlocked by the person who locked it, and it cannot happen that the lock of A is unlocked by user B
Redis implements distributed locks. Different people may have different implementation logic.
In a distributed environment, the issue of data consistency has always been an important topic, but it is different from the situation of a single process. The biggest difference between distributed and stand-alone situations is that it is not multi-threaded but multi-process. Since multi-threads can share heap memory, they can simply use memory as the mark storage location. The processes may not even be on the same physical machine, so the tag needs to be stored in a place where all processes can see it.
A common flash sale scenario is that multiple instances of the order service are deployed. For example, if there are 4 flash sale products, the first user purchases 3, and the second user purchases 2. Ideally, the first user can purchase successfully, and the second user will be prompted that the purchase failed, and vice versa. What may actually happen is that both users get an inventory of 4, and the first user buys 3. Before updating the inventory, the second user places an order for 2 items and updates the inventory to 2, causing an error.
Common lock schemes are as follows:
Implement distributed locks based on database
Based on cache, implement distributed locks, such as redis
Implementing distributed locks based on Zookeeper
For more Redis-related technical articles, please visit the Redis database usage tutorial column to learn!
The above is the detailed content of Why does redis single thread need to be locked?. For more information, please follow other related articles on the PHP Chinese website!