一篇总结Redis面试题知识点

KayliZ

已于 2024-08-16 11:19:50 修改

阅读量1.7k

点赞数 61

分类专栏： Redis面试知识点文章标签： redis java

于 2024-08-15 10:00:00 首次发布

本文链接：https://blog.csdn.net/Kayli64679/article/details/141201925

版权

Redis面试知识点专栏收录该内容

1 篇文章 1 订阅

订阅专栏

为什么要使用Redis

使用Redis主要是因为Redis的三大特性，高可靠高并发高性能。在请求访问数据时，如果直接从数据库中获取数据，它的并发量可能只有1000次/秒，这已经算是很不错的表现。如果在程序启动的时候就将数据放到Redis中，数据访问时如果直接从缓存中读取，他的性能以及并发量会明显提高很多，再加上Redis的主从集群部署和哨兵机制也保证了Redis的可靠性。（延伸主从集群和哨兵的机制）

Redis和数据库双写的时候如何保持数据一致

1.先更新DB再更新缓存或者先更新缓存再更新DB（不可行）

先更新缓存再更新DB或者先更新DB再更新缓存都会因为延迟的原因导致产生一些脏数据或者导致缓存和数据库的数据不一致。如果先更新DB再更新缓存，在更新期间，如果前面有请求打到了缓存上，这时候就会返回旧的数据，如果先更新缓存再更新DB，缓存更新成功了但是DB更新失败了，请求发到缓存的时候返回的新数据，导致很难察觉到DB没有更新成功导致数据不一致

2.先删除缓存，再更新DB，

这个策略会出现并发的场景，当两个请求同时来的时候，一个请求去删除缓存然去数据库更新，这时候又来了一个请求打到了缓存上，发现没有缓存就去DB更新，DB还没有更新完成，这时候第二个请求就去数据库把旧的数据更新到了缓存里，导致缓存里面还是旧的数据。

解决方法（延迟双删）

先删除缓存然后再去更新DB，更新完DB之后延迟一下，具体的延迟要看情况来决定，延迟一段时间后再删除缓存，如果删除失败，可以通过消息队列机制进行重试。不能保证百分百的没有脏数据

归纳总结

一般采用删除缓存类的操作，因为会避免很多问题

因为缓存删除或者缓存更新的操作会比在DB中的操作要快一些，所以一般会采用先更新数据库再去删除缓存，这样的话只有查询操作比删除慢的时候才会出现数据不一致的问题，但是这种情况相对是比较少的，再结合延迟双删的策略，可以很大程度上避免数据的不一致。

为什么要把数据存到内存中

首先如果将数据存储在磁盘上，系统首先需要从磁盘中读取数据，然后加载到内存中，再从内存中调用。这种方式的查询速度相比直接将数据存储在内存中要慢得多，虽然并没有差太多但是当数据量大或者并发量一多的时候还是会影响性能的。

最终内存数据持久化不是还要存储到磁盘不会更耗费时间吗

Redis在查询内存中的数据的时候他是以一个单线程的形式去查询的，但是在对数据进行持久化的时候会采用异步的方式去对数据进行持久化，所以实际上对于我们这个内存没有影响。

Redis的过期淘汰策略

Redis中的数据在设置了一个过期时间之后并不一定会直接被刷掉。分为三种策略

惰性过期

其中有惰性过期，就是在当过期时间到的时候并不一定会直接把数据删除掉，会等到一个请求访问数据的时候判断这个key有没有到过期时间，如果没有过期的话直接返回不管，如果过期的话会进入下一步判断他是否是master节点，只有在master节点的时候他才会去分出两个线程，一个同步的一个异步的去做删除的操作。

定时过期

定时过期的话会有一个后台的线程去跑，他会去监控数据有没有设置过期时间，如果有过期时间的话，涉及的一个Hash桶的概念，一次去拿一定数量的key，然后把其中过期的数据给删除掉。删除完之后不会直接结束，会判断一下如有没有拿到过期的数据或者拿到的过期的数据是否超过了百分之十，就是说没拿到或者拿到的过期的数据很多，他都会去立马再跑一遍，再去拿一遍数据，然后删除过期的，最多循环16次且时间大于 25ms。

内存淘汰策略

当Redis的使用内存达到上限的时候，会根据配置的淘汰策略来删除部分的key，具体如下。

Redis的内存淘汰策略

内存淘汰策略一共八种

1.noevication默认，不淘汰，对于一些没用的数据也不会去管他，一直堆着等到内存满的时候会报错

2.ttl 根据过期的时间，到过期时间之后就会把过期的数据给删除掉

3.LRU，RANDOM，LFU其中每种都分为allkey和volatile

常用的一般就是LRU和LFU，一般的淘汰策略FIFO就是一个FIFO链表，在存储到达限制的时候，新插入的数据会把最老的数据给挤掉，Redis是没有这种策略的。

