程序员修神之路--redis做分布式锁可能不那么简单
菜菜哥，复联四上映了，要不要一起去看看？
又想骗我电影票，对不对？
呵呵，想去看了叫我呀
看来你工作不饱和呀
哪有，这两天我刚基于redis写了一个分布式锁，很简单
不管你基于什么做分布式锁，你觉得很简单吗？来来来
在计算机世界里，对于锁大家并不陌生，在现代所有的语言中几乎都提供了语言级别锁的实现，为什么我们的程序有时候会这么依赖锁呢？这个问题还是要从计算机的发展说起，随着计算机硬件的不断升级，多核cpu，多线程，多通道等技术把计算机的计算速度大幅度提升，原来同一时间只能执行一条cpu指令的时代已经过去。随着多条cpu指令可以并行执行的原因，原来不曾出现的资源竞争随着出现，在程序中的体现就是随处可见的多线程环境。比如要更新数据库的一个信息，如果没有并发控制，多个线程同时操作的话，就会出现互相覆盖的现象发生。
锁要解决的就是资源竞争的问题，也就是要把执行的指令顺序化
随着互联网的兴起，现代软件发生了翻天覆地的变化，以前单机的程序，已经支撑不了现代的业务。无论是在抗压，还是在高可用等方面都需要多台计算机协同工作来解决问题。现代的互联网系统都是分布式部署的，分布式部署确实能带来性能和效率上的提升，但为此，我们就需要多解决一个分布式环境下，数据一致性的问题。
当某个资源在多系统之间共享的时候，为了保证大家访问这个资源数据是一致的，那么就必须要求在同一时刻只能被一个客户端处理，不能并发的执行，否者就会出现同一时刻有人写有人读，大家访问到的数据就不一致了。
在分布式系统的时代，传统线程之间的锁机制，就没作用了，系统会有多份并且部署在不同的机器上，这些资源已经不是在线程之间共享了，而是属于进程（服务器）之间共享的资源。
因此，为了解决这个问题，我们就必须引入「分布式锁」。分布式锁，是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。分布式锁的特点如下：
如果你通过网络搜索分布式锁，最多的就是基于redis的了。基于redis的分布式锁得益于redis的单线程执行机制，单线程在执行上就保证了指令的顺序化，所以很大程度上降低了开发人员的思考设计成本。但是，基于redis做分布式锁难道真的这么容易吗？
基于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在正常的业务当中，当一个线程获取到锁并且设置了锁的过期时间之后，会出现由于业务代码执行时间过长，锁由于到达超时时间自动释放的情况。自动释放之后，其他的线程就会获取到分布式锁，导致业务代码不会串行执行。如果业务上允许这样的情况偶尔发生，那程序员就开干吧，最后顶多人工干预一下，update 一下数据库。
为了避免这类情况发生，在使用redis分布式锁的时候，业务方应尽量避免长时间执行的代码任务。
如果设置锁的超时时间比较长，在一定程度上可以缓解业务代码执行时间长锁自动到期的问题，但是一旦业务代码down掉，其他等待锁的线程等待的时间会比较长，这种情况下，确保获取到锁的程序不会down 成为了主要问题。
当锁被一个调用方获取之后，其他调用方在获取锁失败之后，是继续轮询还是直接业务失败呢？如果是继续轮询的话，同步情况下当前线程会一直处于阻塞状态，所以这里轮询的情况还是建议使用异步。
可重入性是指已经拥有锁的客户端再次请求加锁，如果锁支持同一个客户端重复加锁，那么这个锁就是可重入的。如果基于redis的分布式锁要想支持可重入性，需要客户端封装，可以使用threadlocal存储持有锁的信息。这个封装过程会增加代码的复杂度，所以菜菜不推荐这样做。
如果在多个客户端获取锁的过程中，redis 挂了怎么办呢？假如一个客户端已经获取到了锁，这个时候redis挂了（假如是redis集群），其他的redis服务器会接着提供服务，这个时候其他客户端可以在新的服务器上获取到锁了，这也导致了锁意义的丢失。有兴趣的同学可以去看看RedLock，这种方案以牺牲性能的代价解决了这个问题。
在某些时候，redis的服务器时间发生的跳跃，由于锁的过期时间依赖于服务器时间，所以也会出现两个客户端同时获取到锁的情况发生。
当把以上问题都有解决方案了之后，基于redis的分布式锁才可以放心使用
基于redis设计简单分布式锁容易，但是设计完美分布式锁不易， 还觉得基于redis的分布式锁好做吗？
