redis分布式锁java

❶ Redis分布式锁的原理是什么如何续期

在传统单体应用单机部署的情况下，并发问题可以通过使用java并发相关的锁如synchronized，但是当规模上升到分布式集群的情况下，要控制共享资源访问，就需要通过分布式锁来实现。常见的分布式锁方案如数据库乐观锁，Redis锁，zk锁等。

Redis分布式锁的原理
Redis分布式锁可以有多种方式实现但是其核心就是通过以下三个Redis命令组合实现。

SETNX SETNX key val 当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。

Expire expire key timeout 为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。

Delete delete key 删除key

核心思想
使用setnx获取锁。如果成功取到锁，则使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁。

获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。

注意
上面为Redis的一个最简单的锁实现原理，实际中还需要考虑更多具体的情况作出相应的调整。如

上面的demo中，当集群系统时间不一致时会有问题

当服务器异常关闭或是重启，加锁后没来得急设置锁超时时间，如何避免死锁

实际开发环境中不确定的因素有很多，需要慢慢地去调整实践达到理想状态，可以考虑使用redisson框架来实现。
如何续期？
这个情况比较独特，出现这个问题的根本原因在于锁失效的时间小于业务处理的时间导致业务还没处理完毕锁就释放了。那么解决方案是合理地结合业务去设置锁失效的时间。

但是也有更好的方案就如前文提到的redisson，其中的可重入锁概念。

默认情况下,加锁的时间是30秒.如果加锁的业务没有执行完,那么到 30-10 = 20秒的时候,就会进行一次续期,把锁重置成30秒。

以上就是redis锁的原理及续期的方式，希望我的回答能对你有所帮助。

❷ 怎样实现redis分布式锁

使用分布式锁要满足的几个条件：系统是一个分布式系统（关键是分布式，单机的可以使用ReentrantLock或者synchronized代码块来实现）共享资源（各个系统访问同一个资源，资源的载体可能是传统关系型数据库或者NoSQL）。

映射（Map）、多值映射（Multimap）、集（Set）、列表（List）、有序集（SortedSet）、计分排序集（ScoredSortedSet）、字典排序集（LexSortedSet）、列队（Queue）、双端队列（Deque）、阻塞队列（Blocking Queue）。

有界阻塞列队（Bounded Blocking Queue）、阻塞双端列队（Blocking Deque）、阻塞公平列队（Blocking Fair Queue）、延迟列队（Delayed Queue）、优先队列（Priority Queue）和优先双端队列（Priority Deque）。

❸ 使用redis实现的分布式锁原理是什么

一、写在前面

现在面试，一般都会聊聊分布式系统这块的东西。通常面试官都会从服务框架（Spring Cloud、Dubbo）聊起，一路聊到分布式事务、分布式锁、ZooKeeper等知识。

所以咱们这篇文章就来聊聊分布式锁这块知识，具体的来看看Redis分布式锁的实现原理。

说实话，如果在公司里落地生产环境用分布式锁的时候，一定是会用开源类库的，比如Redis分布式锁，一般就是用Redisson框架就好了，非常的简便易用。

大家如果有兴趣，可以去看看Redisson的官网，看看如何在项目中引入Redisson的依赖，然后基于Redis实现分布式锁的加锁与释放锁。

下面给大家看一段简单的使用代码片段，先直观的感受一下：

大家看到了吧，那个myLock的hash数据结构中的那个客户端ID，就对应着加锁的次数

（5）释放锁机制

如果执行lock.unlock()，就可以释放分布式锁，此时的业务逻辑也是非常简单的。

其实说白了，就是每次都对myLock数据结构中的那个加锁次数减1。

如果发现加锁次数是0了，说明这个客户端已经不再持有锁了，此时就会用：

“del myLock”命令，从redis里删除这个key。

然后呢，另外的客户端2就可以尝试完成加锁了。

这就是所谓的分布式锁的开源Redisson框架的实现机制。

一般我们在生产系统中，可以用Redisson框架提供的这个类库来基于redis进行分布式锁的加锁与释放锁。

（6）上述Redis分布式锁的缺点

其实上面那种方案最大的问题，就是如果你对某个redis master实例，写入了myLock这种锁key的value，此时会异步复制给对应的master slave实例。

但是这个过程中一旦发生redis master宕机，主备切换，redis slave变为了redis master。

接着就会导致，客户端2来尝试加锁的时候，在新的redis master上完成了加锁，而客户端1也以为自己成功加了锁。

此时就会导致多个客户端对一个分布式锁完成了加锁。

这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。

所以这个就是redis cluster，或者是redis master-slave架构的主从异步复制导致的redis分布式锁的最大缺陷：在redis master实例宕机的时候，可能导致多个客户端同时完成加锁。

❹ java 链接redis 怎么加锁

我介绍一下Redis分布式锁吧：

一、定义redis实现分布式锁的接口

