当前位置: 首页 > article >正文

Java实习生------Redis常见面试题汇总(AOF持久化、RDB快照、分布式锁、缓存一致性)⭐⭐⭐

 “年轻人,就要勇敢追梦”🌹

参考资料:图解redis

目录

谈谈你对AOF持久化的理解?

redis的三种写回策略是什么?

谈谈你对AOF重写机制的理解?AOF重写机制的具体过程?

谈谈你对RDB快照的理解?怎么触发RDB?

redis大key对持久化有什么影响?

如何用redis实现分布式锁?基于 Redis 实现分布式锁的优点与缺点?

数据库和缓存如何保持一致性?


谈谈你对AOF持久化的理解?

  • Redis每执行一次写操作命令,就会以追加的方式写入到一个文件里,这个文件就叫做AOF日志,当redis重启时,再去执行这个文件中的命令,就相当于做了数据恢复。将写操作命令写入到日志文件的过程就是redis的AOF持久化过程。

值得注意的是,redis只会记录写操作,读操作不会记录;另外,redis是先执行完写操作命令,再将这个命令记录到日志中,这么做有两点好处:

  • 避免了额外的检查开销,如果命令是错误的,那么在执行的时候就可以检查出来了,不会往日志中记录一条错误命令
  • 不会阻塞当前命令的执行

但是也有两点坏处:

  • 如果redis在执行这条写命令的时候,redis发生故障宕机,也就是还没来得及将这条命令写入到日志中,所以就会造成数据丢失
  • 可能会阻塞下一条命令的执行

redis的三种写回策略是什么?

AOF日志中的命令还并没有被同步到硬盘,此时这些命令还存在于server.aof_buf缓冲区中

AOF具体有三种写回策略:

  • always:命令写入aof_buf之后就立即调用fsync函数,将AOF数据同步到硬盘。可靠性高,最大程度保证数据不会丢失,但是性能开销比较大
  • no:命令写入aof_buf之后先将命令写入到AOF文件的内核缓冲区,不对AOF文件做fsync同步,同步硬盘操作由操作系统负责。性能好,但是如果宕机会丢失很多数据
  • everysec:命令写入aof_buf之后,先将命令写入到AOF文件的内核缓冲区,然后每隔一秒调用一次fsync函数,将内核缓冲区中的数据同步到硬盘。性能适中,redis宕机会丢失一秒内的数据

谈谈你对AOF重写机制的理解?AOF重写机制的具体过程?

随着执行命令的增多,AOF文件中的命令也越来越多,AOF文件的体积也会越来越大,AOF重写机制的目的就是为了压缩AOF文件的体积。

AOF重写机制的妙处就在于,它会读取数据库中的最新数据,然后仅用一条命令来记录这条数据;也就是说,如果在之前,这条记录被多次修改过,也就意味着有多条修改命令,那么只需要记录最后一条修改不就行了吗?这样就减少了命令的数量,AOF重写机制会把这些最新的命令写入到一个新的AOF文件中,然后覆盖掉原有的AOF文件。

因为AOF重写过程比较耗时,所以一般不会在主进程中执行

开启AOF重写机制之后,主进程会fork出一个子进程,由子进程来执行AOF重写。

这样做的好处有两点:

  • 重写过程由子进程来执行,主进程依旧可以相应客户端命令
  • 主进程和子进程共用一份页表,即主进程和子进程共用一块物理内存

缺点:

  • 主进程在fork子进程的时候,由于要复制一份页表给子进程,所以会造成主进程阻塞
  • 另外,当主进程或者子进程修改共享数据时,会发生写时复制,内核会将物理内存再拷贝一份,也会造成主进程的阻塞

谈谈你对RDB快照的理解?怎么触发RDB?

RDB快照记录了某一瞬间内存中的数据,所以RDB文件记录的是实际的数据,而AOF日志记录的是一条条命令。使用RDB来进行数据恢复的效率要高于AOF,所以RDB是redis的默认持久化方式。

触发机制:两条命令,save和bgsave

  • save:阻塞当前redis服务器,直到RDB过程结束
  • bgsave:主进程fork出一个子进程,阻塞只发生在fork阶段,一般时间很短

redis大key对持久化有什么影响?

大key对AOF日志的影响:

  • 使用always策略:主线程在执行fsync函数时,阻塞的时间比较久
  • 使用no策略:由于永远不会执行fsync函数,所以不会影响主线程
  • 使用everysec策略:由于是异步执行fsync函数,所以大key持久化的过程不会影响主线程

