Redis面试，看这就够啦，2024年最新jdk8新特性面试

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

set key value [ex seconds] [px milliseconds] [nx|xx]

ex seconds： 为键设置秒级过期时间。

px milliseconds： 为键设置毫秒级过期时间。

nx： 键必须不存在， 才可以设置成功， 用于添加。

xx： 与nx相反， 键必须存在， 才可以设置成功， 用于更新。

面试官：那这样还是会存在一个问题，假如你业务代码没有执行完，然后你的redis又把锁自动释放了，然后其他线程又可以获取到锁，那样不就还是又线程安全问题了？

小白：是的，但是针对这种问题redis官网也帮我们想了一种解决方案，也就是redis的红锁

面试官：那你可以和我说说redis的红锁是怎么回事么？

小白：sorry,i don’t no

面试官：你应该还记得怎么进来的把？我就不送了

小白：这个红锁有兴趣可以看看官网，给大家来一个传送门：redis红锁

面试官：那看你还知道在哪看api就再问一个问题好啦，redis的击穿，雪崩，穿透，都了解没，然后怎么解决呢？

小白：先从雪崩开始说好啦，雪崩就是指再某一个时间点，很多热点key同一时间失效了，那样就会导致之前查redis的请求都去查mysql了，那样就会导致mysql扛不住，然后直接挂了，解决方法就是redis再给这些热点key设置过期时间的时候不要都设置一个时间点，可以加一个随机数。再说击穿好啦，击穿就是我很多请求，一直请求一个热点key，如果这个热点key设置了过期时间，那么它过期那一瞬间，所有请求就全都打到mysql上了，那样也可能导致数据库挂了，解决方案就是给这样的热点key设置永不过期。也就是不设置过期时间就好啦。然后还有穿透，穿透就是我发起的请求再redis中不存在，那样肯定会去请求mysql了的，但是实际上再mysql重也是没有的，比如我查id=-1这样类似的数据。这个解决方案的话就是增加一个布隆过滤器进行处理的。

面试官：那看你答得还行，说说redis得持久化机制把

小白：redis得持久化机制有两种，一种是RDB就是多长时间内多少key发生了变化，就使用一次快照得方式进行一次持久化，还有就是AOF持久化，有三个取值，一个是不开启，一个是每一次对key得修改都以记录日志得方式进行一个记录，还有就是一秒钟记录一次，一半采用最后最后一种。

面试官：那你再和我说说这两种得使用场景，和优劣

小白：直接看官网不会？

RDB的优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.

• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.

• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.

• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB的缺点

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.

• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你-

• 可以调节重写日志文件的频率来提高数据集的耐久度.

AOF 优点

• 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.

• AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.

• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

面试官：那你再跟我说说redis得哨兵模式好了

• Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

总结

我们总是喜欢瞻仰大厂的大神们，但实际上大神也不过凡人，与菜鸟程序员相比，也就多花了几分心思，如果你再不努力，差距也只会越来越大。

面试题多多少少对于你接下来所要做的事肯定有点帮助，但我更希望你能透过面试题去总结自己的不足，以提高自己核心技术竞争力。每一次面试经历都是对你技术的扫盲，面试后的复盘总结效果是极好的！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
*
[外链图片转存中…(img-pU4X0izr-1713570310015)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！