Redis (vii) Distributed locks

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:

• Common resources on the same machine;
• Multi-threaded environment access to common resources;

Lock target:

• Ensure the consistency of multi-threaded access resources;

The implementation of Lock:

• Disable interrupts on a single-core processor so that synchronization resources can be accessed at the end;
• The hardware supports atomic instructions, "Compare and swap" and so on, used to test whether the lock is idle, if Idle acquires the 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:

• distributed software applications;
• The shared resources in distributed software;

Distribute lock target:

• Ensure the consistency of distributed application access to shared resources

Distribute Lock Implementation method:

• Based on REDIS implementation;
• Based on zookeeper implementation;
• Based on ETCD or consul implementation;
• Chubby (Lock Service) developed by Google;

Characteristics and influence of exclusive lock

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:

• Only one occupancy lock at a time;
• Can be repeated into the lock;
• Only occupants can unlock;
• Both acquiring and releasing locks require an atom
• Cannot generate deadlocks
• Try to meet performance

Nature: Synchronous mutual exclusion, so that the processing task can be a gradual over-critical resources.

The impact of:

• Reduce the number of concurrent, so that multi-tasking, can only be one-to-one;
• The cost of switching is caused by the change in the task;

Essence: The throughput is greatly compromised.

Redis-based implementation of a distributed lock based on Redis

The 1.Redis itself is a single thread:

• Single command execution has atomic, non-race condition, this feature conforms to only one client contention lock at a time;

The 2.Redis provides the set if not exists operation:

• The existence is not set, this characteristic conforms to the monopoly of the lock (exclusive characteristic);

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[1]) == ARGV[1] " +
            "then return redis.call(‘del‘, KEYS[1]) 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:

• Does not have re-entry, that is, the current task acquires a lock, the next time the acquisition will be deadlocked;
• Cannot spin fetch, that is, the failure is returned immediately when the acquisition fails;

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:

• Target: Mutex synchronization, resource access atomization;
• Implementation: Only one contention to the lock at a time, the process of contention is an atomic process, can only be used to unlock the unlocked, no deadlock occurs;

Reference

The correct implementation of Redis distributed locks
Rewriting our lock
Lock

Off Topic

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