java分布式锁

㈠ Redis的Setnx命令实现分布式锁

首先，分布式锁和我们平常讲到的锁原理基本一样，目的就是确保在多个线程并发时，只有一个线程在同一刻操作这个业务或者说方法、变量。

在一个进程中，也就是一个jvm或者说应用中，我们很容易去处理控制，在 java.util 并发包中已经为我们提供了这些方法去加锁，比如 synchronized 关键字或者 Lock 锁，都可以处理。

但是如果在分布式环境下，要保证多个线程同时只有1个能访问某个资源，就需要用到分布式锁。这里我们将介绍用Redis的 setnx 命令来实现分布式锁。

其实目前通常所说的 setnx 命令，并非单指redis的 setnx key value 这条命令，这条命令可能会在后期redis版本中删除。

一般代指redis中对 set 命令加上 nx 参数进行使用， set 这个命令，目前已经支持这么多参数可选：

从 Redis 2.6.12 版本开始， SET 命令的行为可以通过一系列参数来修改：

注入bean

这里同时启动5个线程并发往redis中存储 lock 这个key（key可以自定义，但需要一致），同时设置10秒的过期时间。
setIfAbsent 这个函数实现的功能与 setnx 命令一样，代表如果没有这个key则set成功获取到锁，否则set失败没有获取到锁。
获得锁后进行资源的操作，最后释放锁。

执行效果 ：

可以看到同时只有1个线程能够获取到锁。

使用 setnx 命令方式虽然操作比较简单方便，但是会有如下问题：

可以在再次获取锁时，如果锁被占用就get值，判断值是否是当前线程存的随机值，如果是则再次执行 set 命令重新上锁；当然为了保证原子性这些操作都要用 lua 脚本来执行。

可以使用 while 循环重复执行 setnx 命令，并设置一个超时时间退出循环。

可以尽量把锁自动过期的时间设的冗余一些。但也不能彻底解决。

可以在删除锁的时候先get值，判断值是否是当前线程存的随机值，只有相同才执行删锁的操作；当然也要使用 lua 脚本执行来保证原子性。

分布式锁需要满足的特性

综上：使用 setnx 命令来实现分布式锁并不是一个很严谨的方案，如果是Java技术栈，我们可以使用 Redisson 库来解决以上问题，接下来的文章会介绍如何使用。

Redisson实现分布式锁
Redlock实现分布式锁

㈡ Zookeeper + Curator实现分布式锁

在分布式系统下，使用Java中的synchronized或者Lock已经不能满足需求了。关于分布式锁的实现，我们可以利用Mysql的唯一索引去实现，也可以利用Redis的SETNX，同样也可以使用Zookeeper的节点唯一路径去实现。

（1）线程先去 /locks 路径下面创建一个带序号的临时节点。

（2）判断自己创建的这个节点是不是 /locks 路径下序号最小的节点，如果是，则获取锁；如果不是，则监听自己的前一个节点。

（3）获取到锁后，处理自己的业务逻辑，然后删除自己创建的节点。监听它的后一个节点收到通知后，执行步骤（2）

上面的过程是不是跟AQS的同步队列有点像，判断自己是不是队列的头结点，如果是就去获取锁，不是就等待。

按照上面的思路，我们可以很快的使用zookeeper相关的api实现分布式锁。

通过在zookeeper中创建带序号的临时节点，然后判断当前线程创建的临时节点序号是不是最小的，如果是则获得锁，否则监听前一节点。

为什么要创建临时节点，就是怕创建完后，zookeeper服务器又挂了，这时候如果是永久节点，那么就会死锁了。而临时节点在关闭服务器后就会被删除。

这里使用 CountDownLatch 在监听节点的时候进行 await 。节点发生变化时，会调用 process 方法，在 process 方法中进行 countDown 。

进行测试

创建两个线程进行测试，看控制打印输出

官方文档

使用原生API存在的问题

基于以上，一般实际开发都是用Curator去实现，毕竟别人的轮子又大又安全，何必自己搞个破破烂烂的轮子上路呢。

Curator主要实现了下面四种锁

首先需要在项目中添加依赖

然后实现即可

查看控制台输出

㈢ Springboot使用redis的setnx和getset实现并发锁、分布式锁

在日常开发中，很多业务场景必须保证原子性。举几个例子：