[java]viewplainprint?
packagecom.iol.common.util.concurrent.locks;

importjava.io.Serializable;

/**
*Description:定义redis实现分布式锁的算法<br/>
*_SMALL_TAIL.<br/>
*ProgramName:IOL_SMALL_TAIL<br/>
*Date:2015年11月8日
*
*@author王鑫
*@version1.0
*/
{
/**
*加锁算法<br/>
*@paramkey
*@return
*/
publicbooleanlock(Stringkey);

/**
*解锁算法<br/>
*@paramkey
*@return
*/
publicbooleanunLock(Stringkey);
}

二、redis分布式锁基础算法实现

[java]viewplainprint?
packagecom.iol.common.util.concurrent.locks.arithmetic;

importorg.slf4j.Logger;
importorg.slf4j.LoggerFactory;

importcom.iol.common.util.concurrent.locks.IRedisComponent;
importcom.iol.common.util.concurrent.locks.IRedisLockArithmetic;

/**
*Description:redis分布式锁基础算法实现<br/>
*_SMALL_TAIL.<br/>
*ProgramName:IOL_SMALL_TAIL<br/>
*Date:2015年11月9日
*
*@author王鑫
*@version1.0
*/
{
/**
*serialVersionUID
*/
=-8333946071502606883L;

privateLoggerlogger=LoggerFactory.getLogger(RedisLockBaseArithmetic.class);

/**
*redis操作方法
*/
;

/**
*超时时间，以毫秒为单位<br/>
*默认为5分钟
*/
privatelongovertime=5*60*1000L;

/**
*休眠时长，以毫秒为单位<br/>
*默认为100毫秒
*/
privatelongsleeptime=100L;

/**
*当前时间
*/
privatelongcurrentLockTime;

/**
*@
*/
publicvoidsetRedisComp(IRedisComponentredisComp){
this.redisComp=redisComp;
}

/**
*@paramovertimetheovertimetoset
*/
publicvoidsetOvertime(longovertime){
this.overtime=overtime;
}

/**
*@
*/
publicvoidsetSleeptime(longsleeptime){
this.sleeptime=sleeptime;
}

/*(non-Javadoc)
*@seecom.iol.common.util.concurrent.locks.IRedisLockArithmetic#lock(java.lang.String,java.lang.Long)
*/
@Override
publicbooleanlock(Stringkey){
while(true){
//当前加锁时间
currentLockTime=System.currentTimeMillis();

if(redisComp.setIfAbsent(key,currentLockTime)){
//获取锁成功
logger.debug("直接获取锁{key:{},currentLockTime:{}}",key,currentLockTime);
returntrue;
}else{
//其他线程占用了锁
logger.debug("检测到锁被占用{key:{},currentLockTime:{}}",key,currentLockTime);
LongotherLockTime=redisComp.get(key);
if(otherLockTime==null){
//其他系统释放了锁
//立刻重新尝试加锁
logger.debug("检测到锁被释放{key:{},currentLockTime:{}}",key,currentLockTime);
continue;
}else{
if(currentLockTime-otherLockTime>=overtime){
//锁超时
//尝试更新锁
logger.debug("检测到锁超时{key:{},currentLockTime:{},otherLockTime:{}}",key,currentLockTime,otherLockTime);
LongotherLockTime2=redisComp.getAndSet(key,currentLockTime);
if(otherLockTime2==null||otherLockTime.equals(otherLockTime2)){
logger.debug("获取到超时锁{key:{},currentLockTime:{},otherLockTime:{},otherLockTime2:{}}",key,currentLockTime,otherLockTime,otherLockTime2);
returntrue;
}else{
sleep();
//重新尝试加锁
logger.debug("重新尝试加锁{key:{},currentLockTime:{}}",key,currentLockTime);
continue;
}
}else{
//锁未超时
sleep();
//重新尝试加锁
logger.debug("重新尝试加锁{key:{},currentLockTime:{}}",key,currentLockTime);
continue;
}
}
}
}
}

/*(non-Javadoc)
*@seecom.iol.common.util.concurrent.locks.IRedisLockArithmetic#unLock(java.lang.String)
*/
@Override
publicbooleanunLock(Stringkey){
logger.debug("解锁{key:{}}",key);
redisComp.delete(key);
returntrue;
}

/**
*休眠<br/>
*@paramsleeptime
*/
privatevoidsleep(){
try{
Thread.sleep(sleeptime);
}catch(InterruptedExceptione){
thrownewLockException("线程异常中断",e);
}
}
}

❺ java怎么实现redis分布式锁

Redis有一系列的命令，特点是以NX结尾，NX是Not eXists的缩写，如SETNX命令就应该理解为：SET if Not eXists。这系列的命令非常有用，这里讲使用SETNX来实现分布式锁。

用SETNX实现分布式锁

利用SETNX非常简单地实现分布式锁。例如：某客户端要获得一个名字foo的锁，客户端使用下面的命令进行获取：

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

