Implementing distributed locks using the Redis setnx command

Distributed locks can be implemented using Redis's SETNX command, which is described below. 

setnx Command Introduction command Format

Setnx Key value

Set the value of key to value when and only if key does not exist.
If the given key already exists, then SETNX does not do any action.
Setnx is a shorthand for the set if not exists. 

return value

Returns an integer, specifically
-1, when the value of key is set
-0, when the value of key is not set 

example

redis> setnx MyKey "Hello"
(integer) 1
redis> setnx MyKey "Hello"
(integer) 0
Redis> GET MyKey
"Hello"
Redis>

  using SETNX to implement distributed locks

Multiple processes execute the following Redis commands:

Setnx Lock.foo <current Unix time + lock timeout + 1>

If Setnx returns 1, the process obtains the lock, SETNX sets the value of the key Lock.foo to the lock's timeout (the current time + the lock's effective time).
If Setnx returns 0, the other process has acquired a lock and the process cannot enter the critical section. A process can continuously attempt to setnx operations in a loop to obtain a lock. 

Resolving deadlocks

Consider a situation in which if a process obtains a lock, disconnects from Redis (possibly a process hangs up, or a network outage), and if there is no effective mechanism to release the lock, then other processes will be in a waiting state, i.e. "deadlock".

When we use SETNX to obtain the lock, we set the value of the key lock.foo to the effective time of the lock, and when the process gets the lock, the other process will constantly detect if the lock has timed out, and if it times out, then the waiting process will have a chance to get the lock.

However, when the lock expires, we cannot simply use the DEL command to remove the key Lock.foo to release the lock. Consider the following situation where the process P1 has first acquired the lock Lock.foo, and then the process P1 is hung out. Process P2,P3 is constantly detecting whether the lock has been freed or has timed out, and the execution process is as follows: The P2 and P3 process reads the value of the key Lock.foo, detects if the lock has timed out (by comparing the current time and the value of the key Lock.foo to determine if the timeout was exceeded) P2 and P3 process Discovery lock Lock.foo Timeout P2 execute del lock.foo command P2 execute setnx lock.foo command, and return 1, that is P2 get lock P3 execute del lock.foo command will P2 just set the key Lock.foo Delete (This step is because the P3 has just detected that the lock has timed out) P3 Execute Setnx lock.foo Command, and returns 1, i.e. P3 gets lock P2 and P3 simultaneously obtains the lock

As you can tell from the above, the process cannot simply perform the DEL delete key operation to obtain a lock after the lock timeout has been detected.

In order to solve the problem that the above algorithm can get the lock at the same time, we will look at the following algorithm.
We also assume that the process P1 has first acquired the lock Lock.foo, and then the process P1 hangs up. Next: The process P4 executes setnx Lock.foo to attempt to acquire the lock because the process P1 has acquired a lock, so P4 performs setnx Lock.foo returns 0, that is, acquires a lock failure P4 performs get Lock.foo to detect if the lock has timed out, and waits for a period of time if it does not time out Again, if P4 detects that the lock has timed out, that is, the current time is greater than the value of the key Lock.foo, P4 performs the following actions
Getset Lock.foo <current Unix timestamp + lock timeout + 1> because the Getset operation also returns the old value of the key while setting the value of the key, whether the old value is less than the current time by comparing the key Lock.foo To determine if the process has been locked if another process P5 also detects that the lock has timed out and performed the getset operation before P4, then P4 's getset operation returns a timestamp greater than the current time, so that P4 will not acquire the lock and continue to wait. Note that even if P4 next sets the value of the key Lock.foo to a larger value than the P5 setting, it has no effect.

Also, it is important to note that the lock has timed out before the process releases the lock, that is, before executing the DEL lock.foo operation. If the lock has timed out, then the lock may have been obtained by another process, and the direct execution of the DEL Lock.foo operation will cause the lock that the other process has acquired to be freed. 

Program Code

Use the following Python code to implement the above algorithm using the SETNX command as a distributed lock.

Lock_timeout = 3
lock = 0
lock_timeout = 0
lock_key = ' Lock.foo '

# acquires lock while lock! =
1: now
    = Int ( Time.time ())
    lock_timeout = now + lock_timeout + 1
    lock = redis_client.setnx (Lock_key, lock_timeout)
    if lock = = 1 or (now > int (redis_client.get-Lock_key)) and now > int (redis_client.getset (Lock_key, Lock_timeout)):
        Break
    Else:
        time.sleep (0.001)

# acquired lock
Do_job ()

# release lock now
= Int (Time.time ())
if Now < lock_timeout:
    redis_client.delete (Lock_key)

ReferencesHttp://redis.io/commands/setnx Http://redis.io/topics/distlock Http://redis.io/commands/getset/http Redis.readthedocs.org/en/latest/string/setnx.html http://my.oschina.net/u/1995545/blog/366381