如果你只有一台服务器，只运行一个Java程序，那么可以使用Java语言自身的一些锁来实现原子性。但如果我们有多台服务器，甚至不同服务器上跑的是不同的语言。那这时候，我们就需要一个跨平台、跨语言的加锁方式。redis就是其中最方便的一种。

使用redis实现并发锁，主要是靠两个redis的命令：setnx和getset。

那我们的设计思路就是：

上面的代码使用了一个RedisService的类，里面主要是简单封装了一下redis的操作，你可以替换为自己的service。代码如下：

以上代码有任何疑问，可以点击右侧边栏联系作者。收费5毛~交个朋友，欢迎来撩！

版权声明：《Springboot使用redis的setnx和getset实现并发锁、分布式锁》为CoderBBB作者“ʘᴗʘ”的原创文章，转载请附上原文出处链接及本声明。

原文链接：https://www.coderbbb.com/articles/2

㈣ 高并发没锁可不行，三种分布式锁详解

Java中的锁主要包括synchronized锁和JUC包中的锁，这些锁都是针对单个JVM实例上的锁，对于分布式环境如果我们需要加锁就显得无能为力。在单个JVM实例上，锁的竞争者通常是一些不同的线程，而在分布式环境中，锁的竞争者通常是一些不同的线程或者进程。如何实现在分布式环境中对一个对象进行加锁呢？答案就是分布式锁。

目前分布式锁的实现方案主要包括三种：

基于数据库实现分布式锁主要是利用数据库的唯一索引来实现，唯一索引天然具有排他性，这刚好符合我们对锁的要求：同一时刻只能允许一个竞争者获取锁。加锁时我们在数据库中插入一条锁记录，利用业务id进行防重。当第一个竞争者加锁成功后，第二个竞争者再来加锁就会抛出唯一索引冲突，如果抛出这个异常，我们就判定当前竞争者加锁失败。防重业务id需要我们自己来定义，例如我们的锁对象是一个方法，则我们的业务防重id就是这个方法的名字，如果锁定的对象是一个类，则业务防重id就是这个类名。

基于缓存实现分布式锁：理论上来说使用缓存来实现分布式锁的效率最高，加锁速度最快，因为Redis几乎都是纯内存操作，而基于数据库的方案和基于Zookeeper的方案都会涉及到磁盘文件IO，效率相对低下。一般使用Redis来实现分布式锁都是利用Redis的 SETNX key value 这个命令，只有当key不存在时才会执行成功，如果key已经存在则命令执行失败。

基于Zookeeper：Zookeeper一般用作配置中心，其实现分布式锁的原理和Redis类似，我们在Zookeeper中创建瞬时节点，利用节点不能重复创建的特性来保证排他性。

在实现分布式锁的时候我们需要考虑一些问题，例如：分布式锁是否可重入，分布式锁的释放时机，分布式锁服务端是否有单点问题等。

上面已经分析了基于数据库实现分布式锁的基本原理：通过唯一索引保持排他性，加锁时插入一条记录，解锁是删除这条记录。下面我们就简要实现一下基于数据库的分布式锁。

id字段是数据库的自增id，unique_mutex字段就是我们的防重id，也就是加锁的对象，此对象唯一。在这张表上我们加了一个唯一索引，保证unique_mutex唯一性。holder_id代表竞争到锁的持有者id。

如果当前sql执行成功代表加锁成功，如果抛出唯一索引异常(DuplicatedKeyException)则代表加锁失败，当前锁已经被其他竞争者获取。

解锁很简单，直接删除此条记录即可。

是否可重入 ：就以上的方案来说，我们实现的分布式锁是不可重入的，即是是同一个竞争者，在获取锁后未释放锁之前再来加锁，一样会加锁失败，因此是不可重入的。解决不可重入问题也很简单：加锁时判断记录中是否存在unique_mutex的记录，如果存在且holder_id和当前竞争者id相同，则加锁成功。这样就可以解决不可重入问题。

锁释放时机 ：设想如果一个竞争者获取锁时候，进程挂了，此时distributed_lock表中的这条记录就会一直存在，其他竞争者无法加锁。为了解决这个问题，每次加锁之前我们先判断已经存在的记录的创建时间和当前系统时间之间的差是否已经超过超时时间，如果已经超过则先删除这条记录，再插入新的记录。另外在解锁时，必须是锁的持有者来解锁，其他竞争者无法解锁。这点可以通过holder_id字段来判定。