如返回1，则该客户端获得锁，把lock.foo的键值设置为时间值表示该键已被锁定，该客户端最后可以通过DEL lock.foo来释放该锁。
如返回0，表明该锁已被其他客户端取得，这时我们可以先返回或进行重试等对方完成或等待锁超时。
解决死锁

上面的锁定逻辑有一个问题：如果一个持有锁的客户端失败或崩溃了不能释放锁，该怎么解决？我们可以通过锁的键对应的时间戳来判断这种情况是否发生了，如果当前的时间已经大于lock.foo的值，说明该锁已失效，可以被重新使用。

发生这种情况时，可不能简单的通过DEL来删除锁，然后再SETNX一次，当多个客户端检测到锁超时后都会尝试去释放它，这里就可能出现一个竞态条件,让我们模拟一下这个场景：

C0操作超时了，但它还持有着锁，C1和C2读取lock.foo检查时间戳，先后发现超时了。
C1 发送DEL lock.foo
C1 发送SETNX lock.foo 并且成功了。
C2 发送DEL lock.foo
C2 发送SETNX lock.foo 并且成功了。
这样一来，C1，C2都拿到了锁！问题大了！

幸好这种问题是可以避免D，让我们来看看C3这个客户端是怎样做的：

C3发送SETNX lock.foo 想要获得锁，由于C0还持有锁，所以Redis返回给C3一个0
C3发送GET lock.foo 以检查锁是否超时了，如果没超时，则等待或重试。
反之，如果已超时，C3通过下面的操作来尝试获得锁：
GETSET lock.foo <current Unix time + lock timeout + 1>
通过GETSET，C3拿到的时间戳如果仍然是超时的，那就说明，C3如愿以偿拿到锁了。
如果在C3之前，有个叫C4的客户端比C3快一步执行了上面的操作，那么C3拿到的时间戳是个未超时的值，这时，C3没有如期获得锁，需要再次等待或重试。留意一下，尽管C3没拿到锁，但它改写了C4设置的锁的超时值，不过这一点非常微小的误差带来的影响可以忽略不计。
注意：为了让分布式锁的算法更稳键些，持有锁的客户端在解锁之前应该再检查一次自己的锁是否已经超时，再去做DEL操作，因为可能客户端因为某个耗时的操作而挂起，操作完的时候锁因为超时已经被别人获得，这时就不必解锁了。

示例伪代码

根据上面的代码，我写了一小段Fake代码来描述使用分布式锁的全过程：

# get lock
lock = 0
while lock != 1:
timestamp = current Unix time + lock timeout + 1
lock = SETNX lock.foo timestamp
if lock == 1 or (now() > (GET lock.foo) and now() > (GETSET lock.foo timestamp)):
break;
else:
sleep(10ms)

# do your job
do_job()

# release
if now() < GET lock.foo:
DEL lock.foo
是的，要想这段逻辑可以重用，使用python的你马上就想到了Decorator，而用Java的你是不是也想到了那谁？AOP + annotation？行，怎样舒服怎样用吧，别重复代码就行。

❻ redis 分布式锁为什么比synchronized 快

从redis获取值N，对数值N进行边界检查，自加1，然后N写回redis中。
这种应用场景很常见，像秒杀，全局递增ID、IP访问限制等。
以IP访问限制来说，恶意攻击者可能发起无限次访问，并发量比较大，分布式环境下对N的边界检查就不可靠，因为从redis读的N可能已经是脏数据。
传统的加锁的做法（如java的synchronized和Lock）也没用，因为这是分布式环境，这个同步问题的救火队员也束手无策。在这危急存亡之秋，分布式锁终于有用武之地了。

❼ Redis 分布式锁有什么缺陷

Redis 分布式锁不能解决超时的问题，分布式锁有一个超时时间，程序的执行如果超出了锁的超时时间就会出现问题。

❽ Redis的主要功能

缓存：这应该是 Redis 最主要的功能了，也是大型网站必备机制，合理地使用缓存不仅可以加 快数据的访问速度，而且能够有效地降低后端数据源的压力。共享Session：对于一些依赖 session 功能的服务来说，如果需要从单机变成集群的话，可以选择 redis 来统一管理 session。消息队列系统：消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务 解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功 能，虽然和专业的消息队列比还不够足够强大，但是对于一般的消息队列功 能基本可以满足。比如在分布式爬虫系统中，使用 redis 来统一管理 url队列。分布式锁：在分布式服务中。可以利用Redis的setnx功能来编写分布式的锁，虽然这个可能不是太常用。 当然还有诸如排行榜、点赞功能都可以使用 Redis 来实现，但是 Redis 也不是什么都可以做，比如数据量特别大时，不适合 Redis，我们知道 Redis 是基于内存的，虽然内存很便宜，但是如果你每天的数据量特别大，比如几亿条的用户行为日志数据，用 Redis 来存储的话，成本相当的高。