大key对AOF重写和RDB的影响:

  • 创建子进程的过程中父进程会发生阻塞,因为子进程要复制父进程的页表等数据结构
  • 创建完子进程之后父进程也会发生阻塞,如果父进程对大key做了修改,那么内核就会发生写时复制,会把物理内存复制一份,由于大key占用的物理内存比较大,那么在复制物理内存的时候就会很耗时,就会阻塞父进程

如何用redis实现分布式锁?基于 Redis 实现分布式锁的优点与缺点?

分布式锁主要应用于并发环境下,保证某个资源在同一时刻只能被某一个用户所使用

使用 redis 中的 SET NX命令实现分布式锁

SET lock_key unique_value NX PX 10000 

在设置锁的时候,需要满足两个条件:

  • 需要对锁设置过期时间,避免锁被获取之后发生异常,导致客户端无法释放锁
  • 锁变量的值需要能够区分出不同的用户

优点:

  • 性能高效、实现方便(使用SET NX命令)

缺点:

  • 超时时间不好设置:如果设置的时间太长,那么会影响性能;如果设置的时间太短,起不到互斥的作用
  • 可能存在不可靠性:redis基于集群分布的,且主从复制的过程是异步的,可能在redis主节点获取到锁之后,主节点宕机,还没来得及同步,所以在新的redis主节点上依旧可以重新获取锁

数据库和缓存如何保持一致性?

如果先更新数据库,再更新缓存:

此时,数据库中的值是2,而缓存中的值是1,出现了数据库和缓存中的数据不一致的现象! 

如果先更新缓存,再更新数据库:

此时,缓存中的值是2,数据库中的值是1,依旧出现了数据库和缓存中的数据不一致的现象! 

如果先删除缓存,再更新数据库:

 这种情况下,读请求和写请求并发的情况下,出现了数据库和缓存中的数据不一致的问题!

如果先更新数据库,再删除缓存:

 如果但从理论上分析,上述情况依旧导致了数据不一致的问题,但是,值得注意的是,在实际中,这种情况出现的概率并不高,因为写缓存的速度要快于写数据库的速度

所以,先更新数据库,再删除缓存这种方案是可行的。

但是,继续分析,更新数据库和删除缓存,这是两种操作,如果更新数据库成功了,但是删除缓存的时候失败了,那么缓存中缓存的就是旧值,数据库中存放的是新值。怎么保证这两个操作都能顺利执行呢?

解决方案有两种:

重试机制:将要操作的数据加入到消息队列,如果删除缓存失败,那么就重新读取消息,重新执行删除缓存操作;如果删除缓存成功了,就将消息从消息队列中移除。

订阅MySQL binlog:在更新数据库时,会产生一条bin log日志,如果删除缓存失败,就从bin log中拿到具体操作的数据,进行重新删除


 整理面经不易,觉得有帮助的小伙伴点个赞吧~感谢收看!


http://www.kler.cn/a/2188.html

相关文章:

  • WPS工具栏灰色怎么办
  • Yolo11改进策略:Head改进|DynamicHead,利用注意力机制统一目标检测头部|即插即用
  • openssl交叉编译(这次基本上正规了)
  • ECharts散点图-气泡图,附视频讲解与代码下载
  • 0.96寸OLED显示屏详解
  • 一篇文章学会HTML
  • Qt基础之三十三:海量网络数据实时显示
  • Spring Boot 中文参考指南(二)-Web
  • 前端网络安全
  • 吃透Java面试题,建议收藏
  • C++基础算法③——排序算法(选择、冒泡附完整代码)
  • Android Lancet Aop 字节编码修复7.1系统Toast问题(WindowManager$BadTokenException)
  • Vite中ant design vue按需引入以及css预处理配置
  • 【Java SE】变量的本质
  • 【Spring-boot源码剥析】| 启动原理之侠客行篇
  • 谷歌外链怎么挑选?谷歌外链高质量平台有哪些?
  • 磁盘I/O %util特别高
  • 基于“遥感+”融合技术在碳储量、碳收支、碳循环等多领域监测与模拟
  • [ 漏洞复现篇 ] Joomla未授权访问Rest API漏洞(CVE-2023-23752)
  • linux中写定时任务
  • Linux之磁盘分区、挂载
  • 【JavaSE】类和对象(中)
  • TypeScript(七)类
  • day12函数进阶作业
  • JVM学习.02 内存分配和回收策略
  • 三维点云转深度图