Redis面试题——简化提纯版-备战春招，秋招

最新推荐文章于 2024-10-02 05:39:15 发布

光明_吖吼

最新推荐文章于 2024-10-02 05:39:15 发布

阅读量957

点赞数 11

文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/weixin_64942806/article/details/141609115

版权

1、redis的优缺点

优缺点:

1. 是基于内存存储的, 读写性能快 2. 支持持久化机制 3. 支持多种数据类型 4. 支持事务 5. 支持主从复制 6. redis是单线程的,但是redis6.0是多线程,此时的多线程是处理网络数据的读写和协议解析, redis的命令还是单线程的

缺点: 1. 对结构化的查询支持比较差 2. redis较难支持在线扩容,在集群容量达到上限时在线扩容会比较复杂

2、什么是redis，它的作用是什么？

redis是一个缓存层的组件，由C语言编写，它是通过键值对的形式来存储数据的，redis还提供了多种持久化机制(RDB,AOF)，性能可以达到110000/s 的读取数据以及81000/s的写入数据,redis还提供了主从，哨兵以及集群的搭建方式，可以更方便的横向以及垂直扩展。

作用：主要是用来减轻数据库的压力，比如说可以把数据以键值对的形式存到redis中，后端访问数据库的时候，可以先查询Redis中有没有这个数据，如果有直接取出来，就不用再去访问数据库了。

可以解决数据共享问题，比如说在分布式架构中，或者是微服务项目中，咱们有很多服务，可以把数据放到 redis里面，这些服务就可以共享redis中的数据。

3、Redis持久化是什么？

因为redis是一个将数据存放在内存中的数据库，一旦发生关机或者重启，内存中的数据都会丢失，所以为了能够重启时恢复数据，redis提供了持久化的机制，正常运行的时候根据策略生成持久化文件。在机器重启后，我们就可以通过持久化文件来恢复redis中的数据。

可以通过主从同步来解决？主机挂掉之后，可以让从节点成为主节点

在极端情况下，比如说如果整个机房都停电了，那么主节点和从节点内存中的数据都丢了，这个时候就只能依靠持久化文件来恢复数据，这也是持久化存在的意义。

4、redis的持久化机制

redis是存储在内存中的，当断电时会丢失数据，使用redis持久化机制可以将redis在内存中的数据持久化到磁盘中，防止丢失

redis持久化机制分为rdb和aof

rdb机制： redis内存中的数据每隔一段时间就会将整个内存中的数据生成一个镜像文件保存到本地磁盘中，如果 redis重启则可以直接把保存的镜像文件加载到内存中去

例如： save 900 1 ：在900秒内有一个key发生了改变，就执行rdb持久化机制 save 300 10 ：在300秒内有10个key发生了改变，就执行rdb持久化机制

特点：rdb持久化文件速度较快，而且存储的是二进制文件，传输方便

rdb是每隔一段时间持久化一次，如果修改了数据，但是修改的数据没有达到持久化的条件，此时会导致数据的丢失，无法保证绝对的安全 rdb持久化机制数据恢复的速度快，但是生成镜像文件的速度慢

注意：如果不配置的话，redis磨人的持久化机制是rdb.

aof机制： aof持久化机制是当我们在redis中执行的所有的增删改查命令都会写入到一个aof文件中，redis重启的时候，就会执行该aof文件中所有的命令，来完成数据的恢复

特点：aof写入文件的性能相对于rdb较差，恢复数据慢 aof文件较大，不便于传输 aof的数据安全性比rbd高，但是也不能做到100%数据不丢失

AOF持久化时机 appendfsync always：每执行一个写操作，立即持久化到AOF文件中，性能比较低。每执行一个增删改命令都立即写入aof文件效率低，但是数据的安全性最高 appendfsync everysec：每秒执行一次持久化数据丢失最多丢失1s的数据 appendfsync no：会根据你的操作系统不同，环境的不同，在一定时间内执行一次持久化。

rdb默认持久化机制，aof 非默认持久化机制，redis官方推荐同时开启rdb和aof，同时开启时，数据恢复优先使用aof持久化机制

5、Redis的数据恢复策略是怎么样的？

1.同时配置了RDB和AOF，启动时只加载AOF文件恢复数据，如果AOF文件损坏，那么根据RDB文件恢复数据。

