redis分布式锁
单机版本
为什么要使用锁？
第一个是正确性，这个众人皆知。就像Java里的synchronize，就是用来保证多线程并发场景下，程序的正确性。JVM里需要保证并发访问的正确性，在分布式系统里面，也同样需要，只不过并发访问的单位，不再是线程，而是进程。
举个例子，一个文件系统，为了提高性能，部署了三台文件服务器。
当服务器A在修改文件A的时候，其他服务器就不能对文件A进行修改，否则A的修改就会被覆盖掉。
锁还有第二个用处——效率。比如应用A有一个耗时的统计任务，每天凌晨两点，定时执行，这时我们给应用A部署了三台机器，如果不加锁，那么每天凌晨两点一到，这三台机器就都会去执行这个很耗时的统计任务，而实际上，我们最后只需要一份统计结果。这时候，就可以在定时任务开始前，先去获取锁，获取到锁的，执行统计任务，获取不到的，该干嘛干嘛去。
分布式锁和本地锁的区别？
就像上面说的，单机，并发的单位是线程，分布式，并发的单位是多进程。
并发单位的等级上去了，锁的等级自然也得上去。
以前锁是进程自己的，进程下的线程都看这个锁的眼色行事，谁拿到锁，谁才可以放行。
进程外面还有别的进程，你要跟别人合作，就不能光看着自己了，得有一个大家都看得到的，光明正大的地方，来放这把锁。有不少适合放这把锁的地方，redis、zookeeper、etcd等等
获取锁
要怎么在redis里获取一把锁？
很简单，执行set命令就好了，还是上面文件系统的例子，比如你想修改文件id是9527的文件，那就往redis里，添加一个key为file：9257，value为任意字符串的值即可：
set成功了，就说明获取到锁。
这样可以吗？很明显不行，set方法默认是会覆盖的，也就是说，就算file:9527已经有值了，set还是可以成功，这样锁就起不到互斥的作用。
那在set之前，先用get判断一下，如果是null，再去set？
也不行，原因很简单，get和set都在客户端执行，不具有原子性。
要实现原子性，唯一的办法，就是只给redis发送一条命令，来完成获取锁的动作。
于是就有了下面这条命令：
NX=If Not Existed
如果不存在，才执行set
完美了吗？非也，这个值没有设置过期时间，如果后面获得锁的客户端，因为挂掉了，或者其他原因，没有释放锁，那其他进程也都获取不到锁了，结果就是死锁。
所以有了终极版的获取锁命令：
使用EX参数，可以设置过期时间，单位是秒，另一个参数PX，也可以设置过期时间，单位是毫秒。
上述的命令会拆解成两条命令，一条set设置值，一条expire设置过期时间，所以实际上，服务端还是分两次执行这条命令，所以还是不满足原子性。
然而，redis是单线程处理命令的，所以，在redis执行这段函数的过程中，不可能有精力去执行其他函数，所以，就算是分成两个动作去执行，也不影响。
释放锁
最后再来看看释放锁。
有人说，释放锁，简单，直接del：
有问题吗？当然有，这会把别人的锁给释放掉。
举个例子：
-
A拿到了锁，过期时间5s
-
5s过去了，A还没释放锁，也许是发生了GC，也许是某个耗时操作。
-
锁过期了，B抢到了锁
- A缓过神来了，以为锁还是自己的，执行del file:9527
- C抢到了锁，也进来了
-
B看看屋里的C，有看看刚出门的A，对着A吼了一句：尼玛，你干嘛把我的锁释放了
所以，为了防止把别人的锁释放了，必须检查一下，当前的value是不是自己设置进去的value，如果不是，就说明锁不是自己的了，不能释放。
显然，这个过程，如果放在客户端做，就又不满足原子性了，只能整在一起，一次性让redis server执行完。
这下redis可没有一条命令，可以做这么多事情的，好在redis提供了lua脚本的调用方式，只需使用eval命令调用以下脚本即可：
那么redis在执行lua脚本时，是原子的吗？答案当然是肯定的：
单机版实现的局限性
大多数生产环境，都不可能只部署一个Redis，至少是主从架构：
更多的是主从+分片的架构
当然主从架构也可以进化为一主多架构乃至主从链架构（Master-Salve Chain）：
而其实在主从架构下，之前那套分布式锁的机制，就已经失效了，原因正如之前说的：
Redloc算法
针对Redis集群架构，redis的作者antirez提出了Redlock算法，来实现集群架构下的分布式锁。
Redlock算法并不复杂，假设我们Redis分片下，有三个Master的节点，这三个Master，又各自有一个Slave：
好，现在客户端想获取一把分布式锁：
记下开始获取锁的时间 startTime
按照A->B->C的顺序，依次向这三台Master发送获取锁的命令。客户端在等待每台Master回响应时，都有超时时间timeout。举个例子，客户端向A发送获取锁的命令，在等了timeout时间之后，都没收到响应，就会认为获取锁失败，继续尝试获取下一把锁
如果获取到超过半数的锁，也就是 3/2+1 = 2把锁，这时候还没完，要记下当前时间endTime
计算拿到这些锁花费的时间 costTime = endTime - startTime，如果costTime小于锁的过期时间expireTime，则认为获取锁成功
如果获取不到超过一半的锁，或者拿到超过一半的锁时，计算出costTime>=expireTime，这两种情况下，都视为获取锁失败
如果获取锁失败，需要向全部Master节点，都发生释放锁的命令，也就是那段Lua脚本
追问Redlock
1、为什么要给每个获取锁的请求设置timeout
为了防止在某个出了问题的Master节点上，浪费太多时间。一旦超时了，马上尝试下一个。
2、获取了过半数的锁之后，还要不要继续获取
这个没有约束。
你可以选择适可而止，这样可以提高获取锁的速度，总共三台，A和B都拿到了，就不必去拿C了。
3、如果costTime只比expireTime小一点点，会不会有问题？
当然有问题，这样你前脚刚拿到锁，走进门，后脚分布式锁就过期了，别人也拿到锁，进门了，互斥性被打破。
解决办法是，每个请求的timeout要比expireTime小很多，比如你的expireTime是10s，那么timeout可以设置为50ms，这样costTime最多也就50*3=150ms，剩下的9850ms，这九秒多钟，你都可以用来执行代码，保证不会有其他进程可以进入。
当然，如果你的代码执行了9850ms还没执行完，那别的进程还是可以抢到锁。这也是一个暂时无解的问题。
4、释放锁时，为什么不能只向成功获取到锁的Master发送释放命令，而要向所有的Master节点发送
很简单，假设你向Master A发送了获取锁的命令，set命令执行成功了，但是在回响应时发送了故障，响应没发回来，过了超时时间后，你会认为获取锁失败，而实际上，锁已经在redis那边生效了。
所以在释放锁的时候，必须向全部节点都发生命令，不管你到底有没有在那节点上面获取到锁。
5、如果有节点crash，锁不也还是会丢失吗？
的确，单机时候的问题，在集群依然存在。
Redlock算法，在有节点重启或者crash的情况下，也会有可能无法达到互斥的目的。
假设有三个节点ABC：
- 进程1在B和C上拿到了锁
- 这时候B crash了
- 如果B没有Slave节点，那么B会重启，如果数据还没备份，那么重启后B上的锁就丢了
- 又或者B有Slave节点，但是crash时，Master B的数据还没同步到Slave，Slave被提拔为Master
- 不管有没有Slave，其他进程都有可能在B crash掉之后，在B上拿到锁，再加上在A拿到的锁，就可以拿到超过半数的锁，这样就有两个进程同时拿到了锁，互斥性被打破
对于上面这个问题，Redis的作者，同时也是Redlock的作者antirez，提出了delay的解决方案，就是让B别那么快重启，稍微等一下，等的时间，就是分布式锁的最大过期时间，等到其他节点上的锁都过期了，你再重启，对外提供服务。
对于有Slave的情况，也可以用类似的方案，Slave先别那么快接替Master，稍微等一下下。
6、会不会有锁饥饿的问题？
还是三台Master节点，现在有三个进程同时要加同一把锁，会不会出现每次都是一个进程抢到一把锁的情况？
这是有可能的。
解决办法1：
获取锁失败后，随机休息一段时间
解决办法2：
如果客户端在发现，就算后面全部的锁，都被我抢到，加起来也不能超过半数，这时候就不再继续往下抢。
举个例子，进程1抢到了节点A的锁，进程2抢到节点B的，这时候进程3想过来抢锁，按照ABC的顺序，逐个抢，A和B都抢不过别人，于是掐指一算，就算C让我抢到了，我也抢不到超过半数了，没必要继续抢了，我还是先尝试抢一下A吧。
这样就不会出现三把锁，分别被三个不同的进程抢的情况了。
Redisson（一个Java的redis客户端）在实现redlock时就采用了这个解决方案。
Redlock实现：Redisson
上面讲的只是Redlock的算法，具体怎么用代码来实现，可以看redlock各种语言的客户端源码，比如Java的实现，就可以看看Redisson。
参考资料