超级详细，讲解分布式锁各种实现（附代码）（redis，zookeeper，mysql）

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了超级详细，讲解分布式锁各种实现（附代码）（redis，zookeeper，mysql）相关的知识，希望对你有一定的参考价值。

关注我，看全文，绝对值

分布式理论

1、分布式编程是解决您可以使用多台计算机在单台计算机上解决的同一问题的艺术- 通常，因为问题不再适合单台计算机

2、分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理 更多的数据。

3、分布式系统的核心定理CAP，该定理指出了这三个性质：

（1） 一致性：所有节点同时看到相同的数据。

（2） 可用性：节点故障不会阻止幸存者继续操作。

（3） 分区容错性：尽管由于网络和/或节点故障导致消息丢失， 系统仍继续运行

4，CAP定理的运用

只有两个可以同时满足。可以将其绘制为一个漂亮的图表，从三个属性中选择两个属性为我们提供了三种类型的系统，它们对应于不同的交叉点，如图： 该定理指出中间部分（具有所有三个属性）是不可实现的。然后我们得到三种不同的系统类型：

（1） CA（一致性+可用性）。示例包括完全严格的仲裁协议，例如两阶段提交。

（2） CP（一致性+分区容错性）。示例包括多数仲裁协议，其中少数分区不可用，例如Paxos。

（3） AP（可用性+分区容错性）。示例包括使用冲突解决的协议，例如Dynamo。

5，设计技巧：分区和复制

数据集在多个节点之间分布的方式非常重要。为了进行任何计算，我们需要定位数据，然后对其采取行动。

有两种基本技术可以应用于数据集。它可以拆分到多个节点（分区）以允许更多的并行处理。它也可以被复制或缓存在不同的节点上，以减少客户端和服务器之间的距离和更大的容错（复制）。

  • 分区

    分区是将数据集划分为更小的不同的独立集；这用于减少数据集增长的影响，因为每个分区都是数据的一个子集。 分区通过限制要检查的数据量和在同一分区中定位相关数据来提高性能 分区通过允许分区独立失败来提高可用性，增加在牺牲可用性之前需要失败的节点数量

  • 复制

    复制是在多台机器上复制相同的数据；这允许更多的服务器参与计算。

什么是锁？

在并发编程中，经常会遇到多个线程访问同一个共享资源，这时候我们要保证数据的一致性，那么就要用到了锁的概念，给资源加上锁，拿到锁所有权的人才能够进行操作共享资源，没有拿到锁的线程需要等待，等锁的所有权放开。

Java中实现锁的工具类有: synchronized和JDK以后才引用Lock接口锁. 如：ReentrantLock（可重入锁），ReadWriteLock （读写锁） ReentrantReadWriteLock （可以选择获取什么锁）

在单机多线程的java程序中，我们可以使用堆内存中的变量作为标志，因为多线程是共享堆内存的，堆内存中的变量对于各个线程都是可见的。 但是在分布式系统的java程序中Java提供的锁就无法解决多线程问 题了。

分布式锁概念

与分布式锁相对应的是「单机锁」，我们在写多线程程序时，避免同时操作一个共享变量产生数据问题，通常会使用一把锁来「互斥」，以保证共享变量的正确性，其使用范围是在「同一个进程」中。 如果换做是多个进程，需要同时操作一个共享资源，如何互斥呢？例如，现在的业务应用通常都是分布式架构，为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。 分布式锁的引入：一个应用会部署多个进程，那这多个进程如果需要修改mysql 中的同一行记录时，为了避免操作乱序 导致数据错误，此时，我们就需要引入「分布式锁」来解决这个问题了。 想要实现分布式锁，必须借助一个外部系统，所有进程都去这个系统上申请「加锁」，而这个外部系统，必须要实现「互斥」的能力，即两个请求同时进来，只会给一个进程返回成功，另一个返回失败（或等待）。 这个外部系统，可以是MySQL，也可以是Redis 或Zookeeper。但为了追求更好的性能，我们通常会选择使用Redis或Zookeeper 来做。

