使用Redis做为分布式锁的一些注意点

Redis实现分布式锁

最近看分布式锁的过程当中看到一篇不错的文章，特意的加工一番本身的理解：

Redis分布式锁实现的三个核心要素：

1.加锁

最简单的方法是使用setnx命令。key是锁的惟一标识，按业务来决定命名，value为当前线程的线程ID。

好比想要给一种商品的秒杀活动加锁，能够给key命名为 “lock_sale_ID” 。而value设置成什么呢？咱们能够姑且设置成1。加锁的伪代码以下：    

setnx（key，1）当一个线程执行setnx返回1，说明key本来不存在，该线程成功获得了锁，当其余线程执行setnx返回0，说明key已经存在，该线程抢锁失败。

 

2.解锁

有加锁就得有解锁。当获得锁的线程执行完任务，须要释放锁，以便其余线程能够进入。释放锁的最简单方式是执行del指令，伪代码以下：

del（key）释放锁以后，其余线程就能够继续执行setnx命令来得到锁。

 

3.锁超时

锁超时是什么意思呢？若是一个获得锁的线程在执行任务的过程当中挂掉，来不及显式地释放锁，这块资源将会永远被锁住，别的线程再也别想进来。

因此，setnx的key必须设置一个超时时间，以保证即便没有被显式释放，这把锁也要在必定时间后自动释放。setnx不支持超时参数，因此须要额外的指令，伪代码以下：

expire（key， 30）综合起来，咱们分布式锁实现的初版伪代码以下：

 

if（setnx（key，1） == 1）{
    expire（key，30）
    try {
        do something ......
    }catch()
　　{
　　}
　　finally {
       del（key）
    }

}

 

由于上面的伪代码中，存在着三个致命问题：

 

1. setnx和expire的非原子性

设想一个极端场景，当某线程执行setnx，成功获得了锁：

setnx刚执行成功，还将来得及执行expire指令，节点1 Duang的一声挂掉了。

if（setnx（key，1） == 1）{
　　//此处挂掉了.....
    expire（key，30）
    try {
        do something ......
    }catch()
　　{
　　}
　　finally {
       del（key）
    }

}

这样一来，这把锁就没有设置过时时间，变得“长生不老”，别的线程再也没法得到锁了。

怎么解决呢？setnx指令自己是不支持传入超时时间的，Redis 2.6.12以上版本为set指令增长了可选参数，伪代码以下：set（key，1，30，NX）,这样就能够取代setnx指令。

 

2. 超时后使用del 致使误删其余线程的锁

又是一个极端场景，假如某线程成功获得了锁，而且设置的超时时间是30秒。

若是某些缘由致使线程B执行的很慢很慢，过了30秒都没执行完，这时候锁过时自动释放，线程B获得了锁。

随后，线程A执行完了任务，线程A接着执行del指令来释放锁。但这时候线程B还没执行完，线程A实际上删除的是线程B加的锁。

怎么避免这种状况呢？能够在del释放锁以前作一个判断，验证当前的锁是否是本身加的锁。

至于具体的实现，能够在加锁的时候把当前的线程ID当作value，并在删除以前验证key对应的value是否是本身线程的ID。

加锁：
String threadId = Thread.currentThread().getId()
set（key，threadId ，30，NX）

doSomething.....
 
解锁：
if（threadId .equals(redisClient.get(key))）{ del(key)
}

 

可是，这样作又隐含了一个新的问题，if判断和释放锁是两个独立操做，不是原子性。

咱们都是追求极致的程序员，因此这一块要用Lua脚原本实现：

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

redisClient.eval(luaScript , Collections.singletonList(key), Collections.singletonList(threadId));

这样一来，验证和删除过程就是原子操做了。

 

3. 出现并发的可能性

仍是刚才第二点所描述的场景，虽然咱们避免了线程A误删掉key的状况，可是同一时间有A，B两个线程在访问代码块，仍然是不完美的。

怎么办呢？咱们能够让得到锁的线程开启一个守护线程，用来给快要过时的锁“续航”。

当过去了29秒，线程A还没执行完，这时候守护线程会执行expire指令，为这把锁“续命”20秒。守护线程从第29秒开始执行，每20秒执行一次。

当线程A执行完任务，会显式关掉守护线程。

另外一种状况，若是节点1 突然断电，因为线程A和守护线程在同一个进程，守护线程也会停下。这把锁到了超时的时候，没人给它续命，也就自动释放了。

 

 memcache实现分布式锁

