Redis高频面试题汇总（2024最新版），2024年最新Java开发中常见的一些问题面试专题

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

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

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

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

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

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

正文

1. 从过期字典（设置了过期时间的key的集合）中随机选择20个key，检查其是否过期

2. 删除其中已经过期的key

3. 如果删除的过期key数量大于25%，则重复步骤1

此外开发在设计Redis缓存架构时，一定要注意要尽可能的避免（禁止）将大量的key设置为同一过期时间，因为结合被动删除可知，Redis被动删除过期key时，会导致服务短暂的不可用；如果存在大量key同时过期，这会导致被动删除key的三个步骤循环多次，从而导致Redis服务出现卡顿情况，这种情况在大型流量项目是无法接收的。 因此为了避免这种情况出现，一定要将一些允许过期时间不需要非常精确的key，设置较为随机的过期时间，这样就可以将卡顿时间缩小。 ​

这个我的理解大致是这样的面试官！！

在分布式场景中我们常见的分布式锁解决方案有（如果自己都会可以把其他两种也在这带出来，如果不会那就别把自己坑了呀！）：

1. 基于数据库锁机制实现的分布式锁

2. 基于Zookeeper实现的分布式锁

3. 基于Redis实现的分布式锁

而关于Redis实现分布式锁的方案是这样的。 如果Redis是在单机环境中我们可以通过，Redis提供的原子指令来实现分布式锁

set key value [EX seconds] [PX milliseconds] [NX|XX]

为了防止A加的锁，被B删除了，可以加锁时传入客户端加锁标记，只有当客户端传入的标记和锁标记相同时才允许解锁，不过Redis并未提供这样的功能，我们只能通过Lua脚本来处理，因为Lua脚本可以保证多个指令的原子性执行。最后我们还要考虑锁的超时问题，如果客户端一直不释放锁肯定也是不行的，因此锁只能保证在指定的超时时间范围内不被其他客户端解锁，超时之后就自动释放了，这种情况很难我们可以这样优化：

1. 尽可能不要在Redis分布式锁中执行较长的任务，尽可能的缩小锁区间内执行代码，就像单JVM锁中的synchronized优化一样，我们可以考虑优化锁的区间

2. 多做压力测试和线上真实场景的模拟测试，估算一个合适的锁超时时间

3. 做好Redis分布式锁超时任务未执行完的问题发生后，数据恢复手段的准备