LRU就是在FIFO的基础上，如果在此期间，有数据被调用，就会把这个数据挪到头部去，避免热点数据被刷掉。但是新插入的数据可能还没来得及被访问就被淘汰了，因此需要进一步改进。比如新插入的数据不会给他放到头部，而是给他放到后端偏尾部的位置，主要是为了避免他新增还没被访问就被刷掉，然后被调用的数据也不会直接给他放到头部，会根据他的这个调用次数给他进行排序，调用次数越多的就给他放的越靠前。

LFU既最不经常使用，它通过记录每个缓存项的使用频率来决定哪些数据应被淘汰。当缓存空间不足时，LFU 会优先移除那些使用频率最低的数据。相比于其他策略，LFU 更适合用于数据访问频率有明显差异的场景，能更有效地保留高频访问的数据，从而提高缓存命中率。

Redis的基本类型和应用场景

Redis一共有五大基本类型，分别是String，List，Hash，Set，Z Set

List就是做列表，一般用来做一些文章列表消息队列之类的

Set是一个无序的集合，里面是可以有交集并集差集的应用的，可以做一些标签，抽奖之类的场景

Zset是有序的集合，一般适用于一些需要排序的比如排行榜，时间播放量之类的场景

String就是字符串类型，一般用来存缓存，分布式Id，还有分布式锁

Hash一般用来存储一些对象类数据，统计类的数据，或者购物车，也同样可以用来存分布式锁

Redis为什么快

1.纯内存访问，不涉及到磁盘的交互

2.Redis是单线程的，避免了上下文的切换

3.采用了合理的数据结构，合理的分配内存的空间

4.多路复用epo||模型

5.渐进式ReHash，缓存时间戳等设计

Redis持久化的方式有哪些

Redis的持久化分两种一种是AOF（追加命令）一种是RDB（内存快照）

AOF会先去看有没有配置appendonly和appendfilename，如果有的话就会开启一个AOF，AOF默认有三种策略。

一种always，就是在每个命令执行完毕之后就会立马同步日志到磁盘。

everysec，在执行完一个命令之后先把日志写到缓存区，然后每隔一秒再将缓存区的内容写到磁盘。

还有一个就是no，就是他默认的策略，默认的策略就是每个命令执行完也将数据放到缓存区，由操作系统决定什么时候写入磁盘，通常同步周期不超过30秒。

如果没有去配置AOF他就会默认开启RDB，是基于快照的，但是他有可能会造成数据丢失，可能会有一些影响。

RDB备份分为自动触发和手动触发。自动触发可以通过配置参数save seconds updates，即在指定时间内修改一定次数后自动触发快照。另外，在系统关闭（shutdown）时也会触发快照。主动触发的话用save命令，但是会阻塞主线程，所以不建议去使用，可以用bgsave，可以在后台开启一个线程去将快照写入磁盘。

RDB持久化有哪些优缺点

优点的话Redis加载RDB恢复数据的速度远超于AOF的方式，适用于备份，全量复制的场景。缺点的话，RDB没法做到实时的持久化，因为每次bgsave运行都要创建一个子进程，属于重量级操作，频繁执行的话成本太高了。而且RDB使用特定的二进制格式保存，Redis版本演化的时候有多个RDB版本，老版本的Redis的话可能会无法兼容新版本的RDB格式，数据恢复就会遇到麻烦。

怎么提高缓存的命中率

首先的可以采取缓存预热的方式，在系统启动的时候提前将一些热点数据缓存到内存中。这样的话会避免一些初始的数据一开始没有被命中缓存导致的数据库压力过大。

其次要考虑项目的架构设计合理，如果架构合理的话会提高很多命中率。

什么是缓存击穿？要如何避免？

缓存的话就相当于给数据库的资源前面放一个盾牌，本身数据库是顶不住特别高的并发量或者特别大量的数据操作，所以就需要缓存来挡在前面阻挡请求，让请求从缓存中获取数据，如果有大量的恶意的请求打到缓存上，导致缓存顶不住，就会突然有大量的请求打到DB上，可能会导致DB顶不住甚至直接挂掉，就是缓存击穿。

一般来说的这种恶意的请求都要想办法把他解决掉，要避免缓存被击穿的话，在面对恶意的请求的时候，可以直接在缓存里存入一个空对象，请求来的时候直接把这个空对象给他返回去，就不会造成缓存的压力。但是如果恶意的请求每次查询的对象都不一样的话，这种方法就会导致缓存中有很多多余的空对象数据，带来一些额外的内存消耗。

还有一种布隆过滤器，对于发来的请求先进去看一下，如果有这个数据的话就去查询，没有数据的话直接把请求拒绝掉，这样的话他的内存占用会比较小，也没有很多多余的key，但是同时也会带来一些缺点比如实现起来比较复杂，而且可能存在对请求的误判。