本文深入解析分布式锁的三种实现方式：数据库锁、基于Redis的分布式锁及基于ZooKeeper的分布式锁。探讨了每种方式的优缺点，重点介绍了Redis锁的正确与错误实现案例，以及ZooKeeper锁的实现原理。
分布式锁一般有三种实现方式：1. 数据库锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁。
分布式锁应该是怎么样的
- 互斥性 可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。
- 具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。
- 不会发生死锁：有一个客户端在持有锁的过程中崩溃而没有解锁，也能保证其他客户端能够加锁
- 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。
- 这把锁要是一把可重入锁（避免死锁）
- 这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条）
一、数据库实现
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='锁定中的方法';2、加锁
insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)3、解锁
delete from methodLock where method_name ='method_name'4、优缺点：
a、优点：易于实现与理解。
b、缺点：
I、这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
II、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
III、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
IV、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。
5、当然，我们也可以有其他方式解决上面的问题。
- 数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。
- 没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
- 非阻塞的？搞一个while循环，直到insert成功再返回成功。
- 非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。
二、Redis实现
代码实现
组件依赖
首先我们要通过Maven引入Jedis开源组件，在pom.xml文件加入下面的代码：
| 1 2 3 4 5 |
|
加锁代码
正确姿势
Talk is cheap, show me the code。先展示代码，再带大家慢慢解释为什么这样实现：
| 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 |
|
可以看到，我们加锁就一行代码：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()组合实现加锁，代码如下：
| 1 2 3 4 5 6 7 8 9 |
|
setnx()方法作用就是SET IF NOT EXIST，expire()方法就是给锁加一个过期时间。乍一看好像和前面的set()方法结果一样，然而由于这是两条Redis命令，不具有原子性，如果程序在执行完setnx()之后突然崩溃，导致锁没有设置过期时间。那么将会发生死锁。网上之所以有人这样实现，是因为低版本的jedis并不支持多参数的set()方法。
错误示例2
这一种错误示例就比较难以发现问题，而且实现也比较复杂。实现思路：使用jedis.setnx()命令实现加锁，其中key是锁，value是锁的过期时间。执行过程：1. 通过setnx()方法尝试加锁，如果当前锁不存在，返回加锁成功。2. 如果锁已经存在则获取锁的过期时间，和当前时间比较，如果锁已经过期，则设置新的过期时间，返回加锁成功。代码如下：
| 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 |
|
那么这段代码问题在哪里？1. 由于是客户端自己生成过期时间，所以需要强制要求分布式下每个客户端的时间必须同步。 2. 当锁过期的时候，如果多个客户端同时执行jedis.getSet()方法，那么虽然最终只有一个客户端可以加锁，但是这个客户端的锁的过期时间可能被其他客户端覆盖。3. 锁不具备拥有者标识，即任何客户端都可以解锁。
解锁代码
正确姿势
还是先展示代码，再带大家慢慢解释为什么这样实现：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
可以看到，我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的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()方法删除锁，这种不先判断锁的拥有者而直接解锁的方式，会导致任何客户端都可以随时进行解锁，即使这把锁不是它的。
| 1 2 3 |
|
错误示例2
这种解锁代码乍一看也是没问题，甚至我之前也差点这样实现，与正确姿势差不多，唯一区别的是分成两条命令去执行，代码如下：
| 1 2 3 4 5 6 7 8 9 |
|
如代码注释，问题在于如果调用jedis.del()方法的时候，这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景？答案是肯定的，比如客户端A加锁，一段时间之后客户端A解锁，在执行jedis.del()之前，锁突然过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。
总结
如果你的项目中Redis是多机部署的，那么可以尝试使用Redisson实现分布式锁，这是Redis官方提供的Java组件，链接在参考阅读章节已经给出。
Redis分布式锁参考：
三、zookeeper的扩展工具Curatorshix实现
1、zookeeper自身可以shi实现分布式锁
a、主要通过在指定节点下创建短暂的有序节点实现。
b、当指定节点下创建子节点时，创建的子节点不为首节点则等待锁，通过对前一节点设置exits()方法监视器实现，当前一节点释放锁时将删除前一节点此时会通知监视器激活等待的锁。
c、可以参考这篇文章或者官网：
zookeeper锁实现：https://www.cnblogs.com/liuyang0/p/6800538.html
2、Curator实现分布式锁
a、示例代码如下：
package com.hubena.distributed.lock.zookeeper;
import java.util.concurrent.TimeUnit;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.retry.ExponentialBackoffRetry;
import org.junit.BeforeClass;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* <p>测试Curator包实现锁.
* @author Zengxb
*/
public class CuratorTest {
private static final Logger logger = LoggerFactory.getLogger(CuratorTest.class);
private static final String zookeeperConnectionString = "127.0.0.1:2183,127.0.0.1:2181,127.0.0.1:2182";
private static CuratorFramework client;
/**
* 可重入分布式锁.
*/
private static InterProcessMutex lock;
@BeforeClass
public static void BeforeClass() {
RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
client = CuratorFrameworkFactory.newClient(zookeeperConnectionString, 5000000,5000000,retryPolicy);
client.start();
lock = new InterProcessMutex(client, "/lock1");
}
@Test
public void testCuratorLock() throws Exception {
// 除非获得锁否则，阻塞直到超时，超过时间未获得锁则返回false
if (lock.acquire(3000, TimeUnit.MILLISECONDS)) {
try {
// do some work inside of the critical section here
logger.debug("获得了可重入锁");
TimeUnit.SECONDS.sleep(5);
logger.debug("准备释放可重入锁");
} finally {
// 释放锁
lock.release();
}
}
}
}
3、Curator实现分布式锁代码跟踪：
获取锁：
a、acquire(long time, TimeUnit unit)方法获取锁：
/**
* 获取互斥锁 - 阻塞直到它可用或给定时间到期。 注意：相同的线程扫描调用会重新获得。 每次调用获 * 取返回true都必须通过调用release（）来平衡，即获得后必须释放。
* to {@link #release()}
*
* @param time time to wait
* @param unit time unit
* @return true if the mutex was acquired, false if not
* @throws Exception ZK errors, connection interruptions
*/
@Override
public boolean acquire(long time, TimeUnit unit) throws Exception
{
return internalLock(time, unit);
}b、internalLock(long time, TimeUnit unit)方法：
private boolean internalLock(long time, TimeUnit unit) throws Exception
{
/*
Note on concurrency: a given lockData instance
can be only acted on by a single thread so locking isn't necessary
*/
Thread currentThread = Thread.currentThread();
/*threadData是一个ConcurrentMap，用于缓存在同一个Jvm中锁与线程对应关系
private final ConcurrentMap<Thread, LockData> threadData = Maps.newConcurrentMap();
*/
LockData lockData = threadData.get(currentThread);
// 如果不为空，则说明当前线程已经获得了锁，只需增加计数就行了
if ( lockData != null )
{
// re-entering
lockData.lockCount.incrementAndGet();
return true;
}
// 以上判断为空则要去zookeeper中获取锁
String lockPath = internals.attemptLock(time, unit, getLockNodeBytes());
// 如果获取的lockPath不为空则获得了锁，lockPath本例中返回值为：
// lockPath:/lock1/_c_5dbcf19c-a5b8-4805-b40b-5ae16bbab2a6-lock-0000000002
if ( lockPath != null )
{
LockData newLockData = new LockData(currentThread, lockPath);
// 将获得的锁放入缓存Map中
threadData.put(currentThread, newLockData);
return true;
}
return false;
}c、
String attemptLock(long time, TimeUnit unit, byte[] lockNodeBytes) throws Exception
{
final long startMillis = System.currentTimeMillis();
final Long millisToWait = (unit != null) ? unit.toMillis(time) : null;
final byte[] localLockNodeBytes = (revocable.get() != null) ? new byte[0] : lockNodeBytes;
int retryCount = 0;
String ourPath = null;
boolean hasTheLock = false;
boolean isDone = false;
while ( !isDone )
{
isDone = true;
try
{ // 在path节点下创建有序短暂ephemeral节点
ourPath = driver.createsTheLock(client, path, localLockNodeBytes);
// 获取锁
hasTheLock = internalLockLoop(startMillis, millisToWait, ourPath);
}
catch ( KeeperException.NoNodeException e )
{
// gets thrown by StandardLockInternalsDriver when it can't find the lock node
// this can happen when the session expires, etc. So, if the retry allows, just try it all again
if ( client.getZookeeperClient().getRetryPolicy().allowRetry(retryCount++, System.currentTimeMillis() - startMillis, RetryLoop.getDefaultRetrySleeper()) )
{
isDone = false;
}
else
{
throw e;
}
}
}
if ( hasTheLock )
{
return ourPath;
}
return null;
}d、internalLockLoop(long startMillis, Long millisToWait, String ourPath)方法：
private boolean internalLockLoop(long startMillis, Long millisToWait, String ourPath) throws Exception
{
boolean haveTheLock = false;
boolean doDelete = false;
try
{
if ( revocable.get() != null )
{
client.getData().usingWatcher(revocableWatcher).forPath(ourPath);
}
while ( (client.getState() == CuratorFrameworkState.STARTED) && !haveTheLock )
{ // 获取锁路径下已排好序的子节点
List<String> children = getSortedChildren();
String sequenceNodeName = ourPath.substring(basePath.length() + 1); // +1 to include the slash
// 获取锁，通过判断是否为首个子节点来判断是否获取锁，maxLeases在初始化InterProcessMutex类时被赋值为1
PredicateResults predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases);
if ( predicateResults.getsTheLock() )
{
haveTheLock = true;
}
else // 如果没有获取锁，则对前一个节点放监视器，在前一节点删除后会通知监视器唤醒阻塞线程
{
String previousSequencePath = basePath + "/" + predicateResults.getPathToWatch();
synchronized(this)
{
try
{
// use getData() instead of exists() to avoid leaving unneeded watchers which is a type of resource leak
// 为前一子节点上监视器 client.getData().usingWatcher(watcher).forPath(previousSequencePath);
if ( millisToWait != null )
{
millisToWait -= (System.currentTimeMillis() - startMillis);
startMillis = System.currentTimeMillis();
if ( millisToWait <= 0 )
{
doDelete = true; // timed out - delete our node
break;
}
wait(millisToWait);
}
else
{
wait();
}
}
catch ( KeeperException.NoNodeException e )
{
// it has been deleted (i.e. lock released). Try to acquire again
}
}
}
}
}
catch ( Exception e )
{
ThreadUtils.checkInterrupted(e);
doDelete = true;
throw e;
}
finally
{ // 如果超时未获取锁或者发生异常则主动删除前面创建的子节点
if ( doDelete )
{
deleteOurPath(ourPath);
}
}
return haveTheLock;
}e、StandardLockInternalsDriver类的getsTheLock(CuratorFramework client, List<String> children, String sequenceNodeName, int maxLeases)方法：
@Override
public PredicateResults getsTheLock(CuratorFramework client, List<String> children, String sequenceNodeName, int maxLeases) throws Exception
{ // 获取当前子节点在锁节点的所有子节点中排序位置ourIndex
int ourIndex = children.indexOf(sequenceNodeName);
validateOurIndex(sequenceNodeName, ourIndex);
// 如果ourIndex 小于maxLeases即小于1.则为true，即为首节点，可以获取到锁
boolean getsTheLock = ourIndex < maxLeases;
// 如果获取到了锁则不用前一节点为空，否则获取到前一节点路径
String pathToWatch = getsTheLock ? null : children.get(ourIndex - maxLeases);
return new PredicateResults(pathToWatch, getsTheLock);
}释放锁：
a、release()
/**
* Perform one release of the mutex if the calling thread is the same thread that acquired it. If the
* thread had made multiple calls to acquire, the mutex will still be held when this method returns.
* 如果调用线程是获取它的同一线程，则释放一次互斥锁。 如果线程已经多次调用获取，则此方法返回时仍将保持互斥锁
*
* @throws Exception ZK errors, interruptions, current thread does not own the lock
*/
@Override
public void release() throws Exception
{
/*
Note on concurrency: a given lockData instance
can be only acted on by a single thread so locking isn't necessary
*/
Thread currentThread = Thread.currentThread();
// 获取此线程中的锁
LockData lockData = threadData.get(currentThread);
// 如果锁为空，则释放锁为不合法操作，抛异常
if ( lockData == null )
{
throw new IllegalMonitorStateException("You do not own the lock: " + basePath);
}
// 将加锁次数减一
int newLockCount = lockData.lockCount.decrementAndGet();
// 如果大于零，则加锁次数大于一，要调用相同次数的释放锁方法才能解锁，所以直接返回，依旧持有锁
if ( newLockCount > 0 )
{
return;
}
// 当小于零时不合法，小于零的场景还没想到何时发生
if ( newLockCount < 0 )
{
throw new IllegalMonitorStateException("Lock count has gone negative for lock: " + basePath);
}
try
{ // 当newLockCount=0时则可以彻底释放锁
internals.releaseLock(lockData.lockPath);
}
finally
{ // 彻底释放锁后必须删除Map中的线程与锁键值对
threadData.remove(currentThread);
}
}b、releaseLock(String lockPath)
final void releaseLock(String lockPath) throws Exception
{
// 删除监视器
client.removeWatchers();
// TODO:这个还没看，等待分析
revocable.set(null);
// 删除节点
deleteOurPath(lockPath);
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