数据库单点问题 ：单个数据库容易产生单点问题：如果数据库挂了，我们的锁服务就挂了。对于这个问题，可以考虑实现数据库的高可用方案，例如MySQL的MHA高可用解决方案。

使用Jedis来和Redis通信。

可以看到，我们加锁就一行代码：
jedis.set(String key, String value, String nxxx, String expx, int time);
这个set()方法一共五个形参：
第一个为key,我们使用key来当锁，因为key是唯一的。
第二个为value，这里写的是锁竞争者的id，在解锁时，我们需要判断当前解锁的竞争者id是否为锁持有者。
第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作。
第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期时间的设置，具体时间由第五个参数决定；
第五个参数为time，与第四个参数相呼应，代表key的过期时间。
总的来说，执行上面的set()方法就只会导致两种结果：1.当前没有锁（key不存在）,那么久进行加锁操作，并对锁设置一个有效期，同时value表示加锁的客户端。2.已经有锁存在，不做任何操作。
上述解锁请求中， SET_IF_NOT_EXIST (不存在则执行)保证了加锁请求的排他性，缓存超时机制保证了即使一个竞争者加锁之后挂了，也不会产生死锁问题：超时之后其他竞争者依然可以获取锁。通过设置value为竞争者的id，保证了只有锁的持有者才能来解锁，否则任何竞争者都能解锁，那岂不是乱套了。

解锁的步骤：

注意到这里解锁其实是分为2个步骤，涉及到解锁操作的一个原子性操作问题。这也是为什么我们解锁的时候用Lua脚本来实现，因为Lua脚本可以保证操作的原子性。那么这里为什么需要保证这两个步骤的操作是原子操作呢？
设想：假设当前锁的持有者是竞争者1，竞争者1来解锁，成功执行第1步，判断自己就是锁持有者，这是还未执行第2步。这是锁过期了，然后竞争者2对这个key进行了加锁。加锁完成后，竞争者1又来执行第2步，此时错误产生了：竞争者1解锁了不属于自己持有的锁。可能会有人问为什么竞争者1执行完第1步之后突然停止了呢？这个问题其实很好回答，例如竞争者1所在的JVM发生了GC停顿，导致竞争者1的线程停顿。这样的情况发生的概率很低，但是请记住即使只有万分之一的概率，在线上环境中完全可能发生。因此必须保证这两个步骤的操作是原子操作。

是否可重入 ：以上实现的锁是不可重入的，如果需要实现可重入，在 SET_IF_NOT_EXIST 之后，再判断key对应的value是否为当前竞争者id，如果是返回加锁成功，否则失败。

锁释放时机 ：加锁时我们设置了key的超时，当超时后，如果还未解锁，则自动删除key达到解锁的目的。如果一个竞争者获取锁之后挂了，我们的锁服务最多也就在超时时间的这段时间之内不可用。

Redis单点问题 ：如果需要保证锁服务的高可用，可以对Redis做高可用方案：Redis集群+主从切换。目前都有比较成熟的解决方案。

利用Zookeeper创建临时有序节点来实现分布式锁：

其基本思想类似于AQS中的等待队列，将请求排队处理。其流程图如下：

解决不可重入 ：客户端加锁时将主机和线程信息写入锁中，下一次再来加锁时直接和序列最小的节点对比，如果相同，则加锁成功，锁重入。

锁释放时机 ：由于我们创建的节点是顺序临时节点，当客户端获取锁成功之后突然session会话断开，ZK会自动删除这个临时节点。

单点问题 ：ZK是集群部署的，主要一半以上的机器存活，就可以保证服务可用性。

Zookeeper第三方客户端curator中已经实现了基于Zookeeper的分布式锁。利用curator加锁和解锁的代码如下：

㈤ 分布式锁有哪些

单体架构的应用可以直接使用synchronized或者ReentrantLock就可以解决多线程资源竞争的问题。如果公司业务发展较快，可以通过部署多个服务节点来提高系统的并行处理能力。由于本地锁的作用范围只限于当前应用的线程。高并发场景下，集群中某个应用的本地锁并不会对其它应用的资源访问产生互斥，就会产生数据不一致的问题，所以分布锁就派上了用场。

利用select … where … for update 排他锁

