程序员修神之路--redis做分布式锁可能不那么简单

菜哥，复联四上映了，要不要一起去看看？

又想骗我电影票，对不对？

呵呵，想去看了叫我呀

看来你工作不饱和呀

哪有，这两天我刚基于redis写了一个分布式锁，很简单

不管你基于什么做分布式锁，你觉得很简单吗？来来来

在计算机世界里，对于锁大家并不陌生，在现代所有的语言中几乎都提供了语言级别锁的实现，为什么我们的程序有时候会这么依赖锁呢？这个问题还是要从计算机的发展说起，随着计算机硬件的不断升级，多核cpu，多线程，多通道等技术把计算机的计算速度大幅度提升，原来同一时间只能执行一条cpu指令的时代已经过去。随着多条cpu指令可以并行执行的原因，原来不曾出现的资源竞争随着出现，在程序中的体现就是随处可见的多线程环境。比如要更新数据库的一个信息，如果没有并发控制，多个线程同时操作的话，就会出现互相覆盖的现象发生。

锁要解决的就是资源竞争的问题，也就是要把执行的指令顺序化

01为什么需要分布式锁

随着互联网的兴起，现代软件发生了翻天覆地的变化，以前单机的程序，已经支撑不了现代的业务。无论是在抗压，还是在高可用等方面都需要多台计算机协同工作来解决问题。现代的互联网系统都是分布式部署的，分布式部署确实能带来性能和效率上的提升，但为此，我们就需要多解决一个分布式环境下，数据一致性的问题。

当某个资源在多系统之间共享的时候，为了保证大家访问这个资源数据是一致的，那么就必须要求在同一时刻只能被一个客户端处理，不能并发的执行，否者就会出现同一时刻有人写有人读，大家访问到的数据就不一致了。

在分布式系统的时代，传统线程之间的锁机制，就没作用了，系统会有多份并且部署在不同的机器上，这些资源已经不是在线程之间共享了，而是属于进程（服务器）之间共享的资源。

因此，为了解决这个问题，我们就必须引入「分布式锁」。分布式锁，是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。分布式锁的特点如下：

1互斥性和我们本地锁一样互斥性是最基本，但是分布式锁需要保证在不同节点的不同线程的互斥。2可重入性同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁。3锁超时和本地锁一样支持锁超时，防止死锁。4高效，高可用加锁和解锁需要高效，同时也需要保证高可用防止分布式锁失效，可以增加降级。5支持阻塞和非阻塞和 ReentrantLock 一样支持 lock 和 trylock 以及 tryLock(long timeOut)。

02基于redis分布式锁

如果你通过网络搜索分布式锁，最多的就是基于redis的了。基于redis的分布式锁得益于redis的单线程执行机制，单线程在执行上就保证了指令的顺序化，所以很大程度上降低了开发人员的思考设计成本。但是，基于redis做分布式锁难道真的这么容易吗？

1原子操作

基于redis的分布式锁常用命令是

SETNX key value

只在键 key 不存在的情况下，将键 key的值设置为value 。若键key 已经存在，则SETNX 命令不做任何动作。SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。代码示例：

redis> SETNX redislock "redislock"    # redislock 设置成功
(integer) 1
redis> SETNX redislock "redislock2"   # 尝试覆盖 redislock ，失败
(integer) 0
redis> GET redislock                   # 没有被覆盖
"redislock"

成功获取到锁之后，然后设置一个过期时间(这里避免了客户端down掉，锁得不到释放的问题)

redis> expire redislock 5

成功拿到锁的客户端顺利进行自己的业务，业务代码执行完，然后再删除该key

redis> DEL redislock

如果一切都想想象的那么顺利，程序员TMD就不用996了。假如客户端拿到锁之后，执行设置超时指令之前down掉了（现实总是那么悲剧），那这个锁就永远都释放不了.也许你会想到用 Redis 事务来解决。但是这里不行，因为 expire 是依赖于 setnx 的执行结果的，如果 setnx 没抢到锁，expire 是不应该执行的。事务里没有 if-else 分支逻辑，事务的特点是一口气执行，要么全部执行要么一个都不执行。公司几个亿的业务又被你耽误了...

以上情况的出现是因为两个命令并非一个原子性操作，所以在redis 2.8 版本之后出现了新的命令

SETEX key seconds value

所以现在可以利用一条原子性操作的命令来获取锁

redis> SETEX redislock 60 redislock
OK
redis> GET redislock  # 值
"redislock"
redis> TTL redislock  # 剩余生存时间
(integer) 49

2超时问题

在正常的业务当中，当一个线程获取到锁并且设置了锁的过期时间之后，会出现由于业务代码执行时间过长，锁由于到达超时时间自动释放的情况。自动释放之后，其他的线程就会获取到分布式锁，导致业务代码不会串行执行。如果业务上允许这样的情况偶尔发生，那程序员就开干吧，最后顶多人工干预一下，update 一下数据库。

为了避免这类情况发生，在使用redis分布式锁的时候，业务方应尽量避免长时间执行的代码任务。

如果设置锁的超时时间比较长，在一定程度上可以缓解业务代码执行时间长锁自动到期的问题，但是一旦业务代码down掉，其他等待锁的线程等待的时间会比较长，这种情况下，确保获取到锁的程序不会down 成为了主要问题。

3获取锁失败

当锁被一个调用方获取之后，其他调用方在获取锁失败之后，是继续轮询还是直接业务失败呢？如果是继续轮询的话，同步情况下当前线程会一直处于阻塞状态，所以这里轮询的情况还是建议使用异步。

4可重入性

可重入性是指已经拥有锁的客户端再次请求加锁，如果锁支持同一个客户端重复加锁，那么这个锁就是可重入的。如果基于redis的分布式锁要想支持可重入性，需要客户端封装，可以使用threadlocal存储持有锁的信息。这个封装过程会增加代码的复杂度，所以菜菜不推荐这样做。

5redis挂了

如果在多个客户端获取锁的过程中，redis 挂了怎么办呢？假如一个客户端已经获取到了锁，这个时候redis挂了（假如是redis集群），其他的redis服务器会接着提供服务，这个时候其他客户端可以在新的服务器上获取到锁了，这也导致了锁意义的丢失。有兴趣的同学可以去看看RedLock，这种方案以牺牲性能的代价解决了这个问题。

6时钟跳跃问题

在某些时候，redis的服务器时间发生的跳跃，由于锁的过期时间依赖于服务器时间，所以也会出现两个客户端同时获取到锁的情况发生。