妈妈再也不担心我面试被Redis问得脸都绿了

长文前排提醒，收藏向前排提醒，素质三连 (转发 + 在看 + 留言) 前排提醒！

前言

Redis 作为一个开源的，高级的键值存储和一个适用的解决方案，已经越来越在构建 「高性能」、「可扩展」 的 Web 应用上发挥着举足轻重的作用。

当今互联网技术架构中 Redis 已然成为了应用得最广泛的中间件之一，它也是中高级后端工程 技术面试 中面试官最喜欢问的工程技能之一，不仅仅要求着我们对 基本的使用 进行掌握，更要深层次地理解 Redis 内部实现 的细节原理。

熟练掌握 Redis，甚至可以毫不夸张地说已经半只脚踏入心仪的公司了。下面我们一起来盘点回顾一下 Redis 的面试经典问题，就不要再被面试官问得 脸都绿了 呀！

• Ps： 我把 重要的知识点 都做成了 图片，希望各位 “用餐愉快”。(不错记得付餐费… 点个赞留个言…)

一、基础篇

什么是 Redis ？

先解释 Redis 基本概念

Redis (Remote Dictionary Server) 是一个使用 C 语言 编写的，开源的 (BSD许可) 高性能 非关系型 (NoSQL) 的 键值对数据库。

简单提一下 Redis 数据结构

Redis 可以存储 键 和 不同类型数据结构值 之间的映射关系。键的类型只能是字符串，而值除了支持最 基础的五种数据类型 外，还支持一些 高级数据类型：

一定要说出一些高级数据结构 (当然你自己也要了解… 下面会说到的别担心)，这样面试官的眼睛才会亮。

Redis 小总结

与传统数据库不同的是 Redis 的数据是 存在内存 中的，所以 读写速度 非常 快，因此 Redis 被广泛应用于 缓存 方向，每秒可以处理超过 10 万次读写操作，是已知性能最快的 Key-Value 数据库。另外，Redis 也经常用来做 分布式锁。

除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis 优缺点

优点

• 读写性能优异， Redis能读的速度是 110000 次/s，写的速度是 81000 次/s。
• 支持数据持久化，支持 AOF 和 RDB 两种持久化方式。
• 支持事务，Redis 的所有操作都是原子性的，同时 Redis 还支持对几个操作合并后的原子性执行。
• 数据结构丰富，除了支持 string 类型的 value 外还支持 hash、set、zset、list 等数据结构。
• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点

• 数据库 容量受到物理内存的限制，不能用作海量数据的高性能读写，因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。
• Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了 系统的可用性。
• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

为什么要用缓存？为什么使用 Redis？

提一下现在 Web 应用的现状

在日常的 Web 应用对数据库的访问中，读操作的次数远超写操作，比例大概在 1:9 到 3:7，所以需要读的可能性是比写的可能大得多的。当我们使用 SQL 语句去数据库进行读写操作时，数据库就会 去磁盘把对应的数据索引取回来，这是一个相对较慢的过程。

使用 Redis or 使用缓存带来的优势

如果我们把数据放在 Redis 中，也就是直接放在内存之中，让服务端直接去读取内存中的数据，那么这样 速度 明显就会快上不少 (高性能)，并且会 极大减小数据库的压力 (特别是在高并发情况下)。

记得是 两个角度 啊… 高性能 和 高并发…

也要提一下使用缓存的考虑

但是使用内存进行数据存储开销也是比较大的，限于成本 的原因，一般我们只是使用 Redis 存储一些 常用和主要的数据，比如用户登录的信息等。

一般而言在使用 Redis 进行存储的时候，我们需要从以下几个方面来考虑：

• 业务数据常用吗？命中率如何？ 如果命中率很低，就没有必要写入缓存；
• 该业务数据是读操作多，还是写操作多？ 如果写操作多，频繁需要写入数据库，也没有必要使用缓存；
• 业务数据大小如何？ 如果要存储几百兆字节的文件，会给缓存带来很大的压力，这样也没有必要；

在考虑了这些问题之后，如果觉得有必要使用缓存，那么就使用它！

使用缓存会出现什么问题？

一般来说有如下几个问题，回答思路遵照 是什么 → 为什么 → 怎么解决：

