1. Redis分布式锁原理
1.1. Redisson
现在最流行的redis分布式锁就是Redisson了，来看看它的底层原理就了解redis是如何使用分布式锁的了
1.2. 原理分析
分布式锁要解决的是分布式环境下，并行相同代码的加锁功能；了解过redis分布式锁的人肯定知道，一开始redis作为分布式锁用的是setnx，再这基础上设置个定时过期时间，但这种方式有什么问题呢？
实际上看懂上图的人也就明白了那有什么问题，首先是原子性问题，setnx+过期时间这两个操作必须是原子性的，所以这可以用lua脚本解决
再然后是释放锁的时机该如何定？
- 不管我们定多少过期时间，都不能保证，在这段时间内锁住的代码执行完成了，所以这个时间定多少都不好；
- 如果不定时间，当执行完成后释放锁，问题就是如果执行到一半机器宕机，那这把锁就永远放不掉了
那Redisson是如何解决上述问题的呢？
- 它对代码进行了精简的封装，我们的使用非常简单，甚至我们不用主动设置过期时间
- 它设计了个watch dog看门狗，每隔10秒会检查一下是否还持有锁，若持有锁，就给他更新过期时间30秒；通过这样的设计，可以让他在没有释放锁之前一直持有锁，哪怕宕机了，也能自动释放锁
- 而不能获得锁的客户端则是不断循环尝试加锁
- 通过记录锁的客户端id，可以把它设计成可重入锁
1.3. 存在问题
redis作为分布式锁再大多数情况下是没问题的，但是我们知道CAP原理，一致性，可用性，分区容错性
在redis分布式架构中，我们其实保证的是AP模型，也就是尽可能的保证了redis的可用性，这在一般系统中当然是没问题的，哪怕有时候一致性有点问题（实际读到的数据不正确，或已经写入没读到）毕竟是作为缓存的存在，一定延迟可以接受，没读到可以再读数据库，这是没问题的。
但在分布式锁中，一旦出现该读到没读到，那就是重复锁的问题了，相当于分布式锁没起到作用。
这种情况发生在什么时候呢？redis集群主节点再获取锁后，没来得及复制数据给从节点，此时宕机了，从节点接替主节点进行读写，此时新的主节点没有持有该锁，那么其他想要获取该锁的服务也可以获取到该锁，导致了重复锁的问题。
一般来讲这种情况发生的概率是很小的，看你系统的规模而定，我觉得像阿里这种规模就应该不会用redis来作为分布式锁了
CP模型的分布式锁可以用zookeeper，可能性能略低于redis，但能保证安全，可以提供顺序锁等额外功能
