分布式锁的实现场景
在平时的开发中，对于高并发的开发场景，我们不可避免要加锁进行处理，当然redis中也是不可避免的，下面是我总结出来的几种锁的场景
Redis分布式锁方案一
使用Redis实现分布式锁最简单的方案是在获取锁之前先查询一下以该锁为key对应的value存不存在，如果存在，则说明该锁被其他客户端获取了，否则的话就尝试获取锁，获取锁的方法很简单，只要以该锁为key，设置一个随机的值就行了。比如，我们现在有个秒杀的场景，并发量可能是3000，但是我们商品的库存数量是一定的，为了防止超卖，我们就需要在减库存的时候加上锁，当第一个请求过来的时候，先判断锁时候存在，不存在就加锁，然后去处理秒杀的业务，并且在处理完成的时候，释放锁，如果判断锁存在，就轮训等待锁被释放。
缺点
1、如果我们处理业务的时候报错了，那么加上的锁就不能及时被释放了，这时候我们需要加上一个异常的捕获，在finally的时候释放锁。
2、同时我们也要主要set写入key，是会出现覆盖操作的，我们要要注意使用setnx（只要锁被加上，后面的写入操作不会覆盖前面的写入）
2、但是，有可能我们在处理业务的时候，整个服务器碟机了，那么异常的捕获显眼是不管用了，这时候我们的这种设计显然是存在缺陷的。
Redis分布式锁方案二
上一节的方案缺点就是锁有时候没有办法释放，造成死锁。那么对于setnx我们应该怎样处理呢？
考虑一种情况，如果进程获得锁后，断开了与 Redis 的连接（可能是进程挂掉，或者网络中断），如果没有有效的释放锁的机制，那么其他进程都会处于一直等待的状态，即出现“死锁”。
上面在使用 SETNX 获得锁时，我们将键 lock.foo 的值设置为锁的有效时间，进程获得锁后，其他进程还会不断的检测锁是否已超时，如果超时，那么等待的进程也将有机会获得锁。
然而，锁超时时，我们不能简单地使用 DEL 命令删除键 lock.foo 以释放锁。考虑以下情况，进程P1已经首先获得了锁 lock.foo，然后进程P1挂掉了。进程P2，P3正在不断地检测锁是否已释放或者已超时，执行流程如下：
- P2和P3进程读取键 lock.foo 的值，检测锁是否已超时（通过比较当前时间和键 lock.foo 的值来判断是否超时）
- P2和P3进程发现锁 lock.foo 已超时
- P2执行 DEL lock.foo命令
- P2执行 SETNX lock.foo命令，并返回1，即P2获得锁
- P3执行 DEL lock.foo命令将P2刚刚设置的键 lock.foo 删除（这步是由于P3刚才已检测到锁已超时）
- P3执行 SETNX lock.foo命令，并返回1，即P3获得锁
- P2和P3同时获得了锁
从上面的情况可以得知，在检测到锁超时后，进程不能直接简单地执行 DEL 删除键的操作以获得锁。
为了解决上述算法可能出现的多个进程同时获得锁的问题，我们再来看以下的算法。
我们同样假设进程P1已经首先获得了锁 lock.foo，然后进程P1挂掉了。接下来的情况：
- 进程P4执行 SETNX lock.foo 以尝试获取锁
- 由于进程P1已获得了锁，所以P4执行 SETNX lock.foo 返回0，即获取锁失败
- P4执行 GET lock.foo 来检测锁是否已超时，如果没超时，则等待一段时间，再次检测
- 如果P4检测到锁已超时，即当前的时间大于键 lock.foo 的值，P4会执行以下操作
GETSET lock.foo <current Unix timestamp + lock timeout + 1> - 由于 GETSET 操作在设置键的值的同时，还会返回键的旧值，通过比较键 lock.foo 的旧值是否小于当前时间，可以判断进程是否已获得锁
- 假如另一个进程P5也检测到锁已超时，并在P4之前执行了 GETSET 操作，那么P4的 GETSET 操作返回的是一个大于当前时间的时间戳，这样P4就不会获得锁而继续等待。注意到，即使P4接下来将键 lock.foo 的值设置了比P5设置的更大的值也没影响。
另外，值得注意的是，在进程释放锁，即执行 DEL lock.foo 操作前，需要先判断锁是否已超时。如果锁已超时，那么锁可能已由其他进程获得，这时直接执行 DEL lock.foo 操作会导致把其他进程已获得的锁释放掉。
缺点
1、其实这种方案还存在缺陷，我们知道对于锁设置过期的时间，虽然可以解决锁的及时释放，但是我们知道我们需要处理的业务场景的时间的不可控，可能网络动荡，我们原来0.01秒的业务现在就需要3秒钟，所以简单的对锁设置过期的时间，还是存在缺陷的。
Redis分布式锁方案三
那么对于方案二的场景的缺点我们应该怎么去处理呢？有一个简单的方法就是当给一个锁加上过期的时间的时候，我们另外开启一个线程，去监测业务处理的时间，如果锁额时间快到了，并且业务还没有执行完毕，就给锁的时间延长，实现自旋的加锁。