分布式锁的特点

  • 互斥性：保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。
  • 可重入性：这把锁要是一把可重入锁（避免死锁），类似于ReentrantLock，同一服务节点的相同线程， 允许重复多次加锁；
  • 阻塞性：支持阻塞和非阻塞: 和ReentrantLock 一样支持lock 和trylock 以及tryLock(long timeOut)。
  • 高可用：有高可用的获取锁和释放锁功能
  • 锁超时：支持锁超时，及时释放，防止锁死。
  • 公平锁与非公平锁：公平锁是指按照请求加锁的顺序获得锁，非公平锁请求加锁是无序的。

分布式的实现方式

  • 数据库 创建一张表, 通过对此表的insert/delete 达到获取, 释放锁的目的; 需要解决DB单点故障, 释放锁失败, 堵塞锁等情况; 优点:借助DB, 容易理解 缺点:性能开销大, 有些笨重, 可能导致系统越来越复杂
  • Redis 集群redis中通过setnx与expire,, 或者setnx与getset设置锁的过期时间, 实现分布式锁; 优点: 有效解决单点问题, 性能高，实现起来较为方便; 缺点:setnx与expire无法确保事务, 一个客户端堵塞很久导致expire自动执行, Redlock：是redis的作者设计的分布式锁方案 优点: •可用性高，大多数节点正常即可。 •单Redis 节点的分布式锁在 failover 时锁失效问题不复存在。 缺点: 设计比较复杂,个人实现比较麻烦,最好借用已经实现了的库 (Redission…)
  • Zookeeper 优点：有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题 实现较为简单 缺点：性能上不如使用缓存实现的分布式锁，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁临时节点来实现锁功能需要对Zookeeper的原理有所了解。

4，Etcd

数据库

1，创建一张表