所谓乐观锁与前边最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。我们的抢购、秒杀就是用了这种实现以防止超卖。通过增加递增的版本号字段实现乐观锁

思路： 另启一个服务，利用jdk并发工具来控制唯一资源，如在服务中维护一个concurrentHashMap，其他服务对某个key请求锁时，通过该服务暴露的端口，以网络通信的方式发送消息，服务端解析这个消息，将concurrentHashMap中的key对应值设为true，分布式锁请求成功，可以采用基于netty通信调用，当然你想用java的bio、nio或者整合bbo、spring cloud feign来实现通信也没问题

在高并发场景下，应用程序在执行过程中往往会受到网络、CPU、内存等因素的影响，所以实现一个线程安全的分布式组件，往往需要考虑很多case，这个分布式锁有 3 个重要的考量点：

下面是redis分布式锁的各种实现方式和缺点，按照时间的发展排序:

直接利用setnx，执行完业务逻辑后调用del释放锁，简单粗暴!

为了改正第一个方法的缺陷，我们用setnx获取锁，然后用expire对其设置一个过期时间，如果服务挂了，过期时间一到自动释放

redis官方为了解决第二种方式存在的缺点，在2.8版本为set指令添加了扩展参数nx和ex，保证了setnx+expire的原子性，使用方法：set key value ex 5 nx

上面所说的第一个缺点，没有特别好的解决方法，只能把过期时间尽量设置的长一点，并且最好不要执行耗时任务 第二个缺点，可以理解为当前线程有可能会释放其他线程的锁，那么问题就转换为保证线程只能释放当前线程持有的锁，即setnx的时候将value设为任务的唯一id，释放的时候先get key比较一下value是否与当前的id相同，是则释放，否则抛异常回滚，其实也是变相地解决了第一个问题

我们可以用lua来写一个getkey并比较的脚本，jedis/luttce/redisson对lua脚本都有很好的支持

为了解决上面提到的redis集群中的分布式锁问题，redis的作者antirez的提出了red lock的概念，假设集群中所有的n个master节点完全独立，并且没有主从同步，此时对所有的节点都去setnx，并且设置一个请求过期时间re和锁的过期时间le，同时re必须小于le（可以理解，不然请求3秒才拿到锁，而锁的过期时间只有1秒也太蠢了），此时如果有n / 2 + 1个节点成功拿到锁，此次分布式锁就算申请成功

ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：

（1）redis set px nx + 唯一id + lua脚本

综上所得：

没有绝对完美的实现方式，具体要选择哪一种分布式锁，需要结合每一种锁的优缺点和业务特点而定。

㈥ 分布式锁--Redis秒杀(互斥锁)(一)

中秋佳节，进行月饼秒杀，特价，限量1000份，不限每人秒的份数，不要超卖即可。

RedisLock.java

ResultEnum.java

KeyUtil.java

2）无解锁

3）解锁

㈦ 多服务器java毫秒内的重复请求怎么处理

你好，很高兴回答你的问题。
这种问题，有相对成熟的机制来解决。这种机制叫分布式锁。
其实和单机部署时的同步锁类似，单机部署是一个线程获取到锁之后，另一个线程因为获取不到锁就不能和上一个线程同时执行。
分布式锁道理类似，这个锁一般会由一个独立于部署的多个服务实例之外的系统来解决。比如redis，redis有个方法是setNx(key)这个方法是原子性的，如果redis中不存在key对应的数据，则会存入，相当于获取到锁，如果redis中已经存在key对应的数据，说明锁已经被占用，就会返回false。
放服务实例处理完这个业务功能后可以删除掉redis中的数据，相当于适当锁。
为了防止因意外情况导致不会执行释放锁的操作，可以给存入redis的数据设置一个过期时间，如果时间到了，数据还没有被删除，redis会自行删除这条数据。
如果有帮助到你，请点击采纳。

㈧ Redis实现分布式锁与Zookeeper实现分布式锁区别

前言:

在学习过程中，简单的整理了一些redis跟zookeeper实现分布式锁的区别，有需要改正跟补充的地方，希望各位大佬及时指出

Redis实现分布式锁思路

基于Redis实现分布式锁（setnx）setnx也可以存入key，如果存入key成功返回1，如果存入的key已经存在了，返回0.

Zookeeper实现分布式锁思路

基于Zookeeper实现分布式锁 Zookeeper是一个分布式协调工具，在分布式解决方案中。

