请求|阿里面试官：分布式锁到底用Redis好？还是Zookeeper好？( 二 ) 面试|红包|妹子|redis|阿里|zoo

说到分布式锁的实现，还是有很多的，有数据库方式的，有redis分布式锁，有zookeeper分布式锁等等
我们如果采用redis作为分布式锁，那么上图中负“责红包的妹子（服务）”，就可以替换成redis，请自行脑补。
3.1，为什么redis可以实现分布式锁？
首先redis是单线程的，这里的单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。
在实际的操作中过程大致是这样子的：
服务器1要去访问发红包的妹子，也就是redis，那么他会在redis中通过"setnx key value" 操作设置一个key 进去，value是啥不重要，重要的是要有一个key，也就是一个标记，而且这个key你爱叫啥叫啥，只要所有的服务器设置的key相同就可以。
假设我们设置一个，如下图
那么我们可以看到会返回一个1，那就代表了成功。
如果再来一个请求去设置同样的key，如下图：
这个时候会返回0，那就代表失败了。
那么我们就可以通过这个操作去判断是不是当前可以拿到锁，或者说可以去访问“负责发红包的妹子”，如果返回1，那我就开始去执行后面的逻辑，如果返回0，那就说明已经被人占用了，我就要继续等待。
当服务器1拿到锁之后，进行了业务处理，完成后，还需要释放锁，如下图所示：
删除成功返回1，那么其他的服务器就可以继续重复上面的步骤去设置这个key，以达到获取锁的目的。
当然以上的操作是在redis客户端直接进行的，通过程序调用的话，肯定就不能这么写，比如java 就需要通过jedis 去调用，但是整个处理逻辑基本都是一样的
通过上面的方式，我们好像是解决了分布式锁的问题，但是想想还有没有什么问题呢？？
对，问题还是有的，可能会有死锁的问题发生，比如服务器1设置完之后，获取了锁之后，忽然发生了宕机。
那后续的删除key操作就没法执行，这个key会一直在redis中存在，其他服务器每次去检查，都会返回0，他们都会认为有人在使用锁，我需要等。
为了解决这个死锁的问题，我们就就需要给key 设置有效期了。
设置的方式有2种
1，第一种就是在set完key之后，直接设置key的有效期 "expire key timeout" ，为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
这种方式相当于，把锁持有的有效期，交给了redis去控制。如果时间到了，你还没有给我删除key，那redis就直接给你删了，其他服务器就可以继续去setnx获取锁。
2，第二种方式，就是把删除key权利交给其他的服务器，那这个时候就需要用到value值了，
比如服务器1，设置了value 也就是 timeout 为当前时间+1 秒，这个时候服务器2 通过get 发现时间已经超过系统当前时间了，那就说明服务器1没有释放锁，服务器1可能出问题了，
服务器2就开始执行删除key操作，并且继续执行setnx 操作。
但是这块有一个问题，也就是，不光你服务器2可能会发现服务器1超时了，服务器3也可能会发现，如果刚好，服务器2，setnx操作完成，服务器3就接着删除，是不是服务器3也可以setnx成功了？
那就等于是服务器2和服务器3都拿到锁了，那就问题大了。这个时候怎么办呢？
这个时候需要用到“GETSETkey value” 命令了。这个命令的意思就是获取当前key的值，并且设置新的值。
假设服务器2发现key过期了，开始调用 getset 命令，然后用获取的时间判断是否过期，如果获取的时间仍然是过期的，那就说明拿到锁了。
如果没有，则说明在服务2执行getset之前，服务器3可能也发现锁过期了，并且在服务器2之前执行了getset操作，重新设置了过期时间。
那么服务器2就需要放弃后续的操作，继续等待服务器3释放锁或者去监测key的有效期是否过期。
这块其实有一个小问题是，服务器3已经修改了有效期，拿到锁之后，服务器2，也修改了有效期，但是没能拿到锁，但是这个有效期的时间已经被在服务器3的基础上有增加一些，但是这种影响其实还是很小的，几乎可以忽略不计。
3.2，为什么zookeeper可以实现分布式锁？
百度百科是这么介绍的：ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。
那对于我们初次认识的人，可以理解成ZooKeeper就像是我们的电脑文件系统，我们可以在d盘中创建文件夹a，并且可以继续在文件夹a中创建文件夹a1，a2。
那我们的文件系统有什么特点？？那就是同一个目录下文件名称不能重复，同样ZooKeeper也是这样的。