面试题打卡 | 01 #面试题# 分享 大家好，我是影子。 最近在准备面试题的东西，之前也不断的了解过八股的记忆方式。 个人感觉比较好的方法如下： 1. 通过先了解原理或者答案，同时实践一遍，正所谓好记性不如烂笔头，实践一遍的时候，对于很多细节也能把控住。 2. 对于一个问题，不要仅限于表面，当问题问到A的时候，试想自己是面试官的话，接下来会怎么问这个问题相关的，而不是，对于一个问题，背完就结束，那么稍微问深一点九接不住了。 3. 也是我个人比较喜欢的。 对于多个相关的问题，学习后，整理为一整篇答案，因为很多问题，其实还是可以联系起来的，后面就是通过上下联系的方式，将全部梳理出来，类似于跟别人讲解，当自己能讲出来的时候，这个题，百分之80已经掌握了，剩下的就是偶尔多看看，加深记忆。 本次，以Redis的问题作为分享，因为基本都是自己的口语化方式，模拟跟面试官的对话，当然，如果是大厂的深度拷问，肯定不够用，纯属打卡分享，哪里有误还望大家指出。 压力山大的问题： redisson实现的分布式锁能解决主从一致性的问题吗？ 如果业务非要保证数据的强一致性，这个该怎么解决呢？ 能介绍一下redis的分布式锁的相关知识吗？ .....| 自行补充 找工作的我： 好的，因为在分布式的场景下，一个服务被部署到多个服务器上，那么在并发的情况下，可能导致一个任务被多次执行。那像我们在单机使用的锁，例如syscornized lock锁，就没法解决这个问题。那么，就需要使用到分布式锁。 分布式锁的实现有很多方式，例如redis的setnx命令，这个命令是存入一个key value，如果存入成功，则返回一个1。如果已经有这个key了，那么返回0，存入失败，并且结合lua脚本去实现。但是通过这个方式实现会有很多问题。第一个是流程会比较复杂，成本高。第二个是它的不可重入问题，第三个是它的不可重试问题，第四个是它的超时无法自动续期问题，第五个是主从一致问题。 那基于这些问题，我在项目中采用的是redisson。redisson很好的基于redis去解决了很多分布式的问题，例如分布式限流 分布式锁等等。 首先是不可重入的问题，因为它的底层是一个可重入锁，底层的流程是如果有请求过来，先判断是否已经存入线程号，如果没有，则直接获取锁，如果有，那么判断是否是同一个线程号，如果不是，则直接拒绝。如果是，则给redis中的value值加一，然后重置TTL。那么释放锁的话同样的，给value值减一，直到value为0释放锁，让其他的线程去获取锁。 那第二个的话是不可重试问题，我们使用Redisson的时候，可以定义一个时间，当一个线程获取不到锁的时候，让它不断的自旋进行尝试，直到时间到了，才停止尝试获取。 那第三个的话是不可自动续期问题，redisson中有一个看门狗机制，我们可以在代码中将trylock这个方法中将参数设置为-1，则算开启了这个看门狗机制，那这个机制的话，可以保证我们的业务完整执行，不会说因为当TTL结束后，锁就自动释放了，那具体的话我在实践中看到的是，给的时间是默认30秒，当到达三分之二的时间的时候，就会自动续期。直到我们的业务完整的执行完再释放锁。 那最后的话是主从一致的问题。因为我们底层使用的setnx的命令，那当我们获取到锁的时候，它是写入主节点的，但是因为主节点是异步复制到从节点，那如果说此时主节点宕机了，而线程一获取到锁后又没有释放锁，从节点也没有同步信息。 同时，从节点中会选举一个作为主节点。此时线程二来获取锁，则会获取成功，最终导致出现了一把锁两个线程获取，这是不合理的。 那解决的方式的话，我们可以使用mulitlock这个多重锁，使用这个锁的话，必须保证所有节点都成功的写入获取锁的线程信息后，才算获取成功，那这样就避免了因为redis多节点信息不一致导致的多个线程获取同一把锁的情况。