BATJ 关于 Redis 的高频面试真题

3、缓存预热

缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决思路：

1、直接写个缓存刷新页面，上线时手工操作下；

2、数据量不大，可以在项目启动的时候自动进行加载；

3、定时刷新缓存；

4、缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis 默认的有 6 中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

（1）定时去清理过期的缓存；

（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的 key 是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

5、缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

以参考日志级别设置预案：

（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

（2）警告：有些服务在一段时间内成功率有波动（如在 95~100%之间），可以自动降级或人工降级，并发送告警；

（3）错误：比如可用率低于 90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止 Redis 服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis 出现问题，不去数据库查询，而是直接返回默认值给用户。

[](()三、热点数据和冷数据是什么

1、热点数据，缓存才有价值

对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不高。

对于热点数据，比如我们的某 IM 产品，生日祝福模块，当天的寿星列表，缓存以后可能读取数十万次。

再举个例子，某导航产品，我们将导航信息，缓存以后可能读取数百万次。

2、数据更新前至少读取两次，缓存才有意义

这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。

那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到 Redis 缓存，减少数据库压力。

[](()四、Memcache 与 Redis 的区别都有哪些？

1、存储方式 Memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。Redis 有部分存在硬盘上，redis 可以持久化其数据。

2、数据支持类型 Memcache 所有的值均是简单的字符串，redis 作为其替代者，支持更为丰富的数据类型 ，提供 string，list，set，zset，hash 等数据结构的存储。

3、使用底层模型不同。它们之间底层实现方式以及与客户端之间通信的应用协议不一样。Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

4、 value 值大小不同：Redis 最大可以达到 1gb；memcache 只有 1mb。

5、Redis 的速度比 Memcache 快很多。

6、Redis 支持数据的备份，即 Master-Slave 模式的数据备份。

[](()五、单线程的 redis 为什么这么快

1、纯内存操作

2、单线程操作，避免了频繁的上下文切换

3、采用了非阻塞 I/O 多路复用机制

[](()六、redis 的数据类型，以及每种数据类型的使用场景

回答：一共五种。

1、String

这个其实没啥好说的，最常规的 set/get 操作，value 可以是 String 也可以是数字。一般做一些复杂的计数功能的缓存。

2、hash

这里 value 存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以 cookieId 作为 key，设置 30 分钟为缓存过期时间，能很好的模拟出类似 session 的效果。

3、list

使用 List 的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用 lrange 命令，做基于 redis 的分页功能，性能极佳，用户体验好。本人还用一个场景，很合适—取行情信息。就也是个生产者和消费者的场景。LIST 可以很好的完成排队，先进先出的原则。

4、set

因为 set 堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用 JVM 自带的 Set 进行去重？因为我们的系统一般都是集群部署，使用 JVM 自带的 Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。

另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

5、zset

zset 是 reids 最有特色的数据结构，它类似于 Java 的 SortedSet 和 HashMap 的结合体。一方面它是个 set，保证了内部 value 的唯一性，另一方面它可以给每个 value 赋予一个 score，代表这个 value 的排序权重。内部实现是跳表，关于跳表感兴趣可以看下这篇文章：[数据结构与算法分析：（十）跳表](()

[](()七、redis 的过期策略以及内存淘汰机制

redis 采用的是定期删除+惰性删除策略。

为什么不用定时删除策略?

定时删除,用一个定时器来负责监视 key,过期则自动删除。虽然内存及时释放，但是十分消耗 CPU 资源。

在大并发请求下，CPU 要将时间应用在处理请求，而不是删除 key,因此没有采用这一策略。

定期删除+惰性删除是如何工作的呢?

定期删除，redis 默认每个 100ms 检查，是否有过期的 key,有过期 key 则删除。需要说明的是，redis 不是每个 100ms 将所有的 key 检查一次，而是随机抽取进行检查(如果每隔 100ms,全部 key 进行检查，redis 岂不是卡死)。因此，如果只采用定期删除策略，会导致很多 key 到时间没有删除。

于是，惰性删除派上用场。也就是说在你获取某个 key 的时候，redis 会检查一下，这个 key 如果设置了过期时间，那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除 key。然后你也没即时去请求 key，也就是说惰性删除也没生效。这样，redis 的内存会越来越高。那么就应该采用内存淘汰机制。

在 redis.conf 中有一行配置 maxmemory-policy volatile-lru

该配置就是配内存淘汰策略的(什么，你没配过？ 《一线大厂 Java 面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 好好反省一下自己)

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰。

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰。

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰。

no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错。

ps：如果没有设置 expire 的 key，不满足先决条件(prerequisites); 那么 volatile-lru,、volatile-random 和 volatile-ttl 策略的行为 和 noeviction(不删除) 基本上一致。

[](()八、Redis 为什么是单线程的

官方 FAQ 表示，因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）Redis 利用队列技术将并发访问变为串行访问。

1、绝大部分请求是纯粹的内存操作（非常快速）

2、采用单线程,避免了不必要的上下文切换和竞争条件

3、非阻塞 IO 优点：

（1）速度快，因为数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是 O(1)。

（2）支持丰富数据类型，支持 string，list，set，sorted set，hash。

（3）支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行。

（4）丰富的特性：可用于缓存，消息，按 key 设置过期时间，过期后将会自动删除如何解决 redis 的并发竞争 key 问题同时有多个子系统去 set 一个 key。这个时候要注意什么呢？不推荐使用 redis 的事务机制。因为我们的生产环境，基本都是 redis 集群环境，做了数据分片操作。你一个事务中有涉及到多个 key 操作的时候，这多个 key 不一定都存储在同一个 redis-server 上。因此，redis 的事务机制，十分鸡肋。

a、如果对这个 key 操作，不要求顺序：准备一个分布式锁，大家去抢锁，抢到锁就做 set 操作即可作了。以此类推。

b、利用队列，将 set 方法变成串行访问；redis 遇到高并发，如果保证读写 key 的一致性对 redis 的操作都是具有原子性的，是线程安全的操作，你不用考虑并发问题，redis 内部已经帮你处理好并发的问题了。

[](()九、Redis 常见性能问题和解决方案？

1、Master 最好不要做任何持久化工作，如 RDB 内存快照和 AOF 日志文件。