redis：单机分布式锁实现以及可能遇到的问题

缺乏、安全感 2022-09-14 14:20 282阅读 0赞

在分布式系统中，当不同进程或者线程一起访问共享资源时，会造成资源争抢，如果不加以控制的话，就会引发程序错乱。此时用分布式锁能够非常有效的解决这个问题，它采用了一种互斥的机制来放置线程或进程之间相互干扰，从而保证了数据的一致性

# redis分布式锁介绍 #

分布式锁并非是redis独有，比如mysql关系型数据库，以及zookeeper分布式服务应用，它们都实现了分布式锁，只不过redis是基于缓存实现的。

redis分布式锁有很多应用场景，举个简单的例子，比如春运时，您需要在 12306 上抢购回家火车票，但 Redis 数据库中只剩一张票了，此时有多个用户来预订购买，那么这张票会被谁抢走呢？redis服务器又是如何处理这种情景呢？在这个过程就需要使用分布式锁

redis分布式锁主要有如下特点：

*  互斥性是分布式锁的重要特点，**在任意时刻，只有一个线程能够持有锁**
 *  锁的超时时间，一个线程在持锁期间挂掉了而没主动释放锁，此时通过超时时间来保证该线程在超时后可以释放锁，这样其他线程才可以继续获取锁；
 *  **加锁和解锁必须是由同一个线程来设置**

> 注意：一个线程代表一个客户端。

Redis 是缓存型数据库，拥有很高的性能，因此加锁和释放锁开销较小，并且能够很轻易地实现分布式锁。

# Redis分布式锁命令 #

分布式锁的本质其实就是要在 Redis 里面占一个“坑”，当别的进程也要来占时，发现已经有人蹲了，就只好放弃或者稍做等待。

## 占坑（SETNX 和 EXPIRE 非原子性） ##

占坑一般使用`setnx`指令，只允许被一个客户端占坑。先来先占，用完了，再调用`del`指令释放“坑”

127.0.0.1:6379> setnx lock:codehole true
    (integer) 1
    127.0.0.1:6379> expire lock:codehole 5
    (integer) 1
    // ---- do sonmething ---
    127.0.0.1:6379> del lock:codehole

但是上面逻辑还是会有问题，如下图，如果在setnx和expire之间服务器进程突然死掉了，就会导致expire得不到执行，导致死锁  
![在这里插入图片描述][4af6712685564fdcbcd78c29a5db2793.png]  
这个问题的根源在于setnx和expire的两条指令不是原子指令。如果这两条指令可以一起执行就不会出现问题。为此在redis2.8版本中引入了set 指令的参数，使得setnx和expire指令可以一起执行

127.0.0.1:6379> set lock:codehole true ex 5 nx
    
    (integer) 1
    
    // ---- do sonmething ---
    127.0.0.1:6379> del lock:codehole

## 锁误解除 ##

> 问题

如果线程 A 成功获取到了锁，并且设置了过期时间 30 秒，但线程 A 执行时间超过了 30 秒，锁过期自动释放，此时线程 B 获取到了锁；随后 A 执行完成，线程 A 使用 DEL 命令来释放锁，但此时线程 B 加的锁还没有执行完成，线程 A 实际释放的线程 B 加的锁。

> 解决

*  在del释放锁之前加一个判断，验证当前的锁是不是自己加的锁。
 *  具体在加锁的时候把当前线程的id当做value，可生成一个 UUID 标识当前线程，在删除之前验证key对应的value是不是自己线程的id。
 *  还可以使用 lua 脚本做验证标识和解锁操作。

tag = random.nextint()   $ 随机数
    if redis.set(key, tag, nx = true, ex = 5):
    	do_something();
    	redis.delifequals(key, tag);

*  将set指令的value参数设置一个随机数，释放时先匹配随机数是否一致，然后再删除key，这是为了确保当前线程占有的锁不会被其他线程是否，除非这个锁是因为过期了而被服务器自动释放的。

*  但是匹配value和删除key不是一个原子操作，redis也没有提供类似于delifequals这样的指令，这就需要Lua脚本来处理了，因为Lua脚本可以保证连续多个指令的原子执行

## 超时解锁导致并发 ##

> 问题

*  redis的分布式锁不能解决超时问题，如果在加锁和释放锁之间的逻辑执行得太长，以至于超出了锁的超时限制，就会出现问题。
 *  因为这个时候第一个线程持有的锁过期了，临界区的逻辑还没有执行完，而同时第二个线程就提前持有了这把锁，导致临界区的代码不能得到严格的串行执行

> 解决

1.  将过期时间设置得足够长，确保代码逻辑能够在锁释放之前能够执行完成
2.  为获取锁的线程增加守护进程，为将要过期但没有是否的锁增加有效时间
3.  **redis分布式不要用于较长时间的任务**。如果真的偶尔出现了问题，造成的数据小错乱可能需要人工介入解决

## 可重入性 ##

> 问题

可重入性是指线程在持有锁的情况下再次请求加锁，如果一个锁支持同一个线程的多次加锁，那么这个锁就是可重入的。

> 解决

redis分布式锁如果要支持可冲入，需要对客户端的set方法进行包装，使用线程的ThreadLocal变量存储当前持有锁的计数

Redis 可通过对锁进行重入计数，加锁时加 1，解锁时减 1，当计数归 0 时释放锁。

> 建议

**不推荐**使用可冲入锁，它加重了客户端的复杂性，在编写业务方法的时候注意逻辑结构进行调整完全可以不使用可重入锁

## 无法等待锁释放 ##

> 问题

上述命令执行都是立即返回的，如果客户端可以等待锁释放就无法使用。

1.  可以通过客户端轮询的方式解决该问题，当未获取到锁时，等待一段时间重新获取锁，直到成功获取锁或等待超时。这种方式比较消耗服务器资源，当并发量比较大时，会影响服务器的效率。
2.  另一种方式是使用 Redis 的发布订阅功能，当获取锁失败时，订阅锁释放消息，获取锁成功后释放时，发送锁释放消息。

## 客户端加锁失败怎么办 ##

如果客户端在处理请求时加锁没加成功怎么办？一般有三种策略

*  直接抛出异常，通知用户稍后重试
 *  sleep一会儿，然后再重试
 *  将请求转移到延迟队列，过一会儿再试

（1）直接抛出特定类型的异常

*  这种方式比较适合由用户直接发起的请求。
 *  用户看到错误对话框之后，会先阅读对话框的内容，在点击重试，这样就可以起到人工延迟的效果
 *  如果考虑到用户体验，可以由前端的代码替代用户来进行延迟控制控制
 *  它本质是对当前请求的放弃，有用户决定是否重新发起新的请求

（2）sleep

*  sleep会阻塞当前的消息处理线程，会导致队列的后继消息处理出现延迟
 *  如果碰撞得比较频繁或者队列里消息比较大，sleep可能并不何时
 *  如果因为个别死锁的key导致加锁不成功，线程会彻底堵死，导致后继消息永远得不到及时处理

（3） 延迟队列

*  这种方法比较适合异步消息处理，将当前冲突的请求扔到另一个队列延后处理以避开冲突

[4af6712685564fdcbcd78c29a5db2793.png]: /images/20220828/e0d82a6dd9c64b2cbcacb94df3aa3248.png