一、为什么需要分布式锁
随着互联网的兴起，现代软件发生了翻天覆地的变化，以前单机的程序，已经支撑不了现代的业务。无论是在抗压，还是在高可用等方面都需要多台计算机协同工作来解决问题。现代的互联网系统都是分布式部署的，分布式部署确实能带来性能和效率上的提升，但为此，我们就需要多解决一个分布式环境下，数据一致性的问题。
当某个资源在多系统之间共享的时候，为了保证大家访问这个资源数据是一致的，那么就必须要求在同一时刻只能被一个客户端处理，不能并发的执行，否者就会出现同一时刻有人写有人读，大家访问到的数据就不一致了。
在分布式系统的时代，传统线程之间的锁机制，就没作用了，系统会有多份并且部署在不同的机器上，这些资源已经不是在线程之间共享了，而是属于进程（服务器）之间共享的资源。
因此，为了解决这个问题，我们就必须引入「分布式锁」。分布式锁，是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。分布式锁的特点如下：
1、互斥性
和我们本地锁一样互斥性是最基本，但是分布式锁需要保证在不同节点的不同线程的互斥。
2、可重入性
同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁。
3、锁超时
和本地锁一样支持锁超时，防止死锁。
4、高效，高可用
加锁和解锁需要高效，同时也需要保证高可用防止分布式锁失效，可以增加降级。
5、支持阻塞和非阻塞
和 ReentrantLock 一样支持 lock 和 trylock 以及 tryLock(long timeOut)。
二、基于redis分布式锁
如果你通过网络搜索分布式锁，最多的就是基于redis的了。基于redis的分布式锁得益于redis的单线程执行机制，单线程在执行上就保证了指令的顺序化，所以很大程度上降低了开发人员的思考设计成本。但是，基于redis做分布式锁难道真的这么容易吗？
1、原子操作
基于redis的分布式锁常用命令是
SETNX key value
只在键 key 不存在的情况下，将键 key的值设置为value 。若键key 已经存在， 则SETNX 命令不做任何动作。SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。代码示例：
成功获取到锁之后，然后设置一个过期时间(这里避免了客户端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
所以现在可以利用一条原子性操作的命令来获取锁
2、超时问题
在正常的业务当中，当一个线程获取到锁并且设置了锁的过期时间之后，会出现由于业务代码执行时间过长，锁由于到达超时时间自动释放的情况。自动释放之后，其他的线程就会获取到分布式锁，导致业务代码不会串行执行。如果业务上允许这样的情况偶尔发生，那程序员就开干吧，最后顶多人工干预一下，update 一下数据库。
为了避免这类情况发生，在使用redis分布式锁的时候，业务方应尽量避免长时间执行的代码任务。
如果设置锁的超时时间比较长，在一定程度上可以缓解业务代码执行时间长锁自动到期的问题，但是一旦业务代码down掉，其他等待锁的线程等待的时间会比较长，这种情况下，确保获取到锁的程序不会down 成为了主要问题。
3、获取锁失败
当锁被一个调用方获取之后，其他调用方在获取锁失败之后，是继续轮询还是直接业务失败呢？如果是继续轮询的话，同步情况下当前线程会一直处于阻塞状态，所以这里轮询的情况还是建议使用异步。
4、可重入性
可重入性是指已经拥有锁的客户端再次请求加锁，如果锁支持同一个客户端重复加锁，那么这个锁就是可重入的。如果基于redis的分布式锁要想支持可重入性，需要客户端封装，可以使用threadlocal存储持有锁的信息。这个封装过程会增加代码的复杂度，所以菜菜不推荐这样做。
5、redis挂了
如果在多个客户端获取锁的过程中，redis 挂了怎么办呢？假如一个客户端已经获取到了锁，这个时候redis挂了（假如是redis集群），其他的redis服务器会接着提供服务，这个时候其他客户端可以在新的服务器上获取到锁了，这也导致了锁意义的丢失。有兴趣的同学可以去看看RedLock，这种方案以牺牲性能的代价解决了这个问题。
6、时钟跳跃问题
在某些时候，redis的服务器时间发生的跳跃，由于锁的过期时间依赖于服务器时间，所以也会出现两个客户端同时获取到锁的情况发生。
分布式锁在很多场景中是非常有用的原语， 不同的进程必须以独占资源的方式实现资源共享就是一个典型的例子。
有很多分布式锁的库和描述怎么实现分布式锁管理器(DLM)的博客,但是每个库的实现方式都不太一样，很多库的实现方式为了简单降低了可靠性，而有的使用了稍微复杂的设计。
这个页面试图提供一个使用Redis实现分布式锁的规范算法。我们提出一种算法，叫Redlock,我们认为这种实现比普通的单实例实现更安全,我们希望redis社区能帮助分析一下这种实现方法，并给我们提供反馈。
安全和活性失效保障
按照我们的思路和设计方案，算法只需具备3个特性就可以实现一个最低保障的分布式锁。
- 安全属性(Safety property): 独享(相互排斥)。在任意一个时刻，只有一个客户端持有锁。
- 活性A(Liveness property A): 无死锁。即便持有锁的客户端崩溃(crashed)或者网络被分裂(gets partitioned)，锁仍然可以被获取。
- 活性B(Liveness property B): 容错。 只要大部分Redis节点都活着，客户端就可以获取和释放锁.
为什么基于故障转移的实现还不够
为了更好的理解我们想要改进的方面，我们先分析一下当前大多数基于Redis的分布式锁现状和实现方法.
实现Redis分布式锁的最简单的方法就是在Redis中创建一个key，这个key有一个失效时间(TTL)，以保证锁最终会被自动释放掉(这个对应特性2)。当客户端释放资源(解锁)的时候，会删除掉这个key。
从表面上看，似乎效果还不错，但是这里有一个问题：这个架构中存在一个严重的单点失败问题。如果Redis挂了怎么办？你可能会说，可以通过增加一个slave节点解决这个问题。但这通常是行不通的。这样做，我们不能实现资源的独享,因为Redis的主从同步通常是异步的。
在这种场景(主从结构)中存在明显的竞态:
- 客户端A从master获取到锁
- 在master将锁同步到slave之前，master宕掉了。
- slave节点被晋级为master节点
- 客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。安全失效！
有时候程序就是这么巧，比如说正好一个节点挂掉的时候，多个客户端同时取到了锁。如果你可以接受这种小概率错误，那用这个基于复制的方案就完全没有问题。否则的话，我们建议你实现下面描述的解决方案。
单Redis实例实现分布式锁的正确方法
在尝试克服上述单实例设置的限制之前，让我们先讨论一下在这种简单情况下实现分布式锁的正确做法，实际上这是一种可行的方案，尽管存在竞态，结果仍然是可接受的，另外，这里讨论的单实例加锁方法也是分布式加锁算法的基础。
获取锁使用命令:
SET resource_name my_random_value NX PX 30000这个命令仅在不存在key的时候才能被执行成功(NX选项)，并且这个key有一个30秒的自动失效时间(PX属性)。这个key的值是“my_random_value”(一个随机值)，这个值在所有的客户端必须是唯一的，所有同一key的获取者(竞争者)这个值都不能一样。
value的值必须是随机数主要是为了更安全的释放锁，释放锁的时候使用脚本告诉Redis:只有key存在并且存储的值和我指定的值一样才能告诉我删除成功。可以通过以下Lua脚本实现：
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end使用这种方式释放锁可以避免删除别的客户端获取成功的锁。举个例子：客户端A取得资源锁，但是紧接着被一个其他操作阻塞了，当客户端A运行完毕其他操作后要释放锁时，原来的锁早已超时并且被Redis自动释放，并且在这期间资源锁又被客户端B再次获取到。如果仅使用DEL命令将key删除，那么这种情况就会把客户端B的锁给删除掉。使用Lua脚本就不会存在这种情况，因为脚本仅会删除value等于客户端A的value的key(value相当于客户端的一个签名)。
这个随机字符串应该怎么设置？我认为它应该是从/dev/urandom产生的一个20字节随机数，但是我想你可以找到比这种方法代价更小的方法，只要这个数在你的任务中是唯一的就行。例如一种安全可行的方法是使用/dev/urandom作为RC4的种子和源产生一个伪随机流;一种更简单的方法是把以毫秒为单位的unix时间和客户端ID拼接起来，理论上不是完全安全，但是在多数情况下可以满足需求.
key的失效时间，被称作“锁定有效期”。它不仅是key自动失效时间，而且还是一个客户端持有锁多长时间后可以被另外一个客户端重新获得。
截至到目前，我们已经有较好的方法获取锁和释放锁。基于Redis单实例，假设这个单实例总是可用，这种方法已经足够安全。现在让我们扩展一下，假设Redis没有总是可用的保障。
Redlock算法
在Redis的分布式环境中，我们假设有N个Redis master。这些节点完全互相独立，不存在主从复制或者其他集群协调机制。之前我们已经描述了在Redis单实例下怎么安全地获取和释放锁。我们确保将在每(N)个实例上使用此方法获取和释放锁。在这个样例中，我们假设有5个Redis master节点，这是一个比较合理的设置，所以我们需要在5台机器上面或者5台虚拟机上面运行这些实例，这样保证他们不会同时都宕掉。
为了取到锁，客户端应该执行以下操作:
- 获取当前Unix时间，以毫秒为单位。
- 依次尝试从N个实例，使用相同的key和随机值获取锁。在步骤2，当向Redis设置锁时,客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试另外一个Redis实例。
- 客户端使用当前时间减去开始获取锁时间(步骤1记录的时间)就得到获取锁使用的时间。当且仅当从大多数(这里是3个节点)的Redis节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。
- 如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间(步骤3计算的结果)。
- 如果因为某些原因，获取锁失败(没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间)，客户端应该在所有的Redis实例上进行解锁(即便某些Redis实例根本就没有加锁成功)。
这个算法是异步的么?
算法基于这样一个假设：虽然多个进程之间没有时钟同步，但每个进程都以相同的时钟频率前进，时间差相对于失效时间来说几乎可以忽略不计。这种假设和我们的真实世界非常接近：每个计算机都有一个本地时钟，我们可以容忍多个计算机之间有较小的时钟漂移。
从这点来说，我们必须再次强调我们的互相排斥规则：只有在锁的有效时间(在步骤3计算的结果)范围内客户端能够做完它的工作，锁的安全性才能得到保证(锁的实际有效时间通常要比设置的短，因为计算机之间有时钟漂移的现象)。.
失败时重试
当客户端无法取到锁时，应该在一个随机延迟后重试,防止多个客户端在同时抢夺同一资源的锁(这样会导致脑裂，没有人会取到锁)。同样，客户端取得大部分Redis实例锁所花费的时间越短，脑裂出现的概率就会越低(必要的重试)，所以，理想情况一下，客户端应该同时(并发地)向所有Redis发送SET命令。
需要强调，当客户端从大多数Redis实例获取锁失败时，应该尽快地释放(部分)已经成功取到的锁，这样其他的客户端就不必非得等到锁过完“有效时间”才能取到(然而，如果已经存在网络分裂，客户端已经无法和Redis实例通信，此时就只能等待key的自动释放了，等于被惩罚了)。
释放锁
释放锁比较简单，向所有的Redis实例发送释放锁命令即可，不用关心之前有没有从Redis实例成功获取到锁.
安全争议
这个算法安全么？我们可以从不同的场景讨论一下。
让我们假设客户端从大多数Redis实例取到了锁。所有的实例都包含同样的key，并且key的有效时间也一样。然而，key肯定是在不同的时间被设置上的，所以key的失效时间也不是精确的相同。我们假设第一个设置的key时间是T1(开始向第一个server发送命令前时间)，最后一个设置的key时间是T2(得到最后一台server的答复后的时间)，我们可以确认，第一个server的key至少会存活 MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT。所有其他的key的存活时间，都会比这个key时间晚，所以可以肯定，所有key的失效时间至少是MIN_VALIDITY。
当大部分实例的key被设置后，其他的客户端将不能再取到锁，因为至少N/2+1个实例已经存在key。所以，如果一个锁被(客户端)获取后，客户端自己也不能再次申请到锁(违反互相排斥属性)。
然而我们也想确保，当多个客户端同时抢夺一个锁时不能两个都成功。
如果客户端在获取到大多数redis实例锁，使用的时间接近或者已经大于失效时间，客户端将认为锁是失效的锁，并且将释放掉已经获取到的锁，所以我们只需要在有效时间范围内获取到大部分锁这种情况。在上面已经讨论过有争议的地方，在MIN_VALIDITY时间内，将没有客户端再次取得锁。所以只有一种情况，多个客户端会在相同时间取得N/2+1实例的锁，那就是取得锁的时间大于失效时间(TTL time)，这样取到的锁也是无效的.
如果你能提供关于现有的类似算法的一个正式证明(指出正确性)，或者是发现这个算法的bug？ 我们将非常感激.
活性争议
系统的活性安全基于三个主要特性:
- 锁的自动释放(因为key失效了)：最终锁可以再次被使用.
- 客户端通常会将没有获取到的锁删除，或者锁被取到后，使用完后，客户端会主动(提前)释放锁，而不是等到锁失效另外的客户端才能取到锁。.
- 当客户端重试获取锁时，需要等待一段时间，这个时间必须大于从大多数Redis实例成功获取锁使用的时间，以最大限度地避免脑裂。.
然而，当网络出现问题时系统在失效时间(TTL)内就无法服务，这种情况下我们的程序就会为此付出代价。如果网络持续的有问题，可能就会出现死循环了。 这种情况发生在当客户端刚取到一个锁还没有来得及释放锁就被网络隔离.
如果网络一直没有恢复，这个算法会导致系统不可用.
性能，崩溃恢复和Redis同步
很多用户把Redis当做分布式锁服务器，使用获取锁和释放锁的响应时间，每秒钟可用执行多少次 acquire / release 操作作为性能指标。为了达到这一要求，增加Redis实例当然可用降低响应延迟(没有钱买硬件的”穷人”,也可以在网络方面做优化，使用非阻塞模型，一次发送所有的命令，然后异步的读取响应结果，假设客户端和redis服务器之间的RTT都差不多。
然而，如果我们想使用可以从备份中恢复的redis模式，有另外一种持久化情况你需要考虑，.
我们考虑这样一种场景，假设我们的redis没用使用备份。一个客户端获取到了3个实例的锁。此时，其中一个已经被客户端取到锁的redis实例被重启，在这个时间点，就可能出现3个节点没有设置锁，此时如果有另外一个客户端来设置锁，锁就可能被再次获取到，这样锁的互相排斥的特性就被破坏掉了。
如果我们启用了AOF持久化，情况会好很多。我们可用使用SHUTDOWN命令关闭然后再次重启。因为Redis到期是语义上实现的，所以当服务器关闭时，实际上还是经过了时间，所有(保持锁)需要的条件都没有受到影响. 没有受到影响的前提是redis优雅的关闭。停电了怎么办？如果redis是每秒执行一次fsync，那么很有可能在redis重启之后，key已经丢弃。理论上，如果我们想在Redis重启地任何情况下都保证锁的安全，我们必须开启fsync=always的配置。这反过来将完全破坏与传统上用于以安全的方式实现分布式锁的同一级别的CP系统的性能.
然而情况总比一开始想象的好一些。当一个redis节点重启后，只要它不参与到任意当前活动的锁，没有被当做“当前存活”节点被客户端重新获取到,算法的安全性仍然是有保障的。
为了达到这种效果，我们只需要将新的redis实例，在一个TTL时间内，对客户端不可用即可，在这个时间内，所有客户端锁将被失效或者自动释放.
使用延迟重启可以在不采用持久化策略的情况下达到同样的安全，然而这样做有时会让系统转化为彻底不可用。比如大部分的redis实例都崩溃了，系统在TTL时间内任何锁都将无法加锁成功。
使算法更加可靠：锁的扩展
如果你的工作可以拆分为许多小步骤，可以将有效时间设置的小一些，使用锁的一些扩展机制。在工作进行的过程中，当发现锁剩下的有效时间很短时，可以再次向redis的所有实例发送一个Lua脚本，让key的有效时间延长一点(前提还是key存在并且value是之前设置的value)。
客户端扩展TTL时必须像首次取得锁一样在大多数实例上扩展成功才算再次取到锁，并且是在有效时间内再次取到锁(算法和获取锁是非常相似的)。
这样做从技术上将并不会改变算法的正确性，所以扩展锁的过程中仍然需要达到获取到N/2+1个实例这个要求，否则活性特性之一就会失效。
看一看释放锁的方法,面试过程中很多候选人童鞋说直接调用delete方法,我们写一段代码,然后分析一下直接调用delete方法的问题:
如上一段代码,假设一种极端场景下有两个线程A和B,A线程先获取锁,设置过期时间为10秒,然后A线程执行释放锁操作,执行到if判断语句并且成功进入时,此时耗时刚好10秒,锁过期了,并且CPU分配给A线程的时间片刚好用完,此时B线程开始执行并且成功获取到该分布式锁,然后执行一段时间后B线程的时间片用完,此时A继续执行删除操作,此时A删除的就是B线程的锁,会造成误删除操作,因此为了避免这种情况,我们需要一种机制来保证判断和删除操作的原子性,redis官方推荐我们使用lua脚本,因此正确的解锁方式如下:
其中的UNLOCK_LUA_SCRIPT如下:
redis使用lua脚本能保证该操作的原子性,因此这样才能正确释放分布式锁.这也回答了为什么之前说释放锁的时候直接调用delete方法是错误的.
有什么问题?
在上文中,我们使用redis构建了一个分布式锁,但是请注意,该代码在单机环境下没有任何问题,但是我们在生产中往往都是redis集群部署,由于redis主从节点的数据同步是异步的,如果Redis的master节点在锁未同步到Slave节点的时候宕机了怎么办？举例来说:
1.进程A在master节点获得了锁。
2.在锁同步到slave之前，master宕机，数据还没有同步到slave
3.slave变成了新的master节点
4.进程B也得到了和A相同的锁.
因此,如果你的业务允许在master宕机期间，多个客户端允许同时都持有锁,那如上的分布式锁是可以接受的,否则就不能使用上述的分布式锁,在这种情况下,redis官方为我们提供了另一种解决方案----RedLock算法.
RedLock算法
假设我们有N个Master节点(N一般为奇数),这些节点互相之间相互独立,不需要进行数据同步,我们用在单节点获取和释放锁的方式来操纵这些节点,具体过程为:
1.获取当前时间(单位是毫秒)。
2.轮流用相同的key和随机值在N个节点上请求锁，在这一步里，客户端在每个master上请求锁时，会有一个和总的锁释放时间相比小的多的超时时间。比如如果锁自动释放时间是10秒钟，那每个节点锁请求的超时时间可能是5-50毫秒的范围，这个可以防止一个客户端在某个宕掉的master节点上阻塞过长时间，如果一个master节点不可用了，我们应该尽快尝试下一个master节点。
3.客户端计算第二步中获取锁所花的时间，只有当客户端在大多数master节点上成功获取了锁（N/2+1在这里是3个），而且总共消耗的时间不超过锁释放时间，这个锁就认为是获取成功了。
4.如果锁获取成功了，那现在锁自动释放时间就是最初的锁释放时间减去之前获取锁所消耗的时间。
5.如果锁获取失败了，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁，即便是那些他认为没有获取成功的锁。
有关RedLock的算法,可以详见官网文档
RedLock算法是否真的足够安全?
要回答这个问题,可以看看国外大神Martin Kleppmann在他的一篇文章How to do distributed locking中详细描述了为什么他认为RedLock仍然是不安全的,简单来说,RedLock最大的弊端有两个:
1.进程由于各种原因pause,类似于上文说的多线程间的时间片切换,比如由于GC停顿等导致锁过期,但是进程并未感知到,同时另一个进程已经获取了该分布式锁,就会导致奇怪的结果发生.
2.算法对时钟依赖性太强,假设N个节点为5,按照超过一半的原则,假设进程X成功获取了A/B/C三个节点的锁,此时认为X获取锁成功,此时X在TTL时间段内没有执行完成,锁到期自动释放,此时由于C节点的时间比A/B节点快,导致C节点先释放锁,此时Y节点获取了C/D/E三个节点的锁,又导致两个进程获取了同一个锁.
无论如何,在多master节点的情况下,没有任何方案能完美保证RedLock的绝对安全,因此,我们在使用redis分布式锁的时候一定要弄清楚我们的目的是什么?一般来说,有两种情况:
1.为了提高性能.比如持有该锁使我们的程序不会进行重复的计算,在这种情况下,如果锁失败了我们付出的代价仅仅是进行了重复的计算,不会影响我们的业务结果.
2.为了保证业务的正确性.比如我们是一个银行系统,为了保证转账操作扣款唯一性,拥有该锁可以确保我们的扣款操作的唯一性,如果锁失效,会导致多次扣款,这是无法接受的.
如果我们是为了提升性能,那没有必要使用RedLock算法,它成本高(假设需要5个master节点,这些节点还要保证高可用,则需要更多的节点)且又复杂,不如使用在单机情况下的分布式锁,前提是你的业务能容忍我们上述说的宕机期间相同锁的问题.
如果是为了保证业务的正确性,我们说了RedLock也不能完美保证绝对安全,因此也不能放心的使用RedLock.
总结
总而言之,使用Redis分布式锁实在不是一个好的选择,Redis设计的初衷也并不是满足分布式锁的需求.对于需求性能的分布式锁应用它太重了且成本高;对于需求正确性的应用来说它不够安全.如果你的应用只需要高性能的分布式锁并且不要求多高的正确性,那么单节点的Redis分布式锁足够了;如果你的应用想要保证正确性,那么不建议 RedLock,建议使用一个合适的一致性协调系统,比如基于Zookeeper的分布式锁!