分布式锁的解决方案以及对比

在单机环境中，java提供了很多api可用来保证线程的安全性，随着业务的发展，在分布式的业务环境中，很显然单纯的靠java api来保证数据的一致性已经无能为力，因此产生了分布式锁的问题。解决分布式锁有三种解决方案：1 基于数据库的解决方式 2 基于缓存(redis)的解决方式 3 基于zookeeper的解决方式。 基于数据库的由于性能不好，这里就不介绍了，有兴趣的同学可以查阅相关资料。

一 基于缓存的分布式锁的解决方案

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

（1）获取锁

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

（2）释放锁

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

（3）防止死锁

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

（4）性能角度

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

（5）可靠性

从可靠性角度分析，Zookeeper可靠性比Redis更好。因为Redis有效期不是很好控制，可能会产生有效期延迟，Zookeeper就不一样，因为Zookeeper临时节点先天性可控的有效期，所以相对来说Zookeeper比Redis更好。

conn.expire(redislockKey, expireLock)，是为了设置锁的超时时间 目的是为了防止死锁。

业务执行完删除对应的key,释放锁。conn.get(redisLockKey).equals(redisValue)，是为了保证删除的是同一把锁。

 

二 基于zookeeper的分布式锁的解决方案

使用zookeeper创建临时序列节点来实现分布式锁，适用于顺序执行的程序，大体思路就是创建临时序列节点，找出最小的序列节点，获取分布式锁，程序执行完成之后此序列节点消失，通过watch来监控节点的变化，从剩下的节点的找到最小的序列节点，获取分布式锁，执行相应处理，依次类推……

（1）获取锁

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

（2）释放锁

Zookeeper使用直接关闭临时节点session会话连接，因为临时节点生命周期与session会话绑定在一块，如果session会话连接关闭的话，该临时节点也会被删除。这时候客户端使用事件监听，如果该临时节点被删除的话，重新进入获获取锁的步骤。

（3）防止死锁

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

（4）性能角度

Redis是NoSQL数据库，基于缓存的，相对比来说Redis比Zookeeper性能要好。

（5）可靠性

Zookeeper可靠性比Redis更好。因为Redis有效期不是很好控制，可能会产生有效期延迟，Zookeeper就不一样，因为Zookeeper临时节点先天性可控的有效期，有事件通知机制，所以相对来说Zookeeper比Redis更好。

zkClient.exists(Path) 判断是否有该节点，如果有的话，就进行等待。

利用zk的事件监听机制，一旦临时节点被删除，其他jvm就会加入到抢锁的行列中。