redis如何做分布式锁（居然可以这样）redis分布式锁有什么用，如果连Redis分布式锁的这些坑都不知道，我怀疑你是假的开发，

1.redis实现分布式锁的几种方式

摘要： 用锁遇到过哪些问题？一、白话分布式什么是分布式，用最简单的话来说，就是为了降低单个服务器的压力，将功能分布在不同的机器上面；就比如：本来一个程序员可以完成一个项目：需求->设计->编码->测试

2.如何使用redis实现分布式锁

但是项目多的时候，一个人也扛不住，这就需要不同的人进行分工合作了

3.redis分布式锁需要注意的问题

这就是一个简单的分布式协同工作了；二、分布式锁首先看一个问题，如果说某个环节被终止或者别侵占，就会发生不可知的事情

4.redis分布式锁怎么用

这就会出现，设计好的或者设计的半成品会被破坏，导致后面环节出错；这时候，我们就需要引入 分布式锁 的概念；何为分布式锁？当在分布式模型下，数据只有一份（或有限制），此时需要利用锁的技术控制某一时刻修改数据的进程数。

5.redis作为分布式锁

用一个状态值表示锁，对锁的占用和释放通过状态值来标识分布式锁的条件：可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行这把锁要是一把可重入锁（避免死锁）这把锁最好是一把阻塞锁。

6.怎么实现redis分布式锁

这把锁最好是一把公平锁有高可用的获取锁和释放锁功能获取锁和释放锁的性能要好分布式锁的实现：分布式锁的实现有很多种，文件锁、数据库、redis等等，比较多，在实践中，还是redis做分布式锁性能会高一些；

7.redis怎么做分布式锁

三、redis实现分布式锁首先看两个命令：setnx:将 key 的值设为 value，当且仅当 key 不存在 若给定的 key 已经存在，则 SETNX 不做任何动作 SETNX 是SET if Not eXists的简写。

8.怎么用redis实现分布式锁

127.0.0.1:6379> setlock “unlock” OK 127.0.0.1:6379> setnxlock “unlock” (integer) 0 127.0.0.1:6379> setnx

9.redis为什么能实现分布式锁

lock “lock” (integer) 0 127.0.0.1:6379> expire: EXPIRE key seconds为给定 key 设置生存时间，当 key 过期时(生存时间为 0 )，它会被自动删除

10.redis 怎么实现分布式锁?

127.0.0.1:6379> expirelock 10 (integer) 1 127.0.0.1:6379> ttllock 8 127.0.0.1:6379> getlock (nil)基于分布式锁的流程：

这就是一个简单的分布式锁的实现流程，具体代码实现也很简单，就不赘述了；四、redis实现分布式锁问题如果出现了这么一个问题：如果setnx是成功的，但是expire设置失败，那么后面如果出现了释放锁失败的问题，那么这个锁永远也不会被得到，业务将被锁死？

解决的办法：使用set的命令，同时设置锁和过期时间set参数：setkeyvalue [EX seconds] [PX milliseconds] [NX|XX] EX seconds：设置失效时长，单位秒 PX milliseconds：设置失效时长，单位毫秒 NX：

key不存在时设置value，成功返回OK，失败返回(nil) XX：key存在时设置value，成功返回OK，失败返回(nil)实践：127.0.0.1:6379> setunlock “234” EX

100 NX (nil) 127.0.0.1:6379> 127.0.0.1:6379> settest “111” EX 100 NXOK这样子就完美地解决了分布式锁的原子性五、用锁遇到过哪些问题？又是如何解决的？。

未关闭资源由于当前线程 获取到redis 锁，处理完业务后未及时释放锁，导致其它线程会一直尝试获取锁阻塞，例如：用Jedis客户端会报如下的错误信息1redis.clients.jedis.exceptions

.JedisConnectionException: Couldnotgetaresourcefromthepoolredis线程池已经没有空闲线程来处理客户端命令使用原生方法记得关闭！解决的方法也很简单，只要我们细心一点，拿到锁的线程处理完业务及时释放锁。

B的锁被A给释放了我们知道Redis实现锁的原理在于 SETNX命令当 key不存在时将 key的值设为 value ，返回值为 1；若给定的 key已经存在，则 SETNX不做任何动作，返回值为 0 。

SETNX key value我们来设想一下这个场景：A、B两个线程来尝试给key myLock加锁，A线程先拿到锁（假如锁3秒后过期），B线程就在等待尝试获取锁，到这一点毛病没有那如果此时业务逻辑比较耗时，执行时间已经超过redis锁过期时间，这时A线程的锁自动释放（删除key），B线程检测到myLock这个key不存在，执行 SETNX命令也拿到了锁。

但是，此时A线程执行完业务逻辑之后，还是会去释放锁（删除key），这就导致B线程的锁被A线程给释放了为避免上边的情况，一般我们在每个线程加锁时要带上自己独有的value值来标识，只释放指定value的key，否则就会出现释放锁混乱的场景。

一般我们可以设置value为业务前缀_当前线程ID或者uuid,只有当前value相同的才可以释放锁锁过期了，业务还没执行完redis分布式锁过期，而业务逻辑没执行完的场景，不过，这里换一种思路想问题，把redis锁的过期时间再弄长点不就解决了吗？

那还是有问题，我们可以在加锁的时候，手动调长redis锁的过期时间，可这个时间多长合适？业务逻辑的执行时间是不可控的，调的过长又会影响操作性能要是redis锁的过期时间能够自动续期就好了为了解决这个问题我们使用redis客户端redisson，redisson很好的解决了redis在分布式环境下的一些棘手问题，它的宗旨就是让使用者减少对Redis的关注，将更多精力用在处理业务逻辑上。

redisson对分布式锁做了很好封装，只需调用API即可1 RLock lock = redissonClient.getLock(“stockLock”);redisson在加锁成功后，会注册一个定时任务监听这个锁，每隔10秒就去查看这个锁，如果还持有锁，就对过期时间进行续期。

默认过期时间30秒这个机制也被叫做：“看门狗”redis主从复制的坑redis高可用最常见的方案就是主从复制（master-slave），这种模式也给redis分布式锁挖了一坑redis cluster集群环境下，假如现在A客户端想要加锁，它会根据路由规则选择一台master节点写入key mylock，在加锁成功后，master节点会把key异步复制给对应的slave节点。

如果此时redis master节点宕机从节点复制失败，为保证集群可用性，会进行主备切换，slave变为了redis masterB客户端在新的master节点上加锁成功，而A客户端也以为自己还是成功加了锁的。

另外如果主从复制延迟同样也会造成加锁和解锁延迟的问题此时就会导致同一时间内多个客户端对一个分布式锁完成了加锁，导致各种脏数据的产生毕竟redis是保持的AP而非CP，如果要追求强一致性可以使用zookeeper分布式锁。

以上就是有关Redis的学习笔记，希望可以对大家学习Redis有帮助，喜欢的小伙伴可以帮忙转发+关注，感谢大家！原文链接：https://www.tuicool.com/articles/qYNzEvu