如果是在分布式环境中，会增加一个新的问题，比如sentinel+一主多从环境中，可能存在客户端在主节点上申请了锁，但是同步未完成，主节点宕机了，此时新选举的主节点上锁是失效的。 对于这种情况的处理应该是这么考虑的，首先Redis主从同步直接无论如何都无法解决数据会有丢失的情况。所以我们考虑把像一个Redis申请锁，变成像多个单机Redis申请锁，只有大部分申请成功就行。这种思想就是RedLock(红锁）。 RedLock通过使用多个Redis实例，各个实例之间没有主从关系，相互独立；加锁的时候，客户端向所有的节点发送加锁指令，如果过半的节点set成功，就加锁成功。释放锁时，需要向所有的节点发送del指令来释放锁。 红锁虽然解决了主从同步的问题，但是带来新的复杂问题：

• 第一个问题是时钟漂移

• 第二个问题是客户端像不同的Redis服务端申请锁成功的时间是不同的

因此在RedLock中需要计算申请的锁的最小有效时长。假设客户端申请锁成功，第一个key设置成功的时间为TF，最后一个key设置成功的时间为TL，锁的超时时间为TTL，不同进程之间的时钟差异为CLOCK_DIFF，则锁的最小有效时长是：

TIME = TTL - (TF- TL) - CLOCK_DIFF

采用Redis来实现分布式锁，离不开服务器宕机等不可用问题，这里RedLock红锁也一样，即使是多台服务器申请锁，我们也要考虑服务器宕机后的处理，官方建议采用AOF持久化处理。 但是AOF持久化只对正常SHUTDOWN这种指令能做到重启恢复，但是如果是断电的情况，可能导致最后一次持久化到断电期间的锁数据丢失，当服务器重启后，可能会出现分布式锁语义错误的情况。所以为了规避这种情况，官方建议Redis服务重启后，一个最大客户端TTL时间内该Redis服务不可用（不提供申请锁的服务），这确实可以解决问题，但是显而易见这肯定影响Redis服务器的性能，并且在多数节点都出现这种情况的时候，系统将出现全局不可用的状态。 ​

这个我的理解大致是这样的面试官！！

Redis的非常快，很大一部分原因是因为Redis的数据存储在内存中，既然在内存中，那么当服务器宕机或者断电的时候，数据就会全部丢失了，所以Redis提供了两种机制来保证Redis数据不会因为故障而全部丢失，这种机制称为Redis的持久化机制。 Redis的持久化机制有两种：

• RDB(Redis Data Base) 内存快照

• AOF(Append Only File) 增量日志

RDB(Redis DataBase) 指的是在指定的时间间隔内将内存中的数据集快照写入磁盘，RDB是内存快照（内存数据的二进制序列化形式）的方式持久化，每次都是从Redis中生成一个快照进行数据的全量备份。 优点：

• 存储紧凑，节省内存空间

• 恢复速度非常快

• 适合全量备份、全量复制的场景，经常用于灾难恢复（对数据的完整性和一致性要求相对较低的场合）

缺点：

• 容易丢失数据，容易丢失两次快照之间Redis服务器中变化的数据。

• RDB通过fork子进程对内存快照进行全量备份，是一个重量级操作，频繁执行成本高。

• fork子进程，虽然共享内存，但是如果备份时内存被修改，最大可能膨胀到2倍大小。

RDB触发的规则分为两大类，分别是手动触发和自动触发： 自动触发：

1. 配置触发规则

2. shutdown触发

3. flushall触发

手动触发：

1. save

2. bgsave

**AOF(Append Only File)**是把所有对内存进行修改的指令（写操作）以独立日志文件的方式进行记录，重启时通过执行AOF文件中的Redis命令来恢复数据。AOF能够解决数据持久化实时性问题，是现在Redis持久化机制中主流的持久化方案（后续会谈到4.0以后的混合持久化）。 优点：

• 数据的备份更加完整，丢失数据的概率更低，适合对数据完整性要求高的场景

• 日志文件可读，AOF可操作性更强，可通过操作日志文件进行修复

缺点：

• AOF日志记录在长期运行中逐渐庞大，恢复起来非常耗时，需要定期对AOF日志进行瘦身处理（后续详述）

• 恢复备份速度比较慢

• 同步写操作频繁会带来性能压力

AOF日志是以文件的形式存在的，当程序对AOF日志文件进行写操作时，实际上将内容写到了内核为文件描述符分配的一个内存缓冲区中，随后内核会异步的将缓冲区中的数据刷新到磁盘中。如果缓冲区中的数据没来得及刷回磁盘时，服务器宕机了，这些数据就会丢失。 因此Redis通过调用Linux操作系统的glibc提供的fsync(int fid)来将指定文件的内容强制从内核缓冲区刷回磁盘，以此来保证缓冲区中的数据不会丢失。不过这是一个IO操作，相比Redis的性能来说它是非常慢的，所以不能频繁的执行。 Redis配置文件中有三种刷新缓冲区的配置：

appendfsync always 每次Redis写操作，都写入AOF日志，这种配置理论上Linux操作系统扛不住，因为Redis的并发远远超过了Linux操作系统提供的最大刷新频率，就算Redis写操作比较少的情况，这种配置也是非常耗性能的，因为涉及到IO操作，所以这个配置基本上不会用 ​

appendfsync everysec 每秒刷新一次缓冲区中的数据到AOF文件，这个Redis配置文件中默认的策略，兼容了性能和数据完整性的折中方案，这种配置，理论上丢失的数据在一秒钟左右 ​

appendfsync no Redis进程不会主动的去刷新缓冲区中的数据到AOF文件中，而是直接交给操作系统去判断，这种操作也是不推荐的，丢失数据的可能性非常大。 ​

前面提到AOF的缺点时，说过AOF属于日志追加的形式来存储Redis的写指令，这会导致大量冗余的指令存储，从而使得AOF日志文件非常庞大，这种情况不仅占内存，也会导致恢复的时候非常缓慢，因此Redis提供重写机制来解决这个问题。Redis的AOF持久化机制执行重写后，保存的只是恢复数据的最小指令集，我们如果想手动触发可以使用如下指令

bgrewriteaof

Redis4.0后的重写使用的是RDB快照和AOF指令拼接的方式，在AOF文件的头部是RDB快照的二进制形式的数据，尾部是快照产生后发生的写入操作的指令。 由于重写AOF文件时，会对Redis的性能带来一定的影响，因此也不能随便的进行自动重写，Redis提供两个配置用于自动进行AOF重写的指标，只有这两个指标同时满足的时候才会发生重写：

auto-aof-rewrite-percentage 100：指的是当文件的内存达到原先内存的两倍

auto-aof-rewrite-min-size 64mb：指的是文件重写的最小内存大小

此外Redis4.0后大部分的使用场景都不会单独使用RDB或者AOF来做持久化机制，而是兼顾二者的优势混合使用。 最后来总结这两者，到底用哪个更好呢？

• 推荐是两者均开启

• 如果对数据不敏感，可以选单独用RDB

• 不建议单独用AOF，因为可能会出现Bug

• 如果只是做纯内存缓存，可以都不用

这个我的理解大致是这样的面试官！！

Redis是基于内存存储的key-value数据库，我们知道内存虽然快但空间小，当物理内存达到上限时，系统就会跑的很慢，所以我们会设置Redis的最大内存，当Redis内存达到设定阈值的时候会触发内存回收，Redis提供了很多内存淘汰策略：

• **noeviction：**当达到内存限制并且客户端尝试执行可能导致使用更多内存的命令时返回错误，简单来说读操作仍然允许，但是不准写入新的数据，del（删除）请求可以。

• **allkeys-lru：**从全体key中，通过lru（Least Recently Used - 最近最少使用）算法进行淘汰

• **allkeys-random：**从全体key中，随机进行淘汰

• **volatile-lru：**从设置了过期时间的全部key中，通过lru（Least Recently Used - 最近最少使用）算法进行淘汰，这样可以保证未设置过期时间需要被持久化的数据，不会被选中淘汰

• **volatile-random：**从设置了过期时间的全部key中，随机进行淘汰

• **volatile-ttl：**从设置了过期时间的全部key中，通过比较key的剩余过期时间TTL的值，TTL越小越先被淘汰

• **volatile-lfu：**对有过期时间的key采用LFU淘汰算法

• **allkeys-lfu：**对全部key采用LFU淘汰算法

在这些策略中有两个比较重要的算法一个是LRU，也就是淘汰最近最少使用的key。不过Redis使用了近似LRU算法，并不是完完全全准确的淘汰掉最近最不经常使用的key，但是总体的准确度也可以得到保证。近似LRU算法非常简单，在Redis的key对象中，增加24bit用于存储最近一次访问的系统时间戳，当客户端对Redis服务端发送key的写入相关请求时，发现内存达到maxmemory，此时触发惰性删除；Redis服务通过随机采样，选择5个满足条件的key（注意这个随机采样allkeys-lru是从所有的key中随机采样，volatile-lru是从设置了过期时间的所有key中随机采样），通过key对象中记录的最近访问时间戳进行比较，淘汰掉这5个key中最旧的key；如果内存仍然不够，就继续重复这个步骤。在Redis 3.0 maxmemory_samples设置为10的时候，Redis的近似LRU算法已经非常的接近真实LRU算法了，但是显然maxmemory_samples设置为10比maxmemory_samples 设置为5要更加消耗CPU计算时间，因为每次采样的样本数据增大，计算时间也会增加。Redis3.0的LRU比Redis2.8的LRU算法更加准确，是因为Redis3.0增加了一个与maxmemory_samples相同大小的淘汰池，每次淘汰key的时候，先与淘汰池中等待被淘汰的key进行比较，最后淘汰掉最老旧的key，其实就是被选中淘汰的key放到一起再比较一下，淘汰其中最旧的。 ​

LRU有一个明显的缺点，它无法正确的表示一个Key的热度，如果一个key从未被访问过，仅仅发生内存淘汰的前一会儿被用户访问了一下，在LRU算法中这会被认为是一个热key。LFU(Least Frequently Used)是Redis 4.0 引入的淘汰算法，它通过key的访问频率比较来淘汰key，重点突出的是Frequently Used。 ​

LRU与LFU的区别：

• LRU -> Recently Used，根据最近一次访问的时间比较

• LFU -> Frequently Used，根据key的访问频率比较

在LFU模式下，Redis对象头的24bit lru字段被分成两段来存储，高16bit存储ldt(Last Decrement Time)，低8bit存储logc(Logistic Counter)。高16bit用来记录最近一次计数器降低的时间，由于只有8bit，存储的是Unix分钟时间戳取模2^16，16bit能表示的最大值为65535（65535/24/60≈45.5），大概45.5天会折返（折返指的是取模后的值重新从0开始）。低8位用来记录访问频次，8bit能表示的最大值为255，logc肯定无法记录真实的Rediskey的访问次数，其实从名字可以看出存储的是访问次数的对数值，每个新加入的key的logc初始值为5（LFU_INITI_VAL），这样可以保证新加入的值不会被首先选中淘汰；logc每次key被访问时都会更新；此外，logc会随着时间衰减。 Logistic Counter不仅会增长，也会衰弱，增长和衰弱的规则也可以通过redis.conf进行配置。

• lfu-log-factor 用于调整Logistic Counter的增长速度，lfu-log-factor值越大，Logistic Counter增长越慢。

• lfu-decay-time 用于调整Logistic Counter的衰减速度，它是一个以分钟为单位的数值，默认值为1,；lfu-decay-time值越大，衰减越慢。

这个我的理解大致是这样的面试官！！

缓存击穿： 就是说某个访问非常频繁的热点 key ，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，直接穿过了Redis。

最后

小编在这里分享些我自己平时的学习资料，由于篇幅限制，pdf文档的详解资料太全面，细节内容实在太多啦，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！

程序员代码面试指南 IT名企算法与数据结构题目最优解

这是” 本程序员面试宝典!书中对IT名企代码面试各类题目的最优解进行了总结，并提供了相关代码实现。针对当前程序员面试缺乏权威题目汇总这一-痛点， 本书选取将近200道真实出现过的经典代码面试题，帮助广“大程序员的面试准备做到万无一失。 “刷”完本书后，你就是“题王”!

《TCP-IP协议组(第4版)》

本书是介绍TCP/IP协议族的经典图书的最新版本。本书自第1版出版以来，就广受读者欢迎。

本书最新版进行」护元，以体境计算机网络技不的最新发展，全书古有七大部分共30草和7个附录:第一部分介绍一些基本概念和基础底层技术:第二部分介绍网络层协议:第三部分介绍运输层协议;第四部分介绍应用层协议:第五部分介绍下一代协议，即IPv6协议:第六部分介绍网络安全问题:第七部分给出了7个附录。

Java开发手册（嵩山版）

这个不用多说了，阿里的开发手册，每次更新我都会看，这是8月初最新更新的**（嵩山版）**

MySQL 8从入门到精通

本书主要内容包括MySQL的安装与配置、数据库的创建、数据表的创建、数据类型和运算符、MySQL 函数、查询数据、数据表的操作(插入、更新与删除数据)、索引、存储过程和函数、视图、触发器、用户管理、数据备份与还原、MySQL 日志、性能优化、MySQL Repl ication、MySQL Workbench、 MySQL Utilities、 MySQL Proxy、PHP操作MySQL数据库和PDO数据库抽象类库等。最后通过3个综合案例的数据库设计，进步讲述 MySQL在实际工作中的应用。

Spring5高级编程（第5版）

本书涵盖Spring 5的所有内容，如果想要充分利用这一领先的企业级 Java应用程序开发框架的强大功能，本书是最全面的Spring参考和实用指南。

本书第5版涵盖核心的Spring及其与其他领先的Java技术(比如Hibemate JPA 2.Tls、Thymeleaf和WebSocket)的集成。本书的重点是介绍如何使用Java配置类、lambda 表达式、Spring Boot以及反应式编程。同时，将与企业级应用程序开发人员分享一些见解和实际经验，包括远程处理、事务、Web 和表示层，等等。

JAVA核心知识点+1000道 互联网Java工程师面试题

企业IT架构转型之道 阿里巴巴中台战略思想与架构实战

本书讲述了阿里巴巴的技术发展史，同时也是-部互联网技 术架构的实践与发展史。

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

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

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

[外链图片转存中…(img-VuqtvFyF-1713425739123)]

企业IT架构转型之道 阿里巴巴中台战略思想与架构实战

本书讲述了阿里巴巴的技术发展史，同时也是-部互联网技 术架构的实践与发展史。

[外链图片转存中…(img-XA7CnaGh-1713425739123)]

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

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-m47AbEuG-1713425739123)]

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