在分布式系统的很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。

有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中，Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。

目前针对分布式锁的实现目前有多种方案：

基于数据库实现分布式锁基于缓存（redis，memcached）实现分布式锁基于Zookeeper实现分布式锁

在分析这几种实现方案之前我们先来想一下，我们需要的分布式锁应该是怎么样的？（这里以方法锁为例，资源锁同理）

可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。

这把锁要是一把可重入锁（避免死锁）这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条）有高可用的获取锁和释放锁功能获取锁和释放锁的性能要好一. 基于数据库实现分布式锁1.1 基于数据库表

要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。

当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。

创建这样一张数据库表：

CREATE TABLE `methodLock` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键', `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名', `desc` varchar(1024) NOT NULL DEFAULT '备注信息', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成', PRIMARY KEY (`id`), UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

当我们想要锁住某个方法时，执行以下SQL：

insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)

因为我们对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

当方法执行完毕之后，想要释放锁的话，需要执行以下Sql:

delete from methodLock where method_name ='method_name'

上面这种简单的实现有以下几个问题：

这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。

这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。

这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

当然，我们也可以有其他方式解决上面的问题。

针对 数据库是单点问题搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。

针对 没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。

针对 非阻塞的？搞一个while循环，直到insert成功再返回成功。

针对 非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

1.2 基于数据库排他锁

除了可以通过增删操作数据表中的记录以外，其实还可以借助数据中自带的锁来实现分布式的锁。

我们还用刚刚创建的那张数据库表。可以通过数据库的排他锁来实现分布式锁。 基于MySql的InnoDB引擎，可以使用以下方法来实现加锁操作：

public boolean lock(){ connection.setAutoCommit(false) while(true){ try{ result = select * from methodLock where method_name=xxx for update; if(result==null){ return true; } }catch(Exception e){ } sleep(1000); } return false;}

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：

public void unlock(){ connection.commit();}

通过connection.commit()操作来释放锁。

这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。

锁定之后 服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。
但是还是无法直接解决数据库单点和可重入问题。

1.3 总结

总结一下使用数据库来实现分布式锁的方式，这两种方式都是依赖数据库的一张表，一种是通过表中的记录的存在情况确定当前是否有锁存在，另外一种是通过数据库的排他锁来实现分布式锁。

数据库实现分布式锁的 优点: 直接借助数据库，容易理解。

数据库实现分布式锁的 缺点: 会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。

操作数据库需要一定的开销，性能问题需要考虑。

二.基于缓存实现分布式锁

相比较于基于数据库实现分布式锁的方案来说，基于缓存来实现在性能方面会表现的更好一点。而且很多缓存是可以集群部署的，可以解决单点问题。

目前有很多成熟的缓存产品，包括Redis，memcached等。

在实现的时候要注意的几个关键点：

锁信息必须是会过期超时的，不能让一个线程长期占有一个锁而导致死锁；

同一时刻只能有一个线程获取到锁。

几个要用到的redis命令：

setnx(key, value)：“set if not exits”，若该key-value不存在，则成功加入缓存并且返回1，否则返回0。

get(key)：获得key对应的value值，若不存在则返回nil。

getset(key, value)：先获取key对应的value值，若不存在则返回nil，然后将旧的value更新为新的value。

expire(key, seconds)：设置key-value的有效期为seconds秒。

看一下流程图：

在这个流程下，不会导致死锁。

我采用Jedis作为Redis客户端的api，下面来看一下具体实现的代码。

（1）首先要创建一个Redis连接池。

