Tags: TPS binding deadlock Organization code access share no Ali Special
Earlier, we learned about Redis's data structure and the commands, transactions in Redis, and Redis support for LUA scripting.
This chapter is a practical application of Redis's features--a distributed lock implementation based on Redis.Lock and distributed lock
Before this, come to know the lock and the distributed lock (distributed lock):
In computer science, a-lock or mutex (from mutual exclusion) are a synchronization mechanism for enforcing limits on access To a resource in an environment where there is many threads of execution. A lock is designed to enforce a mutual exclusion concurrency control policy.
Reference Wiki Interpretation: in the field of computer science, locks are a synchronization mechanism to restrict access to a resource in a multithreaded environment. Locks are designed to be mutually exclusive concurrency policies.
The condition of Lock:
The implementation of Lock:
Operating systems use lock managers to organise and serialise the access to resources. A distributed lock Manager (DLM) runs in every machine in a cluster, with an identical copy of a cluster-wide lock Databas E. In the this-to-the-provides software applications which is distributed across a cluster on multiple machines with a mea NS to synchronize their accesses to shared resources.
The reference wiki explains distributed locks: the operating system uses lock managers to implement organized, sequential access resources. Distributed locks run on every machine in a clustered environment, making the data have the same copy. Distributed locks provide a shared resource that is accessed synchronously by the distribution software application.
Prerequisites for Distribute Lock:
Distribute lock target:
Distribute Lock Implementation method:
There are many types of locks, depending on the purpose and scene. such as: Exclusive lock, shared lock, spin lock, mutual exclusion lock, read lock, write lock. But in the distributed environment, the so-called distributed lock, in most cases refers to: Distributed exclusive lock.
1. Characteristics Analysis:
Nature: Synchronous mutual exclusion, so that the processing task can be a gradual over-critical resources.
The impact of:
Essence: The throughput is greatly compromised.Redis-based implementation of a distributed lock based on Redis
The 1.Redis itself is a single thread:
The 2.Redis provides the set if not exists operation:
Let's take a look at getting the lock:
return jedis.set(lockKey, lockValue, NX, EX, expireTime) != null ? true : false;
Here, the use of set instructions, with atomic operation characteristics, will not be interrupted by other client operations, in a distributed environment, is safe, no race conditions are generated, only one client contention lock at a time, using NX, there is no setting, in accordance with exclusive features; Finally, the Lockvalue is set up so that it is bound to the current lock task, which can be used as the key to unlock;
Then take a look at the unlock operation:
static final String RELEASE_LOCK_LUA = "if redis.call(‘get‘, KEYS) == ARGV " + "then return redis.call(‘del‘, KEYS) else return 0 end"; Object result = jedis.eval(RELEASE_LOCK_LUA, 1, lockKey, lockValue);
Here is the Lua script, the previous article describes the Redis built into a LUA interpreter, the Redis invoke interpreter execution Lua script is also atomic, that is, only one client operation can be executed at the same time, so the use of Lua script to unlock the non-race condition ; unlocking conforms to the principle that the task that occupies the lock is released;
However, the disadvantages of the distributed locks implemented above are:
I have modified it, respectively, to adapt to the above two scenarios of distributed lock, details can be timestamp [distributed lock], welcome you to improve together.Summarize
This paper analyzes the distributed lock from the angle of what, Features and how. In general, the larger version of multi-threaded or multi-process locks in single-machine applications is basically a distributed lock. Original aim, the key element for implementing an exclusive lock:
The correct implementation of Redis distributed locks
Rewriting our lock
Refer to rewriting our lock in the use of SETNX implementation of the distribution, in strict sense there is a deadlock problem. Setnx and expire do not have atomic nature. When the setnx succeeds, the expire application takes place before the outage, which causes the lock to never expire, and the other app always struggles with the lock. Of course, this kind of situation is very special, but the code is a rigorous thing!
Redis (vii) Distributed locks