What are the two pitfalls that Redis distributed locks must avoid?
1 The first pit: Wrong lock release timing
1.1. Found the problem
Analyze the problems in the following code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
The above code seems to be fine, In fact, it hides a big problem. The problem is that when releasing the lock, there is no verification whether the current thread has obtained the lock:
Thread 1 and Thread 2 access the business method at the same time
Thread 2 Obtain the lock successfully and perform business processing
Thread 1 did not acquire the lock, but released the lock successfully
At this time, thread 3 tried to acquire The lock is successful, but the business of Thread 2 has not been processed, so Thread 3 will not cause a business duplication exception
Ultimately, Thread 2 and Thread 3 will repeatedly execute the business
1.2 Solve the problem
The solution is to allow the lock to be released only after confirming that the lock acquisition is successful:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
2 The second pit: cache invalidation problem
No. The second problem is that Redis also has a memory cleaning mechanism, which may cause distributed locks to fail.
2.1 Expiration cleanup mechanism
(1) Regular deletion
Redis regularly checks which keys have expired, and deletes them if they are found to be expired
(2) Lazy deletion
If there are too many keys, regular deletion will consume a lot of resources, so a lazy deletion strategy is introduced
If Redis finds that the key has expired when accessing it, Direct deletion
2.2 Memory recycling mechanism
When memory is insufficient, Redis will select some elements for deletion:
no-enviction
Prohibit eviction of data, new The write operation will report an error
volatile-lru
Select the least recently used data from the data set with an expiration time to be eliminated
volatile-ttl
Select the data to be expired from the data set with expiration time set to be eliminated
volatile-random
Select any data to be eliminated from the data set with expiration time set
allkeys- lru
Select the least recently used data from the data set to eliminate
allkeys-random
Select any data from the data set to eliminate
There are at least two Scenario causes distributed lock failure problem:
Scenario 1: Redis has insufficient memory for memory recycling, use
allkeys-lru
orallkeys-random
The recycling strategy causes lock failureScenario 2: The thread successfully acquires the distributed lock, but the processing time is too long. At this time, the lock expires and is regularly cleared, causing other threads to successfully acquire the lock and fail. Repeated execution of business
2.3 Optimistic lock
The general solution is to protect it at the database layer. For example, the inventory deduction business uses optimistic locking at the database layer.
1 2 |
|
The above is the detailed content of What are the two pitfalls that Redis distributed locks must avoid?. For more information, please follow other related articles on the PHP Chinese website!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

Redis cluster mode deploys Redis instances to multiple servers through sharding, improving scalability and availability. The construction steps are as follows: Create odd Redis instances with different ports; Create 3 sentinel instances, monitor Redis instances and failover; configure sentinel configuration files, add monitoring Redis instance information and failover settings; configure Redis instance configuration files, enable cluster mode and specify the cluster information file path; create nodes.conf file, containing information of each Redis instance; start the cluster, execute the create command to create a cluster and specify the number of replicas; log in to the cluster to execute the CLUSTER INFO command to verify the cluster status; make

How to clear Redis data: Use the FLUSHALL command to clear all key values. Use the FLUSHDB command to clear the key value of the currently selected database. Use SELECT to switch databases, and then use FLUSHDB to clear multiple databases. Use the DEL command to delete a specific key. Use the redis-cli tool to clear the data.

To read a queue from Redis, you need to get the queue name, read the elements using the LPOP command, and process the empty queue. The specific steps are as follows: Get the queue name: name it with the prefix of "queue:" such as "queue:my-queue". Use the LPOP command: Eject the element from the head of the queue and return its value, such as LPOP queue:my-queue. Processing empty queues: If the queue is empty, LPOP returns nil, and you can check whether the queue exists before reading the element.

Using the Redis directive requires the following steps: Open the Redis client. Enter the command (verb key value). Provides the required parameters (varies from instruction to instruction). Press Enter to execute the command. Redis returns a response indicating the result of the operation (usually OK or -ERR).

Using Redis to lock operations requires obtaining the lock through the SETNX command, and then using the EXPIRE command to set the expiration time. The specific steps are: (1) Use the SETNX command to try to set a key-value pair; (2) Use the EXPIRE command to set the expiration time for the lock; (3) Use the DEL command to delete the lock when the lock is no longer needed.

On CentOS systems, you can limit the execution time of Lua scripts by modifying Redis configuration files or using Redis commands to prevent malicious scripts from consuming too much resources. Method 1: Modify the Redis configuration file and locate the Redis configuration file: The Redis configuration file is usually located in /etc/redis/redis.conf. Edit configuration file: Open the configuration file using a text editor (such as vi or nano): sudovi/etc/redis/redis.conf Set the Lua script execution time limit: Add or modify the following lines in the configuration file to set the maximum execution time of the Lua script (unit: milliseconds)

Use the Redis command line tool (redis-cli) to manage and operate Redis through the following steps: Connect to the server, specify the address and port. Send commands to the server using the command name and parameters. Use the HELP command to view help information for a specific command. Use the QUIT command to exit the command line tool.

In Debian systems, readdir system calls are used to read directory contents. If its performance is not good, try the following optimization strategy: Simplify the number of directory files: Split large directories into multiple small directories as much as possible, reducing the number of items processed per readdir call. Enable directory content caching: build a cache mechanism, update the cache regularly or when directory content changes, and reduce frequent calls to readdir. Memory caches (such as Memcached or Redis) or local caches (such as files or databases) can be considered. Adopt efficient data structure: If you implement directory traversal by yourself, select more efficient data structures (such as hash tables instead of linear search) to store and access directory information
