【Java核心能力】饿了么一面：Redis 面试连环炮

欢迎关注公众号（通过文章导读关注：【11来了】），及时收到 AI 前沿项目工具及新技术的推送！

在我后台回复「资料」可领取编程高频电子书！
在我后台回复「面试」可领取硬核面试笔记！

文章导读地址：点击查看文章导读！

感谢你的关注！

饿了么一面：Redis 面试连环炮

Redis用过吗，和本地缓存有啥区别？

Redis 是 分布式缓存 ，本地缓存是 单机缓存 ，那么在分布式系统中，如果将数据放在本地缓存中，其他节点肯定是无法进行访问了

其次就是 本地缓存相对于 Redis 缓存来说会更快 ，因为去 Redis 中查询数据虽然 Redis 基于内存操作比较快，但是应用还需要和 Redis 发起网络 IO ，而使用本地缓存就不需要网络 IO 了，因此本地缓存更快

Redis 的数据结构

Redis 有 5 种 基本数据结构 ：String、List、Hash、Set（无序集合、值唯一）、Zset（有序集合）

我们都知道 Redis 速度是比较快的，因为他是基于内存操作，并且利用 IO 多路复用 来提升处理客户端连接上请求的速度，使用 单线程 处理客户端请求，速度很快

其次呢，Redis 对基本数据结构也做了许多优化 ：

String 底层的 SDS 数据结构优化

字符串底层封装了 SDS 数据结构来实现，没有使用 C 语言默认的字符数组来实现，SDS 内部直接 存储了字符串的长度 len ，因此获取长度的时间复杂度为 O(1)，而 C 语言字符串获取长度需要遍历字符串，时间复杂度为 O(N)，并且 C 语言以 \0 表示字符串结尾，因此无法存储二进制数据，SDS 中记录字符串长度就不需要结尾标识符了，因此 可以存储二进制数据

SDS 中还采用了 空间预分配策略 ，在 SDS 进行空间扩展时，会同时分配 所需空间 和 额外的未使用空间 ，以减少内存再分配次数

listPack 优化

Redis 7.0 之后，zipList 被废弃，转而使用 listPack 来代替，因为 zipList 中存在 级联更新 的问题：

假如 zipList 中每一个 entry 都是很接近但又不到 254B，此时每个 entry 的 prevlength 使用 1 个字节就可以保存上个节点的长度，但是此时如果向 zipList 中间插入一个新的节点，长度大于 254B，那么新插入节点后边的节点需要把 prevlength 扩展为 5B 来存储新插入节点的长度，那么扩展后该节点长度又大于 254B，因此后边节点需要再次扩展 prevlength 来存储该节点的长度，导致了插入节点后边的所有节点都需要更新 prevlength 的值，这属于是极端情况下才会发生

跳表优化

并且使用跳表来优化 Zset 的性能，Zset 底层是通过 压缩列表 + 跳表 来实现的，跳表可以支持平均时间复杂度为 O(logN) 的查询操作

1697874023019

Redis的持久化机制

Redis 持久化机制有 AOF、RDB 和混合持久化三种方式，这就是常规八股文了

要知道这三种持久化方式的区别：

使用 RDB 会进行全量备份，RDB 持久化文件时压缩后的二进制文件，因此加载 RDB 文件的速度是远超 AOF 的，不过缺点就是持久化不及时，可能丢失数据

RDB 持久化有两种方式 save 和 bgsave，save 会导致 Redis 阻塞，bgsave 会利用子进程对数据进行持久化，利用到了 写时复制技术 ，写时复制的优点就是利用单独子进程持久化，不会阻塞

AOF 会进行实时备份，AOF 文件中存储的是 RESP 协议数据格式，会存储 Redis 执行的每一条命令，因此实时性比较强，缺点就是速度比较慢（因为需要将命令刷入磁盘中），AOF 肯定不会对每一条命令都写入到磁盘中，而是会先写入到内存中，再统一刷入到磁盘中，刷盘策略分为三种：always（每条命令都立即刷入磁盘）、everysec（默认，每秒同步一次）、no（Redis 不调用文件同步，而是交给操作系统自己判断同步时机）

AOF 文件过大的话，会进行 重写（Rewrite） 压缩体积，使用重写之后，就会将最新数据记录到 AOF 文件中，比如之前对于 name 属性设置了好多次，AOF 文件中记录了 set name n1，set name n2 …，那么在重写之后，AOF 文件中就直接记录了 set name nn，nn 就是 name 的最新值，通过这样来减小 AOF 文件体积是

混合持久化 （Redis4.0 提出）的话，结合了 RDB 和 AOF，既保证了 Redis 性能，又降低了数据丢失的风险，缺点就是 AOF 文件中包含了 RDB 格式的数据，可读性较差