public class RedisPool { private static JedisPool pool;//jedis连接池 private static int maxTotal = 20;//最大连接数 private static int maxIdle = 10;//最大空闲连接数 private static int minIdle = 5;//最小空闲连接数 private static boolean testOnBorrow = true;//在取连接时测试连接的可用性 private static boolean testOnReturn = false;//再还连接时不测试连接的可用性 static { initPool();//初始化连接池 } public static Jedis getJedis(){ return pool.getResource(); } public static void close(Jedis jedis){ jedis.close(); } private static void initPool(){ JedisPoolConfig config = new JedisPoolConfig(); config.setMaxTotal(maxTotal); config.setMaxIdle(maxIdle); config.setMinIdle(minIdle); config.setTestOnBorrow(testOnBorrow); config.setTestOnReturn(testOnReturn); config.setBlockWhenExhausted(true); pool = new JedisPool(config, "127.0.0.1", 6379, 5000, "liqiyao"); }}（2）对Jedis的api进行封装，封装一些实现分布式锁需要用到的操作。

public class RedisPoolUtil { private RedisPoolUtil(){} private static RedisPool redisPool; public static String get(String key){ Jedis jedis = null; String result = null; try { jedis = RedisPool.getJedis(); result = jedis.get(key); } catch (Exception e){ e.printStackTrace(); } finally { if (jedis != null) { jedis.close(); } return result; } } public static Long setnx(String key, String value){ Jedis jedis = null; Long result = null; try { jedis = RedisPool.getJedis(); result = jedis.setnx(key, value); } catch (Exception e){ e.printStackTrace(); } finally { if (jedis != null) { jedis.close(); } return result; } } public static String getSet(String key, String value){ Jedis jedis = null; String result = null; try { jedis = RedisPool.getJedis(); result = jedis.getSet(key, value); } catch (Exception e){ e.printStackTrace(); } finally { if (jedis != null) { jedis.close(); } return result; } } public static Long expire(String key, int seconds){ Jedis jedis = null; Long result = null; try { jedis = RedisPool.getJedis(); result = jedis.expire(key, seconds); } catch (Exception e){ e.printStackTrace(); } finally { if (jedis != null) { jedis.close(); } return result; } } public static Long del(String key){ Jedis jedis = null; Long result = null; try { jedis = RedisPool.getJedis(); result = jedis.del(key); } catch (Exception e){ e.printStackTrace(); } finally { if (jedis != null) { jedis.close(); } return result; } }}（3）分布式锁工具类

public class DistributedLockUtil { private DistributedLockUtil(){ } public static boolean lock(String lockName){//lockName可以为共享变量 名，也可以为方法名，主要是用于模拟锁信息 System.out.println(Thread.currentThread() + "开始尝试加锁！"); Long result = RedisPoolUtil.setnx (lockName, String.valueOf(System.currentTimeMillis() + 5000)); if (result != null && result.intValue() == 1){ System.out.println(Thread.currentThread() + "加锁成功！"); RedisPoolUtil.expire(lockName, 5); System.out.println(Thread.currentThread() + "执行业务逻辑！"); RedisPoolUtil.del(lockName); return true; } else { String lockValueA = RedisPoolUtil.get(lockName); if (lockValueA != null && Long.parseLong(lockValueA) >= System.currentTimeMillis()){ String lockValueB = RedisPoolUtil.getSet(lockName, String.valueOf(System.currentTimeMillis() + 5000)); if (lockValueB == null || lockValueB.equals(lockValueA)){ System.out.println(Thread.currentThread() + "加锁成功！"); RedisPoolUtil.expire(lockName, 5); System.out.println(Thread.currentThread() + "执行业务逻辑！"); RedisPoolUtil.del(lockName); return true; } else { return false; } } else { return false; } } }}三. 基于Zookeeper实现分布式锁

基于zookeeper临时有序节点可以实现的分布式锁。大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的

瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。

来看下Zookeeper能不能解决前面提到的问题。

锁无法释放？
使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。

非阻塞锁？
使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。

不可重入？
使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。

单点问题？
使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。
可以直接使用zookeeper第三方库Curator客户端，这个客户端中封装了一个可重入的锁服务。

public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException { try { return interProcessMutex.acquire(timeout, unit); } catch (Exception e) { e.printStackTrace(); } return true;}public boolean unlock() { try { interProcessMutex.release(); } catch (Throwable e) { log.error(e.getMessage(), e); } finally { executorService.schedule(new Cleaner(client, path), delayTimeForClean, TimeUnit.MILLISECONDS); } return true;}

Curator提供的InterProcessMutex是分布式锁的实现。acquire方法用户获取锁，release方法用于释放锁。

使用ZK实现的分布式锁好像完全符合了本文开头我们对一个分布式锁的所有期望。但是，其实并不是，Zookeeper实现的分布式锁其实存在一个缺点，那就是性能上可能并没有缓存服务
那么高。因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同不到所有的Follower机器上。

总结

使用Zookeeper实现分布式锁的优点: 有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题。实现起来较为简单。

使用Zookeeper实现分布式锁的缺点 : 性能上不如使用缓存实现分布式锁。 需要对ZK的原理有所了解。

四.三种方案的比较

从理解的难易程度角度（从低到高）: 数据库 > 缓存 > Zookeeper

从实现的复杂性角度（从低到高）: Zookeeper >= 缓存 > 数据库

从性能角度（从高到低）: 缓存 > Zookeeper >= 数据库

从可靠性角度（从高到低）: Zookeeper > 缓存 > 数据库

因此我个人更加倾向于使用缓存来实现，后续的文章中会基于Redis封装一个我们自己的分布式锁实现。