CREATE TABLE `dl_lock` (
`id` int NOT NULL AUTO_INCREMENT COMMENT 主键,
`lock_name` varchar(64) CHARACTER SET utf8 NOT NULL DEFAULT  COMMENT 锁名,
`desc` varchar(1024) CHARACTER SET utf8 NOT NULL DEFAULT 备注信息 COMMENT 描述信息,
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 保存数据时间（当前时间）,
PRIMARY KEY (`id`) USING BTREE,
UNIQUE INDEX `uidx_method_name`(`lock_name`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 COMMENT = 锁定中的方法 ROW_FORMAT =
Dynamic;

2，表结构

3，唯一索引（uidx_method_name）

4，代码实现

/**
* 非阻塞获取锁
*
* @param lockName  锁的名称
* @param desc	描述
* @return 成功:1
*/
public boolean  lock(String lockName, String desc)  try 
//加锁，成功则返回true，失败则证明已经加锁或发送其他异常
int  result = insert(lockName, desc); if (result == 1) 
return true;

 catch (DuplicateKeyException  e) 
log.info("锁已经被其他线程获取,获取锁失败");
 catch (Exception e) 
log.info("sql  exception,获取锁失败");

return false;



/**
* 阻塞获取锁
*
* @param lockName  锁的名称
* @param desc	描述
* @return 成功:1
*/
public void blockLock(String lockName, String desc)  

while (true) 
//获取锁
if (lock(lockName, desc))  
   return;

//阻塞当前线程3秒
LockSupport.parkNanos(3 * 1000 * 1000);




/**
* 删除记录
*
* @param  lockName  锁名，唯一
* @return
*/
public int  delete(String lockName) 
Map<String, Object> param  = new HashMap<>(); 
param.put("lockName", lockName);
String sql  = "delete from dl_lock  where lock_name
= :lockName";
return namedParameterJdbcTemplate.update(sql, param);



/**
* 锁释放，删除锁记录
*
* @param  lockName  锁名，唯一
* @return
*/
public int  release(String lockName) 
 return delete(lockName);

5，应用

public void apply() 
String lockName  = "test02_lock_name";
//获取锁，如果没有获取到锁，会阻塞直到获取到锁dlLockTemplate.blockLock(lockName, "测试锁02"); 
try 
log.info(Thread.currentThread().getName()+"业务开始执行。。。。。。。");
//业务实现

TimeUnit.SECONDS.sleep(3);
 catch (Exception e) 
//业务异常
 finally 
//业务执行完毕后，释放锁
dlLockTemplate.release(lockName);
log.info(Thread.currentThread().getName()+"业务执行结束。。。。。。。");

6，是否满足分布式锁的所有要求？ （1） 互斥性：保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。 答： 满足 （2） 可重入性：这把锁要是一把可重入锁（避免死锁），类似于ReentrantLock，同一服务节点的相同线程，允许重复多次加锁； 答：可以实现，利用锁的节点信息判断是否是重入锁。 （3） 阻塞性：支持阻塞和非阻塞: 和ReentrantLock 一样支持lock 和trylock 以及tryLock(long timeOut)。答：支持 （4） 高可用：有高可用的获取锁和释放锁功能答：高可用 （5） 锁超时：支持锁超时，及时释放，防止锁死。 答：支持锁超时释放，但需要通过定时任务去查询锁的失败日志去释放，不够及时。 （6） 公平锁与非公平锁：公平锁是指按照请求加锁的顺序获得锁，非公平锁请求加锁是无序的。答：可以实现，比较复杂，通过表记录来实现公平锁的顺序性。

基于数据库锁做分布式锁

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁 (注意：InnoDB 引擎在加锁的时候，只有通过索引进行检索的时候才会使用行级锁，否则会使用表级锁。这里我们希望使用行级锁，就要给要执行的方法字段名添加索引，值得注 意的是，这个索引一定要创建成唯一索引，否则会出现多个重载方法之间无法同时被访问的问题。重载方法的话建议把参数类型也 加上。)。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

基于redis的setnx实现

命令：setnx key value ex 10 nx 1，超时获取锁方法（加锁，自旋，超时后会获取失败）

public boolean tryLock(String lockKey, String valueForRequestId, long timeout) 

long start = System.currentTimeMillis();
boolean locked = false; while (true) 
//超时，锁获取失败
if (System.currentTimeMillis() - start > timeout)  break;
 //加锁，成功返回true，失败返回false
Boolean result = redisTemplate.opsForValue().setIfAbsent(lockKey, valueForRequestId,  timeout, TimeUnit.SECONDS);
 if (Boolean.TRUE.equals(result)) 
locked = true; break;
 else 
//500毫秒后重试
LockSupport.parkNanos(TimeUnit.NANOSECONDS.convert(500, TimeUnit.MILLISECONDS));


return locked;

2，两种解锁方法

/**
*	通过lua脚本锁
*
*	@param lockKey 锁key
*	@return 释放结果
*/
public boolean releaseLock(String lockKey, String valueForRequestId)  

if (lockKey == null || valueForRequestId == null)
return false;
DefaultRedisScript<Long> redisScript = new DefaultRedisScript();
//用于解锁的lua脚本位置
redisScript.setLocation(new ClassPathResource("unlock.lua")); redisScript.setResultType(Long.class);
//没有指定序列化方式，默认使用上面配置的
Object result = redisTemplate.execute(redisScript, Arrays.asList(lockKey), valueForRequestId);
return result.equals(Long.valueOf(1));



/**
* 非原子解锁，可能解别人锁，不安全
*/
public boolean unlock(String lockKey, String valueForRequestId)  if (lockKey == null || valueForRequestId == null)
return false;
boolean releaseLock = false;
String requestId = redisTemplate.opsForValue().get(lockKey); if (valueForRequestId.equals(requestId)) 
releaseLock = redisTemplate.delete(valueForRequestId);

return releaseLock;

Lua脚本

if redis.call(get,KEYS[1]) == ARGV[1] then return redis.call(del,KEYS[1])
else
return 0
end

需要注意的问题

（1） 设置过期时间

（2） 保证加锁和设置过期时间的原子性

（3） Value值使用特定值(进程ID,IP地址,docker ID之类)进行区分,防止误删

（4） 尽可能的使用lua脚本 存在的问题 （1）单体性能堪忧，集群，主从等无法防止单节点故障造成锁丢失

是否满足分布式锁的所有问题？

（1） 互斥性：保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。 答：不满足， 极端情况，如果客户A持有锁，但客户A阻塞住并且锁过期了，这时客户B进来之后同样会成功持有锁， 此时客户A和客户B都拥有了这把锁，无法满足互斥性。 解决方案：在客户A持有锁的时候，如果客户A没有执行完业务或者阻塞情况下，需要给客户A持有的锁进行续命， 也就是常说的锁续命

（2） 可重入性：这把锁要是一把可重入锁（避免死锁），类似于ReentrantLock，同一服务节点的相同线程，允许重复多次加锁； 答：可以实现，利用锁的节点信息判断是否是重入锁。 （3） 阻塞性：支持阻塞和非阻塞: 和ReentrantLock 一样支持lock 和trylock 以及tryLock(long timeOut)。答：支持 （4） 高可用：有高可用的获取锁和释放锁功能答：高可用 （5） 锁超时：支持锁超时，及时释放，防止锁死。答：支持锁超时释放，可以设置过期时间。 （6） 公平锁与非公平锁：公平锁是指按照请求加锁的顺序获得锁，非公平锁请求加锁是无序的。答：可以实现，比较复杂，通过记录来实现公平锁的顺序性。

通过Redisson实现分布式锁

Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。充分的利用了Redis键值数据库提供的一系列优势，基于Java 实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类。使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力，大大降低了设计和研发大规模分布式系统的难度。同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。 Redisson提供了主从，集群，单实例，哨兵等配置。 并且Redisson内部代码实现了很多细节，比如内部的看门狗。 而且也实现了多种锁。

通过Redisson实现分布式锁

RedLock的出现

基于setnx实现分布式锁可能会出现丢锁的现象

  • 无论redis是主从+哨兵还是集群都存在这样的风险。因为这个问题， Redis 之父antirez 提出了redisson的RedLock（红锁）算法

  • RedLock的优点

（1） 可用性高，大多数节点正常即可。

（2） 单Redis 节点的分布式锁在failover 时锁失效问题不复存在 RedLock的缺点

（3）设计比较复杂,个人实现比较麻烦,最好借用已经实现了的库 (Redission…)

  • RedLock算法

Redlock为了解决CAP的cp,数据一致性，采用有n个redis节点，n为奇数（官方推荐5个实例），来保证他们大多数情况下都不会同时宕机，这些节点是完全独立的，因此我们不使用复制或任何其他隐式协调系统。我们已经描述了如何在单个实例中安全地获取和释放锁。我们理所当然地认为算法会在单个实例中使用这种方法来获取和释放锁。在我们的示例中，我们设置了N=5，这是一个合理的值，因此我们需要在不同的计算机或虚拟机上运行 5 个Redis 主节点，以确保它们以几乎独立的方式失败。 为了获取锁，客户端执行以下操作： （1），它以毫秒为单位获取当前时间。 （2），它尝试顺序获取所有N 个实例中的锁，在所有实例中使用相同的键名和随机值。在第 2 步中，当在每个实例中设置锁时，客户端使用一个比总锁自动释放时间更小的超时来获取它。例如，如果自动释放时间为 10 秒，则超时可能在~ 5-50 毫秒范围内。这可以防止客户端长时间处于阻塞状态，试图与已关闭的Redis 节点通信：如果实例不可用，我们应该尽快尝试与下一个实例通信。 （3），客户端通过从当前时间中减去步骤 1 中获得的时间戳来计算获取锁所用的时间。 当且仅当客户端能够在大多数实例（至少 3 个）中获取锁，并且获取锁所用的总时间小于锁有效时间，则认为该锁已获取。 （4），如果获得了锁，则其有效时间被视为初始有效时间减去经过的时间，如步骤 3 中计算的那样。 （5），如果客户端由于某种原因获取锁失败（或者它无法锁定N/2+1 个实例或有效时间为负），它将尝试解锁所有实例（即使是它认为没有成功获取锁的实例）。

  • RedLock的方案

Redlock 的方案基于 2 个前提： （1） 不再需要部署从库和哨兵实例，只部署主库 （2） 但主库要部署多个，官方推荐至少 5 个实例

注意：不是部署Redis Cluster，就是部署 5 个简单的Redis 实例。 Redisson 实现方式（红锁RedLock） github Redisson：

https://github.com/redisson/redisson https://github.com/redisson/redisson/wiki/2.-Configuration RedLock： https://redis.io/topics/distlock

Redisson

1，Redission使用

（1）添加maven配置

<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.16.1</version>
</dependency>

Redisson客户端配置

可以有集群，主从，哨兵，单节点等不同配置的客户端。但他们会丢失锁。 红锁的配置算法则不会出现锁丢失：

配置三个客户端，redissonSingleClient1，redissonSingleClient2， redissonSingleClient3，像下面这一样，注入三个Bean，以client1为例子。

/**
* redisson客户端单机模式1
*/
@Bean("client1")
public RedissonClient redissonSingleClient1()  
Config config1 = new Config();
 config1.useSingleServer()
//可以用"rediss://"来启用SSL连接
.setAddress("redis://192.168.145.132:6379");//...other config add return Redisson.create(config1);

通过三个客户端Rlock，构造一把红锁RedissonRedLock。

private RedissonRedLock redLock; @BeforeEach
public void init() 
String lockKey = "lock_key";
RLock lock1 = redissonClient1.getLock(lockKey); 
RLock lock2 = redissonClient2.getLock(lockKey); 
RLock lock3 = redissonClient3.getLock(lockKey); 
redLock = new RedissonRedLock(lock1, lock2, lock3);

实现分布式锁的一个非常重要的点就是set的value要具有唯一性， redisson的value是怎样保证value的唯一性呢？答案是UUID+threadId。源码在Redisson.java和RedissonLock.java中：

锁的核心代码，根据lua脚步实现 应用

public void apply()  try 
//尝试等待10秒，加锁3秒
boolean lock = redLock.tryLock(10, 3, TimeUnit.SECONDS); log.info(Thread.currentThread().getName() +"redLock:",lock); 
if (lock) 
log.info(Thread.currentThread().getName() + " 业务执行开始。。。。。。。。。");
//业务实现TimeUnit.SECONDS.sleep(3);

 catch (Exception e) 
 finally  redLock.unlock();
log.info(Thread.currentThread().getName() + "业务执行结束。。。。。。。。。");

分布式专家Martin 对于Redlock 的质疑？

  • 分布式锁的目的是什么？ Martin认为，RedLock仍然没有解决锁失效的问题，认为这种算法，就像是给患者服用了重复剂量的药物 一样。

  • 锁在分布式系统中会遇到的问题

  • 分布式系统的NPC问题导致出现的问题

  • 假设时钟正确的是不合理的 Redlock 必须「强依赖」多个节点的时钟是保持同步的，一旦有节点时钟发生错误，那这个算法模型就失效了。Redlock 的算法是建立在「同步模型」基础上的，但同步模型的假设，在分布式系统中是有问题的。

  • 提出fecing token 的方案，保证正确性

这个模型流程如下： 1，客户端在获取锁时，锁服务可以提供一个「递增」的token 2，客户端拿着这个token 去操作共享资源 3，共享资源可以根据token 拒绝「后来者」的请求

Martin 的结论：

1、Redlock 不伦不类：它对于效率来讲，Redlock 比较重，没必要这么做，而对于正确性来说，Redlock 是不够安全的。 2、时钟假设不合理：该算法对系统时钟做出了危险的假设（假设多个节点机器时钟都是一致的），如果 不满足这些假设，锁就会失效。 3、无法保证正确性：Redlock 不能提供类似fencing token 的方案，所以解决不了正确性的问题。为了正确性，请使用有「共识系统」的软件，例如Zookeeper。

Redis 作者Antirez 的反驳 ：

  • 解释时钟问题 Redis 作者表示，Redlock 并不需要完全一致的时钟，只需要大体一致就可以了，允许有「误差」。
  • 解释网络延迟、GC 问题 在RedLock算法的第三步是可以避免的，如果是获取锁操作共享资源的过程出现问题，那这不止是RedLock的问题，任何其他锁服务，例如zookeeper也有问题
  • 质疑fencing token 机制 1， 这个方案必须要求要操作的「共享资源服务器」有拒绝「旧token」的能力。 2，既然资源服务器都有了「互斥」能力，那还要分布式锁干什么？ 3， Redlock 已经提供了随机值（ UUID），利用这个随机值，也可以达到与fecing token 同样的效果

Zookeeper实现分布式锁

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的Chubby 一个开源的实现。它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比 如分布式同步，配置管理，集群管理，命名管理，队列管理。它被设计为易于编程，使用文件系统目录树作为数据模型。服务端跑在 java 上，提供java 和C 的客户端API。 官网地址：http://ZooKeeper.apache.org/ 官网API 地址：http://ZooKeeper.apache.org/doc/r3.4.10/api/index.html

ZooKeeper 作为一个集群提供数据一致的协调服务，自然，最好的方式就是在整个集群中的各服务节点进行数据的复制和同步数据复制的好处：

1、容错：一个节点出错，不至于让整个集群无法提供服务。 2、扩展性：通过增加服务器节点能提高 ZooKeeper 系统的负载能力，把负载分布到多个节点上。 3、高性能：客户端可访问本地 ZooKeeper 节点或者访问就近的节点，依次提高用户的访问速度。 特点： 1、 最终一致性：client 不论连接到哪个Server，展示给它都是同一个视图，这是 ZooKeeper 最重要的性能。 2、 可靠性：具有简单、健壮、良好的性能，如果消息 m 被到一台服务器接受，那么它将被所有的服务器接受。 3、 实时性：ZooKeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者 服务器失效的信息。但由于网络延时等原因， ZooKeeper 不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用 sync()接口。 4、 等待无关（wait-free）：慢的或者失效的 client 不得干预快速的client 的请求，使得每个client 都能有效的等待 5、 原子性：更新只能成功或者失败，没有中间状态。 6、 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息 a 在消息b 前发布，则在所有Server 上消息a 都将在消息 b 前被发布；偏序是指如果一个消息 b 在消息a 后被同一个发送者发布，a 必将排在b 前面。

Zookeeper集群的选举策略

配置多个实例共同构成一个集群对外提供服务以达到水平扩展的目的，每个服务器上的数据是相同的，每一个服务器均可以对外提供读和写的服务。 Zookeeper角色分为Leader和Follower，Leader通过选举产生，Leader产生后，其余节点自动为Follower。选举机制为过半机制。 Zookeeper的四种角色：

Zookeeper集群的选举策略(Zab协议)

选举过程中，zookeeper对客户端是停止访问的，所以只满足CAP中的CP,满足一致性。

Zookeeper文件系统

Zookeeper提供了一个类似文件系统的数据结构。其实zookeeper本身就是一个文件系统+通知机制的系统。

每个子目录项如NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

有四种类型的znode：

1、PERSISTENT-持久化目录节点 客户端与zookeeper断开连接后，该节点依旧存在

2、 PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

3、EPHEMERAL-临时目录节点 客户端与zookeeper断开连接后，该节点被删除

4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

根据Zookeeper的有序节点（编号），临时节点（自动删除）和事件监听特质，可以很方便的实现分布式锁。

事件监听：当节点数据或结构变化时，Zookeeper会通知客户端，当前Zookeeper有以下四种事件： 1，节点创建； 2，节点删除； 3，节点数据修改； 4，子节点变更。

ZooKeeper 实现分布式锁的主要流程：

1，当第一个线程进来时会去父节点上创建一个临时的顺序节点。

2，第二个线程进来发现锁已经被持有了，就会为当前持有锁的节点注册一个watcher 监听器。

3，第三个线程进来发现锁已经被持有了，因为是顺序节点的缘故，就会为上一个节点去创建一个watcher 监听器。

4，当第一个线程释放锁后，删除节点，由它的下一个节点去占有锁。

Curator框架实现分布式锁

Curator是Netflix公司开源的一套zookeeper客户端框架，解决了很多Zookeeper客户端非常底层的细节开发工作，包括 连接重连、反复注册Watcher和NodeExistsException异常等等。Patrixck Hunt（Zookeeper）以一句“Guava is to Java that Curator to Zookeeper”给Curator予高度评价。 1，引入pom

<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.7.0</version>
</dependency>

<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>2.12.0</version>
</dependency>

<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>2.12.0</version>
</dependency>

2，创建客户端连接

/**
*	zkAddr zk地址 ip:port,ip:port,ip:port
*	timeOut 连接超时ms
*	namespace 所有的操作都是在 /namespace 下的节点操作
*	acl Access Control List（访问控制列表）。Znode被创建时带有一个ACL列表<br>
*/
private String zkAddr="192.168.145.132:2181";
 private int timeOut=10000;
private String namespace="zk_lock"; @Bean
public CuratorFramework curatorFramework() throws Exception  RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3); CuratorFrameworkFactory.Builder builder = CuratorFrameworkFactory
.builder()
.connectString(this.zkAddr)
.namespace(StringUtils.isEmpty(namespace) ? “” : namespace)
.connectionTimeoutMs(this.timeOut)
.retryPolicy(retryPolicy); 
CuratorFramework client= builder.build(); 
client.start(); //启动客户端
client.blockUntilConnected(5, TimeUnit.SECONDS); 
return client;

分布式锁对象InterProcessMutex： （1） Client：Zookeeper客户端 （2） path: 锁空间的根节点路径

获取锁方法，this.internalLock（-1，null）方法的参数会永久阻塞：

释放锁：

1，在zk_lock下创建路径为test_lock的锁，结果如右图所示

public void apply() throws Exception 
//创建分布式锁，根节点为test_lock 
InterProcessLock test =zookeeperLock.getInterProcessLock("/test_lock");
//获取锁
test.acquire();
//业务实现try 
TimeUnit.SECONDS.sleep(100);
 catch (Exception e) 
finally 
//释放锁test.release();

1，启动三个线程去调用观察

@Test
public void test01() throws Exception  
for (int i = 0; i < 3; i++) 
new Thread(this::apply).start();

加锁和释放锁的过程：

出现三个临时顺序节点，正常情况下是，00000000，00000001,00000002顺序释放锁，也 就是删除节点。

2，分布式锁使用的问题

zookeeper实现的分布式锁，解决分布式问题，不可重入问题，使用起来也较为简单。但是，存在以下问题： （1）效率低，频繁的创建和删除节点。 因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。大家知道，ZK中创建和删除节点只能通过Leader服务器来执行，然后Leader服务器还需要将数据同步到所有的Follower机器上，这样频繁的网络通信， 性能的短板是非常突出的。 所以，在高性能，高并发的场景下，不建议使用ZooKeeper的分布式锁。而由于ZooKeeper的高可用特性，所以在并发量不是太高的场景，推荐使用ZooKeeper的分布式锁。

几种方式对比

无论哪种方式都无法完美的实现。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所 以，根据不同的应用场景选择最适合自己的才是王道。 （1），从理解的难易程度角度（从低到高） 数据库> 缓存> Zookeeper （2），从实现的复杂性角度（从低到高） Zookeeper >= 缓存> 数据库 （3），从性能角度（从高到低） 缓存> Zookeeper >= 数据库 （4），从可靠性角度（从高到低） Zookeeper > 缓存> 数据库

2，分布式锁带来的问题？ （1），将并发变成串行，降低了系统的访问效率 解决方案：具体的解决方案要根据业务去做优化。

redis分布式锁的正确实现

 

Redis分布式锁的正确实现方式

前言

分布式锁一般有三种实现方式：1. 数据库乐观锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁。本篇博客将介绍第二种方式，基于Redis实现分布式锁。虽然网上已经有各种介绍Redis分布式锁实现的博客，然而他们的实现却有着各种各样的问题，为了避免误人子弟，本篇博客将详细介绍如何正确地实现Redis分布式锁。

可靠性

首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

  1. 互斥性。在任意时刻，只有一个客户端能持有锁。
  2. 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
  3. 具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。
  4. 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

代码实现

组件依赖

首先我们要通过Maven引入Jedis开源组件，在pom.xml文件加入下面的代码：

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

 

加锁代码

正确姿势

Talk is cheap, show me the code。先展示代码，再带大家慢慢解释为什么这样实现：

 
public class RedisTool {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}
 

可以看到，我们加锁就一行代码：jedis.set(String key, String value, String nxxx, String expx, int time)，这个set()方法一共有五个形参：

  • 第一个为key，我们使用key来当锁，因为key是唯一的。

  • 第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。

  • 第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；

  • 第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。

  • 第五个为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1. 当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端。2. 已有锁存在，不做任何操作。

心细的童鞋就会发现了，我们的加锁代码满足我们可靠性里描述的三个条件。首先，set()加入了NX参数，可以保证如果已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。其次，由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。最后，因为我们将value赋值为requestId，代表加锁的客户端请求标识，那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。由于我们只考虑Redis单机部署的场景，所以容错性我们暂不考虑。

错误示例1

比较常见的错误示例就是使用jedis.setnx()和jedis.expire()组合实现加锁，代码如下：

 
public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {

    Long result = jedis.setnx(lockKey, requestId);
    if (result == 1) {
        // 若在这里程序突然崩溃，则无法设置过期时间，将发生死锁
        jedis.expire(lockKey, expireTime);
    }

}
 

setnx()方法作用就是SET IF NOT EXIST，expire()方法就是给锁加一个过期时间。乍一看好像和前面的set()方法结果一样，然而由于这是两条Redis命令，不具有原子性，如果程序在执行完setnx()之后突然崩溃，导致锁没有设置过期时间。那么将会发生死锁。网上之所以有人这样实现，是因为低版本的jedis并不支持多参数的set()方法。

错误示例2

 
public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) {

    long expires = System.currentTimeMillis() + expireTime;
    String expiresStr = String.valueOf(expires);

    // 如果当前锁不存在，返回加锁成功
    if (jedis.setnx(lockKey, expiresStr) == 1) {
        return true;
    }

    // 如果锁存在，获取锁的过期时间
    String currentValueStr = jedis.get(lockKey);
    if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
        // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间
        String oldValueStr = jedis.getSet(lockKey, expiresStr);
        if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
            // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才有权利加锁
            return true;
        }
    }
        
    // 其他情况，一律返回加锁失败
    return false;

}
 

