redis面试（六）分布式锁开篇
什么是分布式锁？
在我们的分布式服务中，如果不同的系统服务，不同的 线程，要针对同一个资源进行修改。 小的维度比如是一行数据，大的维度比如是某一批数据的处理过程。
我们要保证这个修改过程的原子性，那么就把这个过程用一个锁包裹起来，每个线程进行处理的时候都要先获取到这把锁，如果获取不到的话就证明有其他线程正在处理。 等其他线程处理完之后，当前线程才能接着处理。
其实本质上分布式锁与单个数据库的锁没有多大区别。无非就是这个竞争的资源是所有线程，所有服务可见的。
适用于什么场景？
最常见的就是订单逻辑中了吧， 下单的时候，要保证生单成功，并且货物冻结成功。 这两个步骤必须要一起处理，要么一起成功，要么一起失败。
而订单和商品的服务大概率是分开的，所以涉及到两个服务的时候，就要锁定这个资源。锁定资源处理过程中，不能被其他的线程竞争到。
或者是支付逻辑中，数据库的支付状态修改和第三方一定是原子性的。并且这个过程持续的时候，支付状态不能被其他线程或者服务修改，比如超时取消。
总结一下：就是在分布式服务环境下，保证同一时刻只有一个线程（进程）获取资源，多线程（多进程）互斥的一种锁。
那么，主要做的就是让这个锁资源在所有的服务器中都可以看见。并且具有高效的增删改查功能。
zk和redis的区别
zk
zookeep也有分布式锁的实现，而且实现的原理也是比较简单的，某个节点尝试创建临时的znode，成功了就证明是获取这个锁成功了。
其他客户端来创建同名锁失败，那就注册一个监听器来监听这个锁，一旦znode被释放掉的话，就会去再次竞争创建这个同名znode临时节点。 之后我们可以单开一章把zk的分布式锁代码逻辑分析一下。
redis
简单来说，就是在redis中，加一个key。加成功了，就代表锁获取成功了。
其他线程来加这个key的时候，判断一下是否存在，如果存在的话，证明这个锁已经被其他线程占用了，要进入等待。
这中间会有很多问题，比如，线程卡死了，锁资源一直不释放，那就造成死锁了，该怎么办？
再比如，线程不知道锁失效了，再去进行解锁的时候，这个锁还是原来的吗？
还有就是，如果redis也是分布式多节点的话，会不会有问题？
后面我们就通过分析源码的方式，把这些问题一一都回答出来。 各位兄弟姐妹如果有其他问题的话也可随时提出来。
题外话
为什么这里要分析redis锁，因为工作中使用缓存接触最多的就是redis，而且redis有一个比较流行的分布式锁组件redisson，我们就是要分析redisson的源码。