1. 什么是分布式锁？
锁大家已经很清楚了，就是避免线程竞争出现问题，那分布式锁，自然在分布式环境下避免线程或进程竞争出现问题了。
一句话回答： 分布式下，对共享资源进行互斥访问的一种处理机制。
列几个应用场景（工作中实际用到的）：
1. 定时任务
定时任务写在服务里时，同时启动了多个服务，这个时候就需要用到分布式锁，保证只有一个服务去执行定时任务。（即便定时任务有幂等性，但是也要考虑并发带来的问题）
2. 三方认证信息维护
我们要接入第三方系统（例如：微信公众平台），通过Token进行访问，Token失效时，需要去更新Token，这个时候只允许一个服务去更新，其他服务使用旧的token访问（微信拿到新token时，旧的token还有5分钟有效期），其他第三方系统我们也是用到了分布式锁处理。
上面两个例子，公司至今还有系统在使用，大部分定时任务已经移植到了统一调度中心，三方信息维护目前还在应用，至于网上经常看到的秒杀，抢购的案例，我是不赞同用分布式锁的，分布式锁也要解决单点问题，其次分布式锁性能也较低。
2. Redis如何实现分布式锁？【极速回答版】
这个面试题我真的不想说了，不知道问了多少次，这里我简单快速的回顾一下，不像网上的长篇大论去讨论，而是说一些关键注意事项，这些事项说完，面试基本没有问题，没有谁面试真的让你去代码实现分布式锁。
1. 原子性
设置获取锁的命令一定要原子性，不能分多个命令进行，如果确实需要多个命令，则使用Lua脚本去完成。
2. 持有线程
因为要保证锁的安全性，要求记录持有锁的线程，允许重入和解锁，也避免其他线程未持有锁释放该锁。
3. 锁释放
如果获取锁的服务自身挂掉，也要保证锁能够释放掉，这个时候通常用超时（key有效期）来处理。
4. 超时检查
如果应用没有挂，结果锁超时释放了，这也是一个问题，这个时候就可以通过检查持锁线程状态的方式去解决，另起检查线程（我是不理解了，另起检查线程，万一它也挂了呢，所以多此一举嘛，也可以自身检查后延长时间，这个就更不靠谱了，自己执行任务都超时了，还来得及延长锁么）
5. 单点性
如果Redis服务自身挂了，也要考虑锁是否还能被使用，这个时候就需要集群处理了。
通过上面几点看，自身去实现一个分布式锁，太繁琐，所以Redis官方给了建议，使用Redlock（也有一些其它的框架实现Redis分布式锁）；那么新的面试题又来了，Redlock的实现原理。
这里先不去对比其他方式实现分布式锁（例如zookeeper和数据库等）
3. Redlock实现原理？问题分析
Redlock的实现原理如下：
- 获取当前时间戳
- 尝试在多个Redis节点上获取锁，每个节点使用相同的
key和value，并设置一个过期时间。 - 统计成功获取锁的节点数量，根据1的时间计算获取锁花费的时间，判断锁是否过期
- 如果大多数节点获取锁成功，并在有效期内，则获取成功
- 如果获取锁失败，则在所有成功获取锁的节点上释放锁。
Redlock也存在一些问题，例如：
1. 时钟偏移
- 如果每个节点时间戳不一样，过期时间可能计算错误
2. 锁提前释放
- 和第一道题的一样，如果还没有释放锁，锁已经过期了，导致其他客户端可以获取锁
3. 分布式系列问题，用例子说明
12345台服务，A线程在123设置键成功，A持有锁，B线程在45设置键，此时3挂了，重启后丢失A创建的键，B线程又设置键成功了，那就AB均获取到锁了，可以通过持久化解决。12345台服务，A线程在12设置键成功，B线程在34设置键成功，C线程在5设置键成功，导致都获取不到锁，只能都释放重新来了，很难完全解决。
4. 性能问题
- 节点越多，获取锁的时间就越长，情况也会越复杂
所以Redlock也不能很好的解决分布式锁的系列问题， 这个时候又来个Redlock++，它可以解决一部分问题，更复杂了，没有必要再深入了，通常情况下，使用分布式锁也得取舍，因为它本身为了解决互斥问题，却带来了更多的问题，要么直接使用开源的分布式锁框架，要么直接改变业务方式。
