Java后端面试高频问题：Redis。你会怎么回答？(1)，2024Java大厂面试题来袭

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

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

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

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

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

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

正文

• 避免过多的上下文切换开销。程序始终运行在进程中单个线程内，没有多线程切换的场景。

• 避免同步机制的开销：如果 Redis选择多线程模型，需要考虑数据同步的问题，则必然会引入某些同步机制，会导致在操作数据过程中带来更多的开销，增加程序复杂度的同时还会降低性能。

• 实现简单，方便维护：如果 Redis使用多线程模式，那么所有的底层数据结构的设计都必须考虑线程安全问题，那么 Redis 的实现将会变得更加复杂。

Redis6.0为何引入多线程？

---

Redis支持多线程主要有两个原因：

• 可以充分利用服务器 CPU 资源，单线程模型的主线程只能利用一个cpu；

• 多线程任务可以分摊 Redis 同步 IO 读写的负荷。

Redis应用场景有哪些？

---

• 缓存热点数据，缓解数据库的压力。

• 利用 Redis 原子性的自增操作，可以实现计数器的功能，比如统计用户点赞数、用户访问数等。

• 简单的消息队列，可以使用Redis自身的发布/订阅模式或者List来实现简单的消息队列，实现异步操作。

• 限速器，可用于限制某个用户访问某个接口的频率，比如秒杀场景用于防止用户快速点击带来不必要的压力。

• 好友关系，利用集合的一些命令，比如交集、并集、差集等，实现共同好友、共同爱好之类的功能。

Memcached和Redis的区别？

---

• Redis 只使用单核，而 Memcached 可以使用多核。

• MemCached 数据结构单一，仅用来缓存数据，而 Redis 支持多种数据类型。

• MemCached 不支持数据持久化，重启后数据会消失。Redis 支持数据持久化。

• Redis 提供主从同步机制和 cluster 集群部署能力，能够提供高可用服务。Memcached 没有提供原生的集群模式，需要依靠客户端实现往集群中分片写入数据。

• Redis 的速度比 Memcached 快很多。

• Redis 使用单线程的多路 IO 复用模型，Memcached使用多线程的非阻塞 IO 模型。

Redis 数据类型有哪些？

---

基本数据类型：

• String：最常用的一种数据类型，String类型的值可以是字符串、数字或者二进制，但值最大不能超过512MB。

• Hash：Hash 是一个键值对集合。

• Set：无序去重的集合。Set 提供了交集、并集等方法，对于实现共同好友、共同关注等功能特别方便。

• List：有序可重复的集合，底层是依赖双向链表实现的。

• SortedSet：有序Set。内部维护了一个score的参数来实现。适用于排行榜和带权重的消息队列等场景。

特殊的数据类型：

• Bitmap：位图，可以认为是一个以位为单位数组，数组中的每个单元只能存0或者1，数组的下标在 Bitmap 中叫做偏移量。Bitmap的长度与集合中元素个数无关，而是与基数的上限有关。

• Hyperloglog。HyperLogLog 是用来做基数统计的算法，其优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。典型的使用场景是统计独立访客。

• Geospatial ：主要用于存储地理位置信息，并对存储的信息进行操作，适用场景如定位、附近的人等。

keys命令存在的问题？

---

redis的单线程的。keys指令会导致线程阻塞一段时间，直到执行完毕，服务才能恢复。scan采用渐进式遍历的方式来解决keys命令可能带来的阻塞问题，每次scan命令的时间复杂度是O(1)，但是要真正实现keys的功能，需要执行多次scan。

scan的缺点：在scan的过程中如果有键的变化（增加、删除、修改），遍历过程可能会有以下问题：新增的键可能没有遍历到，遍历出了重复的键等情况，也就是说scan并不能保证完整的遍历出来所有的键。

SortedSet和List异同点？

---

相同点：

• 都是有序的；

• 都可以获得某个范围内的元素。

不同点：

• 列表基于链表实现，获取两端元素速度快，访问中间元素速度慢；

• 有序集合基于散列表和跳跃表实现，访问中间元素时间复杂度是OlogN；

• 列表不能简单的调整某个元素的位置，有序列表可以（更改元素的分数）；

• 有序集合更耗内存。

Redis事务

---

事务的原理是将一个事务范围内的若干命令发送给Redis，然后再让Redis依次执行这些命令。

事务的生命周期：

