互联网面试必问三剑客
这个概念大家不陌生，可以说现在的面试中，经常会被问道，尤其是在面试互联网企业，互联网以微服务顺藤摸瓜的时候，面试官一定会涉及三个问题：
- 1.分布式锁如何实现的？存在什么问题？
- 2.事务一致性怎么保证的？
- 3.你觉得微服务存在什么问题？
第二点呢？可以关注我的公众号-面试怪圈，回复3fkw从视频教程：微服务架构的分布式事务控制解决方案，找到你想要的答案。
第三点，涉及的面太广了。比如：
- 配置中心
- 服务之间的数据一致性(事务一致性保证\幂等)
- 日志的规范
- 链路追踪
- 服务的监控
- 服务的熔断、降级、限流
- 运维部署管理
- 服务的注册发现、负载均衡
- 服务的安全等， 太开放的问题，基本整个面试只要问道这个问题，可以问到回答不上来为止。简直是灭绝999问。
第三点，在面试怪圈出品的《面试怪圈内卷手册》里有写到，公众号-面试怪圈回复msgq1，也可以找到我给大家准备的答案。
今天，我们就和大家摆一摆第一个问题---分布式锁，这个问题可以挖掘的考察点也太多了。
分布式锁的隐私太多了
如果你把redis分布式锁认为setnx加锁和del释放锁，可能你吊足不了面试官的胃口，或者如果你还没有了解过redis分布式锁的。可以先百度一下，在继续阅读效果更佳。 加锁过程是这样的：
貌似天衣无缝，完美至极，可真的如此吗？我们来揭穿它的底裤！
1.代码异常导致死锁
如果加锁后和释放锁之间代码异常了，锁是否无法释放？答案肯定明显是肯定的！ 无法释放锁就会导致这把锁一直会被某个进程下的某个线程持有，无法释放，其他线程也无法得到这把锁，一直等待着，造成死锁。
解决这个问题方法很简单，finally代码块搞定这个问题。毕竟，finally代码块不管try的内容是否异常都要执行！
2.进程意外终止导致死锁
似乎已经搞定了死锁了？还没喘过气，另外的问题来了。
让代码不执行到锁释放的路千万条：
如果按照以上顺序执行，中间进程中断，这就是通往死锁的另外一条死路....
不要怕，方法总比问题多！
setnx+expire两条命令搞定，expire命令可以给key设置一个过期时间，如果一旦出现进程中断的异常情况，超过设置过期时间锁也会被释放，其他线程不会造成死锁等待。
写到这里，缓缓舒了一口气，然后剧情反转才刚刚开始....
3.死锁三进宫
话说事不过三，难道还有死锁？ 很遗憾的告诉你，你猜对了！
我用伪代码描述下上图的意思，你可能一下就明了：
setnx key 1 ①
expire 30s ②
做一些不可描述的事情
del key
大家不要去猜想不可描述的事情是什么了？回归正题。
①和②是紧挨着执行的逻辑，执行会特别快，不怕一万，就怕万一。
比如，不巧哪天你在上线，重启了一下服务，刚好进行在①和②之间中断了进行。
第二天就可以去领盒饭了，又酿造了一场程序员社死现场。
由于①和②的并不是一个原子性性操作，所以意外随时都可能悄然而至。
你一定会发现又死锁了，真的是三进宫！
当然，这种死锁看上去像是走狗屎运一样，但是造成这样的死锁除了①和②之间进程异常中断，还有:
- expire的时候网络异常
- redis服务正在expire的时候网络不可用
问题明了了，怎么整！怎么整？ redis官方为了推动他的产品，也肯定考虑到这种场景，毕竟不能因为一个小小的setnx和expire的原子性问题，损失一大片忠实粉丝。
在 Redis 2.6.12 版本之前，我们需要想尽办法，保证 SETNX 和 EXPIRE 原子性执行，还要考虑各种异常情况如何处理。
但在 Redis 2.6.12 之后，Redis 扩展了 SET 命令的参数，用这一条命令就可以了：
SET lock 1 EX 10 NX
这个"终极方案"完美了？然而问题依然还有很多。
不过，分布式锁的隐私太多了系列第一部死锁三进宫算是告一段落了。
已经1点多了，明天还要继续搬砖。
明天继续以短篇小说的形式，继续摆一摆分布式锁的隐私太多了系列第二部偷偷释放你的锁
感谢大家关注公众号-面试怪圈，我是Yesterday,我们下篇接着聊~
高能提示：面试怪圈-程序员的图书馆，Java架构、Java面试题、简历模板、中间件学习教程等等
457
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