多个客户端（jvm），同时在zookeeper上创建相同的一个临时节点，因为临时节点路径是保证唯一，只要谁能够创建节点成功，谁就能够获取到锁，没有创建成功节点，就会进行等待，当释放锁的时候，采用事件通知给客户端重新获取锁的资源。

Redis实现分布式锁与Zookeeper实现分布式锁区别

相同点

实现分布式锁最终是通过什么方式？

在集群环境下，保证只允许有一个jvm进行执行。

不同点

从技术上分析

Redis 是nosql数据，主要特点缓存；

Zookeeper是分布式协调工具，主要用于分布式解决方案。

实现思路

核心通过获取锁、释放锁、死锁问题

获取锁

Zookeeper

多个客户端（jvm），会在Zookeeper上创建同一个临时节点，因为Zookeeper节点命名路径保证唯一，不允许出现重复，只要谁能够先创建成功，谁能够获取到锁。

Redis

多个客户端（jvm），会在Redis使用setnx命令创建相同的一个key，因为Redis的key保证唯一，不允许出现重复，只要谁能够先创建成功，谁能够获取到锁。

释放锁

Zookeeper使用直接关闭临时节点session会话连接，因为临时节点生命周期与session会话绑定在一块，如果session会话连接关闭的话，该临时节点也会被删除。

这时候客户端使用事件监听，如果该临时节点被删除的话，重新进入盗获取锁的步骤。

Redis在释放锁的时候，为了确保是锁的一致性问题，在删除的redis 的key时候，需要判断同一个锁的id，才可以删除。

共同特征：如何解决死锁现象问题

Zookeeper使用会话有效期方式解决死锁现象。

Redis 是对key设置有效期解决死锁现象

性能角度考虑

因为Redis是NoSQL数据库，相对比来说Redis比Zookeeper性能要好。

可靠性

从可靠性角度分析，Zookeeper可靠性比Redis更好。

因为Redis有效期不是很好控制，可能会产生有效期延迟；

Zookeeper就不一样，因为Zookeeper临时节点先天性可控的有效期，所以相对来说Zookeeper比Redis更好

总结下两者区别

Redis分布式锁，必须使用者自己间隔时间轮询去尝试加锁，当锁被释放后，存在多线程去争抢锁，并且可能每次间隔时间去尝试锁的时候，都不成功，对性能浪费很大。

Zookeeper分布锁，首先创建加锁标志文件，如果需要等待其他锁，则添加监听后等待通知或者超时，当有锁释放，无须争抢，按照节点顺序，依次通知使用者。

我在学习过程中整理了一些学习资料，可以分享给做java的工程师朋友们，相互交流学习，需要的可以私信 (资料) 即可免费获取Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）

其中覆盖了互联网的方方面面，期间碰到各种产品各种场景下的各种问题，很值得大家借鉴和学习，扩展自己的技术广度和知识面。 最后记得帮作者点个关注

㈨ 使用Redisson实现分布式锁

Redisson的分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口，同时还支持自动过期解锁。

Redisson同时还为分布式锁提供了异步执行的相关方法：

Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。在提供了自动过期解锁功能的同时，保证了当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程。

Redisson同时还为分布式可重入公平锁提供了异步执行的相关方法：

Redisson的RedissonMultiLock对象可以将多个RLock对象关联为一个联锁，每个RLock对象实例可以来自于不同的Redisson实例。

Redisson的RedissonRedLock对象实现了 Redlock 介绍的加锁算法。该对象也可以用来将多个RLock
对象关联为一个红锁，每个RLock对象实例可以来自于不同的Redisson实例。

Redisson的分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。同时还支持自动过期解锁。该对象允许同时有多个读取锁，但是最多只能有一个写入锁。

Redisson的分布式信号量（Semaphore）Java对象RSemaphore采用了与java.util.concurrent.Semaphore相似的接口和用法。

Redisson的可过期性信号量（PermitExpirableSemaphore）实在RSemaphore对象的基础上，为每个信号增加了一个过期时间。每个信号可以通过独立的ID来辨识，释放时只能通过提交这个ID才能释放。

Redisson的分布式闭锁（CountDownLatch）Java对象RCountDownLatch采用了与java.util.concurrent.CountDownLatch相似的接口和用法。

Redisson 分布式锁和同步器