1. 使用MULTI开启一个事务

2. 在开启事务的时候，每次操作的命令将会被插入到一个队列中，同时这个命令并不会被真的执行

3. EXEC命令进行提交事务

一个事务范围内某个命令出错不会影响其他命令的执行，不保证原子性：

WATCH命令

WATCH命令可以监控一个或多个键，一旦其中有一个键被修改，之后的事务就不会执行（类似于乐观锁）。执行EXEC命令之后，就会自动取消监控。

比如上面的代码中：

1. watch name开启了对name这个key的监控

2. 修改name的值

3. 开启事务a

4. 在事务a中设置了name和gender的值

5. 使用EXEC命令进提交事务

6. 使用命令get gender发现不存在，即事务a没有执行

使用UNWATCH可以取消WATCH命令对key的监控，所有监控锁将会被取消。

持久化机制

---

持久化就是把内存的数据写到磁盘中，防止服务宕机导致内存数据丢失。

Redis支持两种方式的持久化，一种是RDB的方式，一种是AOF的方式。前者会根据指定的规则定时将内存中的数据存储在硬盘上，而后者在每次执行完命令后将命令记录下来。一般将两者结合使用。

RDB方式

RDB是 Redis 默认的持久化方案。RDB持久化时会将内存中的数据写入到磁盘中，在指定目录下生成一个dump.rdb文件。Redis 重启会加载dump.rdb文件恢复数据。

bgsave是主流的触发 RDB 持久化的方式，执行过程如下：

1. 执行BGSAVE命令Redis

2. 父进程判断当前是否存在正在执行的子进程，如果存在，BGSAVE命令直接返回。

3. 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞。

4. 父进程fork完成后，父进程继续接收并处理客户端的请求，而子进程开始将内存中的数据写进硬盘的临时文件；

5. 当子进程写完所有数据后会用该临时文件替换旧的 RDB 文件。

Redis启动时会读取RDB快照文件，将数据从硬盘载入内存。通过 RDB 方式的持久化，一旦Redis异常退出，就会丢失最近一次持久化以后更改的数据。

触发 RDB 持久化的方式：

1. 手动触发：用户执行SAVE或BGSAVE命令。SAVE命令执行快照的过程会阻塞所有客户端的请求，应避免在生产环境使用此命令。BGSAVE命令可以在后台异步进行快照操作，快照的同时服务器还可以继续响应客户端的请求，因此需要手动执行快照时推荐使用BGSAVE命令。

2. 被动触发：

• 根据配置规则进行自动快照，如SAVE 100 10，100秒内至少有10个键被修改则进行快照。如果

• 从节点执行全量复制操作，主节点会自动执行BGSAVE生成 RDB 文件并发送给从节点。

• 默认情况下执行shutdown命令时，如果没有开启 AOF 持久化功能则自动执行·BGSAVE·。

优点：

Redis 加载 RDB 恢复数据远远快于 AOF 的方式。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 Redis 的高性能。

缺点：

• RDB方式数据无法做到实时持久化。因为BGSAVE每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本比较高。

• RDB 文件使用特定二进制格式保存，Redis 版本升级过程中有多个格式的 RDB 版本，存在老版本 Redis 无法兼容新版 RDB 格式的问题。

AOF方式

AOF（append only file）持久化：以独立日志的方式记录每次写命令，Redis重启时会重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，AOF 是Redis持久化的主流方式。

默认情况下Redis没有开启AOF方式的持久化，可以通过appendonly参数启用：appendonly yes。开启AOF方式持久化后每执行一条写命令，Redis就会将该命令写进aof_buf缓冲区，AOF缓冲区根据对应的策略向硬盘做同步操作。

默认情况下系统每30秒会执行一次同步操作。为了防止缓冲区数据丢失，可以在Redis写入AOF文件后主动要求系统将缓冲区数据同步到硬盘上。可以通过appendfsync参数设置同步的时机。

appendfsync always //每次写入aof文件都会执行同步，最安全最慢，不建议配置

appendfsync everysec //既保证性能也保证安全，建议配置

appendfsync no //由操作系统决定何时进行同步操作

接下来看一下 AOF 持久化执行流程：

1. 所有的写入命令会追加到 AOP 缓冲区中。

2. AOF 缓冲区根据对应的策略向硬盘同步。

3. 随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩文件体积的目的。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。

