Redis面试题

最新推荐文章于 2022-02-10 21:29:56 发布

残剑无名

最新推荐文章于 2022-02-10 21:29:56 发布

阅读量277

点赞数

本文链接：https://blog.csdn.net/qq_37707826/article/details/116600762

版权

持续更新中

一、说一下项目中redis的应用场景

1.五大value类型
2.基本上都是做缓存和分布式锁用
3.为了服务于无状态

二、redis是单线程还是多线程

1.无论什么版本，工作线程就是一个
2.6.X高版本出现了IO多线程
3.（学一下系统IO课，真正理解IO模型变成的时候，由内核的事，从内核把数据搬运到程序里这是第一步，然后，搬运回来的数据的计算式第二步，netty）

redis存在线程安全问题吗？为什么？

redis的操作是原子的，单指令即pipline，一个客户端的指令集和是原子的，lua脚本的方式也是原子的：事务 VS pipline 客户端发来若干条指令开启了事务，指令会在队列中保存，然后提交执行，*

事务的执行时期是原子的，某一条指令失败了下面的继续执行，没有回滚操作，尽量少使用事务，事务内的指令尽量少，尽量快

不要因为技术而技术

遇到缓存穿透吗？

redis中没有数据，必须从DB中查询。宁可加前置的复杂度也要让数据库更加轻盈一些。解决方案：1.null key（不好，占空间） 2.布隆过滤器
串行的缺点：已到达的会在串行队列里，假如查询同一个东西，第一个穿透后面的都会穿透，加入在redis外加了分布式锁就可以及时更新到redis中key null，用一次写回操作避免了多次数据库IO，锁挡住了无效请求和重复请求。

遇到过缓存击穿吗？

缓存击穿即热点key过期（没有被缓存的），数据库有大量的并发，redis没有缓存。解决方案：1.请求redis。2，抢锁（只有发生redis取不到的部分），抢上的访问数据库，并更新redis

如何避免缓存雪崩

击穿只是雪崩的一种情况，雪崩是多个key过期，数据库有大量的并发，redis没有缓存。设置null key会存在大量的无用空间被占用，所以选用布隆过滤器。

缓存是如何回收的，即如何删除过期key

1.后台在轮询的时候，分批分段删除哪些过期key
2.请求的时候判读已经过期过了
尽量的把内存的无用空间回收回来！

缓存是如何淘汰的

淘汰不会产生空白空间
内存空间不足的情况下：
1.淘汰机制里有不允许淘汰
2.淘汰算法：lru；lfu；random；TTL
3，全空间进行淘汰
4.设置过过期key的集合中

如何进行缓存预热？

1.提前把数据塞入redis，但你知道哪些数据是热数据吗?
2.开发逻辑上规避差集（你没缓存的），会造成击穿，穿透，雪崩。加锁
3.一劳永逸，未来也不怕

数据库与缓存不一致如何解决？

1.采用分布式事务解决（意义不大，顶多是读多写少的情况下）
2.Canal binlog是目前普遍接受的一种方式（mysql主从同步同步的就是binlog，canal做的事情就是阉割一下同步的数据，同步到redis）
3.通过MQ的方式同步redis和MySQL（了解）

简述一下主从不一致的问题

1.redis的确默认是弱一致性，redis的主从是异步的同步
2.锁不能用主从的（单实例、分片集群、redlok）-》redisson
3.在配置中提供了必须有多少个client链接能同步，可以配置同步因子，趋向于强一致性
4.wait命令（小心使用）
第三四点有点违背redis的初衷

描述一下redis持久化方式

1.RDB，AOF；主从同步也算持久化之一。（二加一）
2.高版本当中开启AOF，AOF是可以通过执行日志可以得到全部内存数据的方式，但是追求性能
2.1，体积变大，重复无效指令重写，后台用线程把内存的kv生成指令写个新的AOF

Redis也打不住了，万级流量达到DB上怎么办？

456

描述一下Redis持久化原理？

当前线程阻塞服务不聊
异步后台进程完成持久
fork + cow

为什么使用setnx？

1.好东西，原子（不存在的情况下完成创建）
2.如果要做分布式锁，就要用set k v nx ex （不存在，过期时间，避免死锁）

redis中的事务三条指令是什么，以及事务如何处理失败指令？

失败继续执行

redis实现分布式锁的指令

redis持久化机制RDB和AOF

·RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
·AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
·也可以同时开启两种持久化方式，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

RDB的优缺点

优点
1.RDB是一个非常紧凑的文件，保存了某个时间点的数据集，时间间隔可能是几分钟，可以根据需求恢复到不同的时间版本；
RDB适合传输到远端数据中心，适用于灾难恢复。
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的全部工作交给子进程，父进程不需要再做其他IO操作，所以RDB持久化的方式可以最大化Redis的性能。
与AOF相比，在恢复比较大的数据集时，RDB方式会更快一些。
缺点
因为有时间间隔，所以可能会有几分钟的数据丢失
RDB需要经常fork子进程来保存数据集到硬盘上，数据集大时fork非常耗时，导致redis在一些毫秒内不能响应客户请求。AOF也需要fork，但是可以调节重写日志文件的频率来提高数据集的耐久度

AOF的优缺点

优点
使用AOF会让你的redis更加耐久，可以使用不同的fsync策略：1. 无fsync 2.每秒fsync 3.每次写的时候fsync。使用默认的每秒fsync redis的性能依旧很好，一旦出现故障，自多丢失1s的数据
AOF是一个只进行追加的日志文件
redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写：重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的。
AOF的存储有序，保存了对数据库的写入操作，更加易读，导出也很简单
缺点
对于相同的数据集来说，AOF的文件体积通常大于RDB文件的体积
根据所使用的fsync策略，AOF的速度可能会慢于RDB。在处理巨大的写入载入时，RDB可以提供更有保证的最大延迟时间