首页top 10, 由数据库加载到memcache缓存n分钟
微博中名人的content cache, 一旦不存在会大量请求不能命中并加载数据库
须要执行多个IO操做生成的数据存在cache中, 好比查询db屡次
问题
在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db并回设cache，可能会给系统带来潜在的超负荷风险。咱们曾经在线上系统出现过相似故障。

解决方法

 
if (memcache.get(key) == null) {
// 3 min timeout to avoid mutex holder crash
if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
value = db.get(key);
memcache.set(key, value);
memcache.delete(key_mutex);
} else {
 
sleep(50);
retry()；
}
}

在load db以前先add一个mutex key, mutex key add成功以后再去作加载db, 若是add失败则sleep以后重试读取原cache数据。为了防止死锁，mutex key也须要设置过时时间。伪代码以下

Zookeeper实现分布式缓存

Zookeeper的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫作Znode。

Znode分为四种类型：

• 1.持久节点 （PERSISTENT）

默认的节点类型。建立节点的客户端与zookeeper断开链接后，该节点依旧存在 。

• 2.持久节点顺序节点（PERSISTENT_SEQUENTIAL）

所谓顺序节点，就是在建立节点时，Zookeeper根据建立的时间顺序给该节点名称进行编号：

 

 

• 3.临时节点（EPHEMERAL）

和持久节点相反，当建立节点的客户端与zookeeper断开链接后，临时节点会被删除：

 

 

 

• 4.临时顺序节点（EPHEMERAL_SEQUENTIAL）

顾名思义，临时顺序节点结合和临时节点和顺序节点的特色：在建立节点时，Zookeeper根据建立的时间顺序给该节点名称进行编号；当建立节点的客户端与zookeeper断开链接后，临时节点会被删除。

 

Zookeeper分布式锁偏偏应用了临时顺序节点。具体如何实现呢？让咱们来看一看详细步骤：

• 获取锁

首先，在Zookeeper当中建立一个持久节点ParentLock。当第一个客户端想要得到锁时，须要在ParentLock这个节点下面建立一个临时顺序节点 Lock1。

 

以后，Client1查找ParentLock下面全部的临时顺序节点并排序，判断本身所建立的节点Lock1是否是顺序最靠前的一个。若是是第一个节点，则成功得到锁。

 

这时候，若是再有一个客户端 Client2 前来获取锁，则在ParentLock下载再建立一个临时顺序节点Lock2。

 

 

Client2查找ParentLock下面全部的临时顺序节点并排序，判断本身所建立的节点Lock2是否是顺序最靠前的一个，结果发现节点Lock2并非最小的。

因而，Client2向排序仅比它靠前的节点Lock1注册Watcher，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。

 

这时候，若是又有一个客户端Client3前来获取锁，则在ParentLock下载再建立一个临时顺序节点Lock3。

 

 

Client3查找ParentLock下面全部的临时顺序节点并排序，判断本身所建立的节点Lock3是否是顺序最靠前的一个，结果一样发现节点Lock3并非最小的。

因而，Client3向排序仅比它靠前的节点Lock2注册Watcher，用于监听Lock2节点是否存在。这意味着Client3一样抢锁失败，进入了等待状态。

 

这样一来，Client1获得了锁，Client2监听了Lock1，Client3监听了Lock2。这偏偏造成了一个等待队列，很像是Java当中ReentrantLock所依赖的AQS（AbstractQueuedSynchronizer）。

 

• 释放锁

释放锁分为两种状况：

1.任务完成，客户端显示释放

当任务完成时，Client1会显示调用删除节点Lock1的指令。

 

 

2.任务执行过程当中，客户端崩溃

得到锁的Client1在任务执行过程当中，若是Duang的一声崩溃，则会断开与Zookeeper服务端的连接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。

 

因为Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会马上收到通知。这时候Client2会再次查询ParentLock下面的全部节点，确认本身建立的节点Lock2是否是目前最小的节点。若是是最小，则Client2瓜熟蒂落得到了锁。

 

同理，若是Client2也由于任务完成或者节点崩溃而删除了节点Lock2，那么Cient3就会接到通知。

 

最终，Client3成功获得了锁。

 

 

 

Zookeeper和Redis分布式锁的比较

下面的表格总结了Zookeeper和Redis分布式锁的优缺点：