4. 当 Redis 服务器重启时，可以加载 AOF 文件进行数据恢复。

优点：

• AOF可以更好的保护数据不丢失，可以配置 AOF 每秒执行一次fsync操作，如果Redis进程挂掉，最多丢失1秒的数据。

• AOF以append-only的模式写入，所以没有磁盘寻址的开销，写入性能非常高。

缺点：

• 对于同一份文件AOF文件比RDB数据快照要大。

• 数据恢复比较慢。

RDB和AOF如何选择？

---

通常来说，应该同时使用两种持久化方案，以保证数据安全。

• 如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化。

• 如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可。

• 如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启。

• 如果只用AOF，优先使用everysec的配置选择，因为它在可靠性和性能之间取了一个平衡。

当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整。

Redis常见的部署方式有哪些？

---

Redis的几种常见使用方式包括：

• 单机版

• Redis主从

• Redis Sentinel（哨兵）

• Redis Cluster

使用场景：

• 单机版：很少使用。存在的问题：1、内存容量有限 2、处理能力有限 3、无法高可用。

• 主从模式：master 节点挂掉后，需要手动指定新的 master，可用性不高，基本不用。

• 哨兵模式：master 节点挂掉后，哨兵进程会主动选举新的 master，可用性高，但是每个节点存储的数据是一样的，浪费内存空间。数据量不是很多，集群规模不是很大，需要自动容错容灾的时候使用。

• Redis cluster：主要是针对海量数据+高并发+高可用的场景，如果是海量数据，如果你的数据量很大，那么建议就用Redis cluster，所有主节点的容量总和就是Redis cluster可缓存的数据容量。

主从复制

Redis的复制功能是支持多个数据库之间的数据同步。主数据库可以进行读写操作，当主数据库的数据发生变化时会自动将数据同步到从数据库。从数据库一般是只读的，它会接收主数据库同步过来的数据。一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

redis-server //启动Redis实例作为主数据库

redis-server --port 6380 --slaveof 127.0.0.1 6379 //启动另一个实例作为从数据库

slaveof 127.0.0.1 6379

SLAVEOF NO ONE //停止接收其他数据库的同步并转化为主数据库。

主从复制的原理？

1. 当启动一个从节点时，它会发送一个 PSYNC 命令给主节点；

2. 如果是从节点初次连接到主节点，那么会触发一次全量复制。此时主节点会启动一个后台线程，开始生成一份 RDB 快照文件；

3. 同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， 主节点会将RDB文件发送给从节点，从节点会先将RDB文件写入本地磁盘，然后再从本地磁盘加载到内存中；

4. 接着主节点会将内存中缓存的写命令发送到从节点，从节点同步这些数据；

5. 如果从节点跟主节点之间网络出现故障，连接断开了，会自动重连，连接之后主节点仅会将部分缺失的数据同步给从节点。

哨兵Sentinel

主从复制存在不能自动故障转移、达不到高可用的问题。哨兵模式解决了这些问题。通过哨兵机制可以自动切换主从节点。

客户端连接Redis的时候，先连接哨兵，哨兵会告诉客户端Redis主节点的地址，然后客户端连接上Redis并进行后续的操作。当主节点宕机的时候，哨兵监测到主节点宕机，会重新推选出某个表现良好的从节点成为新的主节点，然后通过发布订阅模式通知其他的从服务器，让它们切换主机。

工作原理

1. 每个Sentinel以每秒钟一次的频率向它所知道的Master，Slave以及其他 Sentinel实例发送一个 PING命令。

2. 如果一个实例距离最后一次有效回复 PING 命令的时间超过指定值， 则这个实例会被 Sentine 标记为主观下线。

3. 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel要以每秒一次的频率确认Master是否真正进入主观下线状态。

4. 当有足够数量的 Sentinel（大于等于配置文件指定值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。若没有足够数量的 Sentinel同意 Master 已经下线， Master 的客观下线状态就会被解除。 若 Master重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

5. 哨兵节点会选举出哨兵 leader，负责故障转移的工作。

6. 哨兵 leader 会推选出某个表现良好的从节点成为新的主节点，然后通知其他从节点更新主节点信息。

Redis cluster

哨兵模式解决了主从复制不能自动故障转移、达不到高可用的问题，但还是存在主节点的写能力、容量受限于单机配置的问题。而cluster模式实现了Redis的分布式存储，每个节点存储不同的内容，解决主节点的写能力、容量受限于单机配置的问题。

