Redis分布式锁专题

谈起redis锁，下面三个，算是出现最多的高频词汇：

• setnx
• redLock
• redisson

setnx

想要实现分布式锁，必须要求Redis有互斥的能力。可以使用SETNX命令，其含义是SET IF NOT EXIST，即如果key不存在，才会设置它的值，否则什么也不做。两个客户端进程可以执行这个命令，达到互斥，就可以实现一个分布式锁。

其实目前通常所说的setnx命令，并非单指redis的setnx key value这条命令。

一般代指redis中对set命令加上nx参数进行使用， set这个命令，目前已经支持这么多参数可选：

SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL]

// 加锁 SETNX lock_key 1

// 业务逻辑 DO THINGS

// 释放锁 DEL lock_key

主要依托了它的key不存在才能set成功的特性，进程A拿到锁，在没有删除锁的Key时，进程B自然获取锁就失败了。

那么为什么要使用PX 30000去设置一个超时时间？因为这两条命令如果不能保证是原子操作，就有潜在的风险导致过期时间设置失败，依旧有可能发生死锁问题。幸好在Redis 2.6.12之后，Redis扩展了SET命令的参数，可以在SET的同时指定EXPIRE时间，这条操作是原子的

是怕进程A不讲道理啊，锁没等释放呢，万一崩了，直接原地把锁带走了，导致系统中谁也拿不到锁。

就算这样，还是不能保证万无一失。

如果进程A又不讲道理，操作锁内资源超过笔者设置的超时时间，那么就会导致其他进程拿到锁，等进程A回来了，回手就是把其他进程的锁删了

所以在用setnx的时候，key虽然是主要作用，但是value也不能闲着，可以设置一个唯一的客户端ID，或者用UUID这种随机数。

删除锁的正确姿势之一，就是可以使用lua脚本，通过redis的eval/evalsha命令来运行。

为什么现在的setnx默认是指set命令带上nx参数，而不是直接说是setnx这个命令。

因为redis版本在2.6.12之前，set是不支持nx参数的，如果想要完成一个锁，那么需要两条命令：

1. setnx Test uuid
2. expire Test 30

即放入Key和设置有效期，是分开的两步，理论上会出现1刚执行完，程序挂掉，无法保证原子性。

但是早在2013年，也就是7年前，Redis就发布了2.6.12版本，并且官网(set命令页)，也早早就说明了“SETNX, SETEX, PSETEX可能在未来的版本中，会弃用并永久删除”。

如何确定锁的过期时间

前面提到过，过期时间如果评估得不好，这个锁就会有提前过期的风险，一种妥协的解决方案是，尽量冗余过期时间，降低锁提前过期的概率，但这个方案并不能完美解决问题。是否可以设置这样的方案，加锁时，先设置一个预估的过期时间，然后开启一个守护线程，定时去检测这个锁的失效时间，如果锁快要过期了，操作共享资源还未完成，那么就自动对锁进行续期，重新设置过期时间。

 

redisson

Redisson是java的redis客户端之一，提供了一些api方便操作redis。

redisson帮我们搞了分布式的版本，比如AtomicLong，直接用RedissonAtomicLong就行了，连类名都不用去新记，很人性化了。

锁只是它的冰山一角，并且从它的wiki页面看到，对主从，哨兵，集群等模式都支持，当然了，单节点模式肯定是支持的。

本文还是以锁为主，其他的不过多介绍。

Redisson普通的锁实现源码主要是RedissonLock这个类，还没有看过它源码的盆友，不妨去瞧一瞧。

源码中加锁/释放锁操作都是用lua脚本完成的，封装的非常完善，开箱即用。

RedLock

redLock的中文是直译过来的，就叫红锁。

红锁并非是一个工具，而是redis官方提出的一种分布式锁的算法。

就在刚刚介绍完的redisson中，就实现了redLock版本的锁。也就是说除了getLock方法，还有getRedLock方法。

redLock算法虽然是需要多个实例，但是这些实例都是独自部署的，没有主从关系。RedLock作者指出，之所以要用独立的，是避免了redis异步复制造成的锁丢失，比如：主节点没来的及把刚刚set进来这条数据给从节点，就挂了。

红锁算法认为，只要2N + 1个节点加锁成功，那么就认为获取了锁， 解锁时将所有实例解锁。 流程为：

1. 顺序向五个节点请求加锁
2. 根据一定的超时时间来推断是不是跳过该节点
3. 三个节点加锁成功并且花费时间小于锁的有效期
4. 认定加锁成功

也就是说，假设锁30秒过期，三个节点加锁花了31秒，自然是加锁失败了。

这只是举个例子，实际上并不应该等每个节点那么长时间，就像官网所说的那样，假设有效期是10秒，那么单个redis实例操作超时时间，应该在5到50毫秒(注意时间单位)

还是假设我们设置有效期是30秒，图中超时了两个redis节点。 那么加锁成功的节点总共花费了3秒，所以锁的实际有效期是小于27秒的。

即扣除加锁成功三个实例的3秒，还要扣除等待超时redis实例的总共时间。