1. 缓存雪崩问题；
2. 缓存穿透问题；
3. 缓存和数据库双写一致性问题；

缓存雪崩问题

另外对于 “Redis 挂掉了，请求全部走数据库” 这样的情况，我们还可以有如下的思路：

• 事发前：实现 Redis 的高可用(主从架构 + Sentinel 或者 Redis Cluster)，尽量避免 Redis 挂掉这种情况发生。
• 事发中：万一 Redis 真的挂了，我们可以设置本地缓存(ehcache) + 限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)
• 事发后：Redis 持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。

缓存穿透问题

缓存与数据库双写一致问题

双写一致性上图还是稍微粗糙了些，你还需要知道两种方案 (先操作数据库和先操作缓存) 分别都有什么优势和对应的问题，这里不作赘述，可以参考一下下方的文章，写得非常详细。

• 面试前必须要知道的Redis面试题 | Java3y - https://mp.weixin.qq.com/s/3Fmv7h5p2QDtLxc9n1dp5A

Redis 为什么早期版本选择单线程？

官方解释

因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是 机器内存的大小 或者 网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。

简单总结一下

1. 使用单线程模型能带来更好的 可维护性，方便开发和调试；
2. 使用单线程模型也能 并发 的处理客户端的请求；(I/O 多路复用机制)
3. Redis 服务中运行的绝大多数操作的 性能瓶颈都不是 CPU；

强烈推荐 各位亲看一下这篇文章：

• 为什么 Redis 选择单线程模型 · Why’s THE Design? - https://draveness.me/whys-the-design-redis-single-thread

Redis 为什么这么快？

简单总结：

1. 纯内存操作：读取不需要进行磁盘 I/O，所以比传统数据库要快上不少；(但不要有误区说磁盘就一定慢，例如 Kafka 就是使用磁盘顺序读取但仍然较快)
2. 单线程，无锁竞争：这保证了没有线程的上下文切换，不会因为多线程的一些操作而降低性能；
3. 多路 I/O 复用模型，非阻塞 I/O：采用多路 I/O 复用技术可以让单个线程高效的处理多个网络连接请求（尽量减少网络 IO 的时间消耗）；
4. 高效的数据结构，加上底层做了大量优化：Redis 对于底层的数据结构和内存占用做了大量的优化，例如不同长度的字符串使用不同的结构体表示，HyperLogLog 的密集型存储结构等等…

二、数据结构篇

简述一下 Redis 常用数据结构及实现？

首先在 Redis 内部会使用一个 RedisObject 对象来表示所有的 key 和 value：

其次 Redis 为了 平衡空间和时间效率，针对 value 的具体类型在底层会采用不同的数据结构来实现，下图展示了他们之间的映射关系：(好像乱糟糟的，但至少能看清楚…)

Redis 的 SDS 和 C 中字符串相比有什么优势？

先简单总结一下

C 语言使用了一个长度为 N+1 的字符数组来表示长度为 N 的字符串，并且字符数组最后一个元素总是 \0，这种简单的字符串表示方式 不符合 Redis 对字符串在安全性、效率以及功能方面的要求。

再来说 C 语言字符串的问题

这样简单的数据结构可能会造成以下一些问题：

• 获取字符串长度为 O(N) 级别的操作 → 因为 C 不保存数组的长度，每次都需要遍历一遍整个数组；
• 不能很好的杜绝 缓冲区溢出/内存泄漏 的问题 → 跟上述问题原因一样，如果执行拼接 or 缩短字符串的操作，如果操作不当就很容易造成上述问题；
• C 字符串 只能保存文本数据 → 因为 C 语言中的字符串必须符合某种编码（比如 ASCII），例如中间出现的 '\0' 可能会被判定为提前结束的字符串而识别不了；

Redis 如何解决的 | SDS 的优势

如果去看 Redis 的源码 sds.h/sdshdr 文件，你会看到 SDS 完整的实现细节，这里简单来说一下 Redis 如何解决的：

1. 多增加 len 表示当前字符串的长度：这样就可以直接获取长度了，复杂度 O(1)；
2. 自动扩展空间：当 SDS 需要对字符串进行修改时，首先借助于 len 和 alloc 检查空间是否满足修改所需的要求