前言

莫得前言

一、为什么需要分布式锁

目前java中的synchronized或者juc包中的锁都是针对单个jvm的，分布式环境下就无能为力，只能用分布式锁；

二、实现思路

分布式锁目前的方案主要有三种：
1、基于数据库；
2、基于redis；
3、基于zooKeeper；

其中基于数据库和redis的实现原理大同小异，都是通过唯一索引（唯一键）保持排他性，加锁时将需要同步的方法名作为key（如submitEvent.getSubmitErp()+“SUBMIT”），存入数据库或者redis。此处仅以数据库demo演示：

表结构

CREATE TABLE `distributed_lock` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `unique_mutex` varchar(255) NOT NULL COMMENT '业务防重id',
  `holder_id` varchar(255) NOT NULL COMMENT '锁持有者id',
  `create_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `mutex_index` (`unique_mutex`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

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

加锁

insert into distributed_lock(unique_mutex, holder_id) values ('unique_mutex', 'holder_id');

  

 

  
1
 

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

解锁

delete from methodLock where unique_mutex='unique_mutex' and holder_id='holder_id';

  

 

  
1
 

进阶

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

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

基于zk
zk实现方式是利用它节点的唯一性和有序性：
假如当前有一个父节点为/lock，我们可以在这个父节点下面创建子节点；zk提供了一个可选的有序特性，例如我们可以创建子节点“/lock/node-”并且指明有序，那么zk在生成子节点时会根据当前的子节点数量自动添加整数序号，也就是说如果是第一个创建的子节点，那么生成的子节点为/lock/node-0000000000，下一个节点则为/lock/node-0000000001，依次类推。

具体步骤：
1、客户端连接zookeeper，并在/lock下创建临时的且有序的子节点，第一个客户端对应的子节点为/lock/lock-0000000000，第二个为/lock/lock-0000000001，以此类推。

2、客户端获取/lock下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁，否则监听自己前一位子节点的变更消息，获得子节点变更通知后重复此步骤直至获得锁；

3、执行业务代码；

4、完成业务流程后，删除对应的子节点释放锁。

敲黑板
实现一个基于zk的分布式锁还是比较麻烦，尤其是对于小白，我们可以直接使用Apache的开源项目curator，非常方便，有手就能学会；
坐标

<dependency>

	<groupId>org.apache.curator</groupId>

	<artifactId>curator-recipes</artifactId>

	<version>4.0.0</version>
	
</dependency>

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
 

使用

public static void main(String[] args) throws Exception {

//创建zookeeper的客户端

RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);

CuratorFramework client = CuratorFrameworkFactory.newClient("ipAddressOne，ipAddressTwo,ipAddressThree", retryPolicy);

client.start();

//创建分布式锁, 锁空间的根节点路径为/curator/lock

InterProcessMutex mutex = new InterProcessMutex(client, "/curator/mylock");

mutex.acquire();

//获得了锁, 进行业务流程

System.out.println("Enter mutex");

//完成业务流程, 释放锁

mutex.release();

//关闭客户端

client.close();

}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
 

可以看出，使用方式跟juc包的lock很像（Lock&unLock），核心操作就只有mutex.acquire()和mutex.release()；

ok我话说完

文章来源: huangjie.blog.csdn.net，作者：负债程序猿，版权归原作者所有，如需转载，请联系作者。

原文链接：huangjie.blog.csdn.net/article/details/108262995