使用Redis SETNX 命令实现分布式锁

转自:http://blog.csdn.net/lihao21/article/details/49104695

使用Redis的 SETNX 命令可以实现分布式锁,下文介绍其实现方法。

SETNX命令简介

命令格式

SETNX key value

将 key 的值设为 value,当且仅当 key 不存在。 
若给定的 key 已经存在,则 SETNX 不做任何动作。 
SETNX 是SET if Not eXists的简写。

返回值

返回整数,具体为 
- 1,当 key 的值被设置 
- 0,当 key 的值没被设置

例子

redis> SETNX mykey “hello” 
(integer) 1 
redis> SETNX mykey “hello” 
(integer) 0 
redis> GET mykey 
“hello” 
redis>

使用SETNX实现分布式锁

多个进程执行以下Redis命令:

SETNX lock.foo <current Unix time + lock timeout + 1>

如果 SETNX 返回1,说明该进程获得锁,SETNX将键 lock.foo 的值设置为锁的超时时间(当前时间 + 锁的有效时间)。 
如果 SETNX 返回0,说明其他进程已经获得了锁,进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作,以获得锁。

解决死锁

考虑一种情况,如果进程获得锁后,断开了与 Redis 的连接(可能是进程挂掉,或者网络中断),如果没有有效的释放锁的机制,那么其他进程都会处于一直等待的状态,即出现“死锁”。

上面在使用 SETNX 获得锁时,我们将键 lock.foo 的值设置为锁的有效时间,进程获得锁后,其他进程还会不断的检测锁是否已超时,如果超时,那么等待的进程也将有机会获得锁。

然而,锁超时时,我们不能简单地使用 DEL 命令删除键 lock.foo 以释放锁。考虑以下情况,进程P1已经首先获得了锁 lock.foo,然后进程P1挂掉了。进程P2,P3正在不断地检测锁是否已释放或者已超时,执行流程如下:

  • P2和P3进程读取键 lock.foo 的值,检测锁是否已超时(通过比较当前时间和键 lock.foo 的值来判断是否超时)
  • P2和P3进程发现锁 lock.foo 已超时
  • P2执行 DEL lock.foo命令
  • P2执行 SETNX lock.foo命令,并返回1,即P2获得锁
  • P3执行 DEL lock.foo命令将P2刚刚设置的键 lock.foo 删除(这步是由于P3刚才已检测到锁已超时)
  • P3执行 SETNX lock.foo命令,并返回1,即P3获得锁
  • P2和P3同时获得了锁

从上面的情况可以得知,在检测到锁超时后,进程不能直接简单地执行 DEL 删除键的操作以获得锁。

为了解决上述算法可能出现的多个进程同时获得锁的问题,我们再来看以下的算法。 
我们同样假设进程P1已经首先获得了锁 lock.foo,然后进程P1挂掉了。接下来的情况:

  • 进程P4执行 SETNX lock.foo 以尝试获取锁
  • 由于进程P1已获得了锁,所以P4执行 SETNX lock.foo 返回0,即获取锁失败
  • P4执行 GET lock.foo 来检测锁是否已超时,如果没超时,则等待一段时间,再次检测
  • 如果P4检测到锁已超时,即当前的时间大于键 lock.foo 的值,P4会执行以下操作 
    GETSET lock.foo <current Unix timestamp + lock timeout + 1>
  • 由于 GETSET 操作在设置键的值的同时,还会返回键的旧值,通过比较键 lock.foo 的旧值是否小于当前时间,可以判断进程是否已获得锁
  • 假如另一个进程P5也检测到锁已超时,并在P4之前执行了 GETSET 操作,那么P4的 GETSET 操作返回的是一个大于当前时间的时间戳,这样P4就不会获得锁而继续等待。注意到,即使P4接下来将键 lock.foo 的值设置了比P5设置的更大的值也没影响。

另外,值得注意的是,在进程释放锁,即执行 DEL lock.foo 操作前,需要先判断锁是否已超时。如果锁已超时,那么锁可能已由其他进程获得,这时直接执行 DEL lock.foo 操作会导致把其他进程已获得的锁释放掉。

程序代码

用以下Python代码来实现上述的使用 SETNX 命令作分布式锁的算法。

LOCK_TIMEOUT = 3
lock = 0
lock_timeout = 0
lock_key = ‘lock.foo‘

# 获取锁
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)

# 已获得锁
do_job()

# 释放锁
now = int(time.time())
if now < lock_timeout:
    redis_client.delete(lock_key)

参考资料

时间: 2025-01-20 04:57:05

使用Redis SETNX 命令实现分布式锁的相关文章

基于redis的一种分布式锁

前言:本文介绍了一种基于redis的分布式锁,利用jedis实现应用(本文应用于多客户端+一个redis的架构,并未考虑在redis为主从架构时的情况) 文章理论来源部分引自:https://i.cnblogs.com/EditPosts.aspx?opt=1 一.基本原理 1.用一个状态值表示锁,对锁的占用和释放通过状态值来标识. 2.redis采用单进程单线程模式,采用队列模式将并发访问变成串行访问,多客户端对Redis的连接并不存在竞争关系. 二.基本命令 1.setNX(SET if N

