Implementation of redis distributed lock

I. Introduction

When we modify the existing data in the system, we need to read it first, and then modify and save it. At this time, it is easy to encounter concurrency problems.Since modification and saving are not atomic operations, some operations on data may be lost in concurrent scenarios.In a single-server system, we often use local locks to avoid problems caused by concurrency. However, when services are deployed in a cluster, local locks cannot take effect between multiple servers. At this time, distributed locks are required to ensure data consistency.accomplish.

Second, the mainstream implementation scheme of distributed locks

Distributed lock based on database

Cache based (Redis, etc.)

Based on Zookeeper

Each distributed lock solution has its own advantages and disadvantages:

Performance: redis is the highest

Reliability: zookeeper highest

3. Implementing distributed locks based on redis

Redis locks mainly use Redis's setnx command

• Locking command: SETNX key value, when the key does not exist, set the key and return success, otherwise return failure.KEY is the unique identifier of the lock, which is generally named according to the business.
• Unlock command: DEL key, releases the lock by deleting the key-value pair, so that other threads can acquire the lock through the SETNX command.
• Lock timeout: EXPIRE key second, set the timeout time of the key to ensure that even if the lock is not explicitly released, the lock can be automatically released after a certain period of time to avoid the resource being locked forever.

There are some problems with the above lock implementation:

    1-SETNX-and-EXPIRE-non-atomic

If SETNX is successful, after setting the lock timeout time, the server hangs up, restarts or has network problems, etc., resulting in the EXPIRE command not being executed, and the lock becoming deadlock if the lock timeout time is not set.

Solution:

1. Use Lua script to compose SETNX and EXPIRE into atomic operation

2. Use set key value ex second nx

    2, lock removal

If thread A successfully acquires the lock and sets an expiration time of 30 seconds, but the execution time of thread A exceeds 30 seconds, the lock is automatically released after expiration, and thread B acquires the lock at this time; then the execution of A is completed, and thread A usesDEL command to release the lock, but the lock added by thread B has not been executed yet, and the lock added by thread B is actually released by thread A.

Solution:

When set acquires the lock, set a specified unique value (for example: uuid), and acquire this before releasingvalue, determine whether it is your own lock, and if so, release the lock

    3. Timeout unlocking leads to concurrency (similar to the previous problem)

If thread A successfully acquires the lock and sets the expiration time to 30 seconds, but the execution time of thread A exceeds 30 seconds, the lock expires and is automatically released. At this time, thread B acquires the lock, and thread A and thread B execute concurrently.

Concurrency of two threads A and B is obviously not allowed. Generally, there are two ways to solve this problem:

• Set the expiration time long enough to ensure that the code logic can complete before the lock is released.
• Add a daemon thread for the thread that acquires the lock, and increase the valid time for the lock that will expire but not be released.

    4. The deletion operation lacks atomicity

If thread A successfully acquires the lock and sets the expiration time to 30 seconds, but the execution time of thread A is exactly 30 seconds, the lock is automatically released when it expires. At this time, A just completes the business logic and makes a judgment to release the lock.But before the lock is released, thread B acquires the lock again, and then thread A uses the DEL command to release the lock, but the lock added by thread B has not been executed yet, and the lock added by thread B actually released by thread A.

Solution:

Use Lua scripts to ensure atomicity of locking and releasing locks.

    5. How does Lua script ensure its atomicity

Redis embeds a lua environment (very small) to run lua scripts. When running lua scripts, other steps and commands will not be run. It is similar to adding locks to the code executing lua scripts, so its atomicity is guaranteed..

Four. Summary

To ensure that distributed locks are available, we at least make sureThe implementation of the lock also satisfies the following four conditions:

- Mutually exclusive.At any time, only one client can hold the lock.

- No deadlock occurs.Even if a client crashes while holding the lock and does not actively unlock it, it is guaranteed that other clients can lock in the future.

- The ringer must also be tied to the bell.Locking and unlocking must be done by the same client, and the client cannot unlock the locks added by others.

- Locking and unlocking must be atomic.