Redis cluster集群节点最小配置6个节点以上（3主3从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

Redis cluster采用虚拟槽分区，所有的键根据哈希函数映射到0～16383个整数槽内，每个节点负责维护一部分槽以及槽所映射的键值数据。

哈希槽是如何映射到 Redis 实例上的？

1. 对键值对的key使用 crc16 算法计算一个结果将结果

2. 对 16384 取余，得到的值表示 key 对应的哈希槽

3. 根据该槽信息定位到对应的实例

优点：

• 无中心架构，支持动态扩容；

• 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布；

• 高可用性。部分节点不可用时，集群仍可用。集群模式能够实现自动故障转移（failover），节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色转换。

缺点：

• 不支持批量操作（pipeline）。

• 数据通过异步复制，不保证数据的强一致性。

• 事务操作支持有限，只支持多key在同一节点上的事务操作，当多个key分布于不同的节点上时无法使用事务功能。

• key作为数据分区的最小粒度，不能将一个很大的键值对象如hash、list等映射到不同的节点

• 不支持多数据库空间，单机下的Redis可以支持到16个数据库，集群模式下只能使用1个数据库空间。

哈希分区算法有哪些？

节点取余分区

使用特定的数据，如Redis的键或用户ID，对节点数量N取余：hash（key）%N计算出哈希值，用来决定数据映射到哪一个节点上。优点是简单性。扩容时通常采用翻倍扩容，避免数据映射全部被打乱导致全量迁移的情况。

一致性哈希分区

为系统中每个节点分配一个token，范围一般在0~232，这些token构成一个哈希环。数据读写执行节点查找操作时，先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点。这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中相邻的节点，对其他节点无影响。

虚拟槽分区

所有的键根据哈希函数映射到0~16383整数槽内，计算公式：slot=CRC16（key）&16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。Redis Cluser采用虚拟槽分区算法。

过期键的删除策略？

---

• 被动删除。在访问key时，如果发现key已经过期，那么会将key删除。

• 主动删除。定时清理key，每次清理会依次遍历所有DB，从db随机取出20个key，如果过期就删除，如果其中有5个key过期，那么就继续对这个db进行清理，否则开始清理下一个db。

• 内存不够时清理。Redis有最大内存的限制，通过maxmemory参数可以设置最大内存，当使用的内存超过了设置的最大内存，就要进行内存释放， 在进行内存释放的时候，会按照配置的淘汰策略清理内存。

内存淘汰策略有哪些？

---

当Redis的内存超过最大允许的内存之后，Redis 会触发内存淘汰策略，删除一些不常用的数据，以保证Redis服务器正常运行。

Redis4.0前提供 6 种数据淘汰策略：

Ending

Tip：由于文章篇幅有限制，下面还有20个关于MySQL的问题，我都复盘整理成一份pdf文档了，后面的内容我就把剩下的问题的目录展示给大家看一下

如果觉得有帮助不妨【转发+点赞+关注】支持我，后续会为大家带来更多的技术类文章以及学习类文章！（阿里对MySQL底层实现以及索引实现问的很多）

吃透后这份pdf，你同样可以跟面试官侃侃而谈MySQL。其实像阿里p7岗位的需求也没那么难（但也不简单），扎实的Java基础+无短板知识面+对某几个开源技术有深度学习+阅读过源码+算法刷题，这一套下来p7岗差不多没什么问题，还是希望大家都能拿到高薪offer吧。

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

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

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
p：由于文章篇幅有限制，下面还有20个关于MySQL的问题，我都复盘整理成一份pdf文档了，后面的内容我就把剩下的问题的目录展示给大家看一下**

如果觉得有帮助不妨【转发+点赞+关注】支持我，后续会为大家带来更多的技术类文章以及学习类文章！（阿里对MySQL底层实现以及索引实现问的很多）

[外链图片转存中…(img-2UMN22Sn-1713058602305)]

[外链图片转存中…(img-2NrWkrJq-1713058602305)]

吃透后这份pdf，你同样可以跟面试官侃侃而谈MySQL。其实像阿里p7岗位的需求也没那么难（但也不简单），扎实的Java基础+无短板知识面+对某几个开源技术有深度学习+阅读过源码+算法刷题，这一套下来p7岗差不多没什么问题，还是希望大家都能拿到高薪offer吧。

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

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

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