Redis分布式锁，绝对问烂了吧

这个玩意儿问的太多，现在很多面试官已经避开了这个面试题

我这里也不讲太多，而是在实现上做一些总结和分析

看看有没有帮助

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的实现原理如下：

1. 获取当前时间戳

2. 尝试在多个Redis节点上获取锁，每个节点使用相同的key和value，并设置一个过期时间。

3. 统计成功获取锁的节点数量，根据1的时间计算获取锁花费的时间，判断锁是否过期

4. 如果大多数节点获取锁成功，并在有效期内，则获取成功

5. 如果获取锁失败，则在所有成功获取锁的节点上释放锁。

Redlock也存在一些问题，例如：

1. 时钟偏移

• 如果每个节点时间戳不一样，过期时间可能计算错误

2. 锁提前释放

• 和第一道题的一样，如果还没有释放锁，锁已经过期了，导致其他客户端可以获取锁

3. 分布式系列问题，用例子说明

• 1 2 3 4 5 台服务，A线程在 1 2 3 设置键成功，A持有锁，B线程在4 5 设置键，此时 3 挂了，重启后丢失A创建的键，B线程又设置键成功了，那就AB均获取到锁了，可以通过持久化解决。

• 1 2 3 4 5 台服务，A线程在 1 2 设置键成功，B线程在 3 4 设置键成功，C线程在 5 设置键成功，导致都获取不到锁，只能都释放重新来了，很难完全解决。

4. 性能问题

• 节点越多，获取锁的时间就越长，情况也会越复杂

所以Redlock也不能很好的解决分布式锁的系列问题， 这个时候又来个Redlock++，它可以解决一部分问题，更复杂了，没有必要再深入了，通常情况下，使用分布式锁也得取舍，因为它本身为了解决互斥问题，却带来了更多的问题，要么直接使用开源的分布式锁框架，要么直接改变业务方式。