2.只配置RDB，启动时加载RDB持久化文件恢复数据。

3.只配置AOF，重启时加载AOF文件恢复数据。

7、redis的数据一致性问题以及解决方案

对于缓存和数据库的操作，主要有以下两种方式

1.先删除缓存，再更新数据库但这样会导致，先删除缓存，数据库还没有更新成功，此时如果读取缓存，缓存不存在，去数据库中读取到的是旧值，缓存不一致发生。

解决方案：延时双删延时双删的方案的思路是，为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再Sleep 一段时间，然后再次删除缓存。对于Sleep 的时间要对业务读写缓存的时间做出评估，只要Sleep 时间大于读写缓存的时间即可。

流程如下：线程1删除缓存，然后去更新数据库。线程2来读缓存，发现缓存已经被删除，所以直接从数据库中读取，这时候由于线程1还没有更新完成，所以读到的是旧值，然后把旧值写入缓存。

线程1，根据估算的时间，Sleep，由于 Sleep 的时间大于线程2读数据+写缓存的时间，所以缓存被再次删除。如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值。

2.先更新数据库，再删除缓存这个就更明显的问题了，更新数据库成功，如果删除缓存失败或者还没有来得及删除，那么，其他线程从缓存中读取到的就是旧值，还是会发生不一致。

解决方案：消息队列消息队列的思路是，先更新数据库，成功后往消息队列发消息，消费到消息后再删除缓存，借助消息队列的重试机制来实现，达到最终一致性的效果。

8、redis的缓存穿透，击穿，雪崩，倾斜什么情况？以及他们的解决方案

缓存击穿：就是某一个热点数据，缓存中某一时刻失效了，因而大量并发请求打到数据库上，就像被击穿了一样。

解决方案：1）通过synchronized+双重检查机制：某个key只让一个线程查询，阻塞其它线程 2）设置value永不过期 3）使用互斥锁(mutex key)

缓存穿透：出现这种情况是因为恶意频繁查询会对系统造成很大的问题，比如说key不在redis缓存并且数据库中不存在，所以每次查询都会查询数据库从而导致数据库崩溃。

解决方案：1）使用布隆过滤器: 热点数据等场景(具体看使用场景)

缓存雪崩：雪崩指的是多个key查询并且同时出现高并发，缓存中失效或者查不到，然后都去数据库中查询，从而导致数据库的压力突然上升，从而崩溃。

解决方案：1）可以通过缓存reload机制，预先去更新缓存，在即将发生高并发访问前手动触发加载缓存 2）不同的key，设置不同的过期时间，具体值可以根据业务决定，让缓存失效的时间点尽量均匀 3）做二级缓存，或者双缓存策略。比如说设置一个主节点A1为原始缓存，一个从节点A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期，这样就可以保证A1失效后仍然可以通过查询A2来降低数据库的查询压力。

缓存倾斜：又称热点key倾斜，就是一个热点key存在一个redis集群上，结果被访问时，高并发的集中到一台服务器上，从而造成倾斜。

解决方案：1）将一些特别热点的key直接放在客户端进行存储，设置过期时间，过期后再从后台中查询

9、Redis采用的过期策略

redis 主要是基于内存来进行高性能、高并发的读写操作的，而内存是很宝贵而且是有限的，当然是干掉不常用的数据，保留常用的数据了，这是由 redis 的过期策略来决定。

Redis采用的过期策略是惰性删除+定期删除同时使用

惰性删除流程在进行get或setnx等操作时，先检查key是否过期，若过期，删除key，然后执行相应操作；若没过期，直接执行相应操作

定期删除流程（简单而言，对指定个数个库的每一个库随机删除小于等于指定个数个过期key）遍历每个数据库（就是redis.conf中配置的"database"数量，默认为16）检查当前库中的指定个数个key（默认是每个库检查20个key，注意相当于该循环执行20次，循环体时下边的描述）如果当前库中没有一个key设置了过期时间，直接执行下一个库的遍历随机获取一个设置了过期时间的key，检查该key是否过期，如果过期，删除key 判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。

但是实际上这还是有问题的，如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期 key 堆积在内存里，导致 redis 内存块耗尽了，咋整？

答案是：走内存淘汰机制。