这一种错误示例就比较难以发现问题，而且实现也比较复杂。实现思路：使用jedis.setnx()命令实现加锁，其中key是锁，value是锁的过期时间。执行过程：1. 通过setnx()方法尝试加锁，如果当前锁不存在，返回加锁成功。2. 如果锁已经存在则获取锁的过期时间，和当前时间比较，如果锁已经过期，则设置新的过期时间，返回加锁成功。代码如下：

 

那么这段代码问题在哪里？1. 由于是客户端自己生成过期时间，所以需要强制要求分布式下每个客户端的时间必须同步。 2. 当锁过期的时候，如果多个客户端同时执行jedis.getSet()方法，那么虽然最终只有一个客户端可以加锁，但是这个客户端的锁的过期时间可能被其他客户端覆盖。3. 锁不具备拥有者标识，即任何客户端都可以解锁。

解锁代码

正确姿势

还是先展示代码，再带大家慢慢解释为什么这样实现：

 
public class RedisTool {

    private static final Long RELEASE_SUCCESS = 1L;

    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call(\'get\', KEYS[1]) == ARGV[1] then return redis.call(\'del\', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}
 

可以看到，我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的Lua脚本代码，上一次见到这个编程语言还是在《黑客与画家》里，没想到这次居然用上了。第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的。关于非原子性会带来什么问题，可以阅读【解锁代码-错误示例2】 。那么为什么执行eval()方法可以确保原子性，源于Redis的特性，下面是官网对eval命令的部分解释：

简单来说，就是在eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。

错误示例1

最常见的解锁代码就是直接使用jedis.del()方法删除锁，这种不先判断锁的拥有者而直接解锁的方式，会导致任何客户端都可以随时进行解锁，即使这把锁不是它的。

public static void wrongReleaseLock1(Jedis jedis, String lockKey) {
    jedis.del(lockKey);
}

 

错误示例2

这种解锁代码乍一看也是没问题，甚至我之前也差点这样实现，与正确姿势差不多，唯一区别的是分成两条命令去执行，代码如下：

 
public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
        
    // 判断加锁与解锁是不是同一个客户端
    if (requestId.equals(jedis.get(lockKey))) {
        // 若在此时，这把锁突然不是这个客户端的，则会误解锁
        jedis.del(lockKey);
    }

}
 

如代码注释，问题在于如果调用jedis.del()方法的时候，这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景？答案是肯定的，比如客户端A加锁，一段时间之后客户端A解锁，在执行jedis.del()之前，锁突然过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。

总结

本文主要介绍了如何使用Java代码正确实现Redis分布式锁，对于加锁和解锁也分别给出了两个比较经典的错误示例。其实想要通过Redis实现分布式锁并不难，只要保证能满足可靠性里的四个条件。

支持原创，本文参照：https://www.cnblogs.com/linjiqin/p/8003838.html ，感谢老铁的辛苦付出！

 
 

 

以上是关于超级详细，讲解分布式锁各种实现（附代码）（redis，zookeeper，mysql）的主要内容，如果未能解决你的问题，请参考以下文章

关于redis实现分布式锁

redis分布式锁的正确实现

Redis分布式锁

Redis分布式锁的正确实现方式

Redis分布式锁的正确实现方式

Redis分布式锁的正确实现方式