Redis事务与可分布式锁

1    Redis事务 1.1   Redis事务介绍 l  Redis的事务是通过MULTI,EXEC,DISCARD和WATCH这四个命令来完成的. l  Redis的单个命令都是原子性的,所以这里确保事务性的对象是命令集合. l  Redis将命令集合序列化并确保处于同一事务的命令集合连续且不被打断的执行 l  Redis不支持回滚操作 1.2   相关命令 l  MULTI 用于标记事务块的开始. Redis会将后续的命令逐个放入队列中,然后使用EXEC命令原子化地执行这个命令序列.

深入Redis(一)分布式锁

分布式锁 由于分布式应用在逻辑处理时存在并发问题,比方修改数据,要先读取到内存,在内存中修改后再保存回去,这两个操作是单独的,如果同时进行,就会出现并发问题. 此时就要用到分布式锁来限制程序的并发执行. 本质 本质就是在Redis内占一个位置,若别的进程也想占用该位置,发现有进程在使用该位置,就放弃或等待. 在Redis中实现依靠setnx(set if not exists)指令,用完了再调用del指令来释放位置. 在1中,如果逻辑执行到中间出现异常,可能导致del未调用,这就陷入死锁,锁永远

基于redis和zookeeper的分布式锁实现方式

先来说说什么是分布式锁,简单来说,分布式锁就是在分布式并发场景中,能够实现多节点的代码同步的一种机制.从实现角度来看,主要有两种方式:基于redis的方式和基于zookeeper的方式,下面分别简单介绍下这两种方式: 一.基于redis的分布式锁实现 1.获取锁 redis是一种key-value形式的NOSQL数据库,常用于作服务器的缓存.从redis v2.6.12开始,set命令开始变成如下格式: SET key value [EX seconds] [PX milliseconds] [

【连载】redis库存操作,分布式锁的四种实现方式[三]--基于Redis watch机制实现分布式锁

一.redis的事务介绍 1. Redis保证一个事务中的所有命令要么都执行,要么都不执行.如果在发送EXEC命令前客户端断线了,则Redis会清空事务队列,事务中的所有命令都不会执行.而一旦客户端发送了EXEC命令,所有的命令就都会被执行,即使此后客户端断线也没关系,因为Redis中已经记录了所有要执行的命令. 2. 除此之外,Redis的事务还能保证一个事务内的命令依次执行而不被其他命令插入.试想客户端A需要执行几条命令,同时客户端B发送了一条命令,如果不使用事务,则客户端B的命令可能会插入

redis击穿,穿透,雪崩,分布式锁,api(jedis,luttuce)

击穿:(redis做缓存用,肯定发生了高并发,到达数据库查询)设置key 的过期时间,过期后没有这个key,找不到了,就穿过了(其中一个key过期导致并发访问数据库)LRU (LRU,即:最近最少使用淘汰算法(Least Recently Used).LRU是淘汰最长时间没有被使用的页面.)LFU (LFU,即:最不经常使用淘汰算法(Least Frequently Used).LFU是淘汰一段时间内,使用次数最少的页面) 1.key为null 2.setnx 如果key存在,则什么都不做 在

jedisLock—redis分布式锁实现

一.使用分布式锁要满足的几个条件: 系统是一个分布式系统(关键是分布式,单机的可以使用ReentrantLock或者synchronized代码块来实现) 共享资源(各个系统访问同一个资源,资源的载体可能是传统关系型数据库或者NoSQL) 同步访问(即有很多个进程同事访问同一个共享资源.没有同步访问,谁管你资源竞争不竞争) 二.应用的场景例子 管理后台的部署架构(多台tomcat服务器+redis[多台tomcat服务器访问一台redis]+mysql[多台tomcat服务器访问一台服务器上的m

AOP实现redis分布式锁

背景:我们系统有一个下传单据接口由于上游推送重复单据[产生异步任务],消费任务的时候是多线程并发执行,导致我们的数据库有很多重复的脏数据,数据库由于业务原因无法加唯一性索引. 解决方案:使用redis的setnx命令实现分布式锁. 原理:setnx---> 这种加锁的思路是,如果 key 不存在,将 key 设置为 value,返回true.如果 key 已存在,则 SETNX 不做任何动作,返回false. 锁的实现 锁的key为目标数据的唯一键,value为锁的期望超时时间点: 首先进行一次

redisTemplate通过setNx实现分布式锁

客户端C2使用SETNX命令获取锁 假设客户端C1已经崩溃但是仍然持有锁,所以Redis返回false给客户端C2 客户端C2使用GET命令获取锁并检查锁是否已经过期,如果没有过期,则继续等待一段时间并重新重试 如果锁已经过期,客户端C2尝试 GETSET lock.name <current Unix timestamp + lock timeout + 1> 利用GETSET语法,客户端C2可以检查key的旧值(锁的旧时间)是否仍然是过期时间,如果是,则获取锁 如果另一个客户端C3率先获取