Redis进阶篇(附面试快速答法)

文章目录

  • Redis使用场景
  • 1、缓存穿透
    • 布隆过滤器
    • 小总结
    • 面试快速答法
  • 2、缓存击穿
    • 小总结
    • 面试快速答法
  • 3、缓存雪崩
    • 面试快速答法
  • 4、双写一致性
    • 小总结
    • 面试快速答法
  • 5、持久化机制
    • 面试快速答法
  • 6、数据过期策略
    • 小总结
    • 面试快速答法
  • 7、数据淘汰策略
    • 小总结
    • 面试快速答法
  • 8、分布式锁
    • 小总结
    • 面试快速答法
  • 9、Redis集群
    • 9.1、主从复制
      • 小总结
      • 面试快速答法
    • 9.2、哨兵模式
      • 小总结
      • 面试快速答法
    • 9.3、分片集群
      • 小总结
      • 面试快速答法
  • 10、IO多路复用
    • 小总结
    • 面试快速答法

思维导图

Redis进阶篇(附面试快速答法)_第1张图片

学习之前先来看看对于以下问题你是否能跟面试官侃侃而谈呢?

Redis进阶篇(附面试快速答法)_第2张图片

Redis进阶篇(附面试快速答法)_第3张图片

下面一起来聊聊吧

Redis使用场景

我看你做的项目中,都用到了redis,你在最近的项目中哪些场景使用了redis呢?

这个时候一定要结合项目来回答

  • 缓存 缓存三兄弟(穿透、击穿、雪崩)、双写一致、持久化、数据过期策略、数据淘汰策略

  • 分布式锁 setnx、redisson

  • 消息队列、延迟队列 何种数据结构

1、缓存穿透

缓存穿透:查询一个不存在的数据,mysql查询不到数据也不会直接写入缓存,就会导致每次请求都会去查数据库

比如现在有一个请求:根据id查询文章

在这里插入图片描述
Redis进阶篇(附面试快速答法)_第4张图片

解决方案一:

缓存空数据

​ 查询返回的数据为空,仍把这个空结果进行缓存在这里插入图片描述

优点:简单

缺点:消耗内存,可能会发生数据不一致的问题

(比如说第一次查询到的数据为空,我们存到Redis里面,后面数据库中添加了这个数据,而缓存中还是null,就会发生数据不一致)

解决方案二:

布隆过滤器

​ 在系统启动的时候把目标数据全部缓存到布隆过滤器里面,当攻击者用不存在的key来请求的时候,先到布隆过滤器里面查询,如果不存在,就意味着这个数据在数据库中也不存在。

Redis进阶篇(附面试快速答法)_第5张图片

优点:内存占用较少,没有多余的key

缺点:实现复杂,存在误判

那么什么是布隆过滤器呢?

布隆过滤器

布隆过滤器的实现依赖于bitmap,占用的内存空间很少

bitmap(位图):相当于是一个以(bit)位为单位的数组,数组中每个单元只能存储二进制数0或1。初始值为0

在这里插入图片描述

布隆过滤器作用:布隆过滤器可以用于检索一个元素是否在一个集合中

我们添加一个id为1的数据存储到bitmap中

Redis进阶篇(附面试快速答法)_第6张图片

布隆过滤器的一个缺点是容易产生误判,比如现在有一个不存在的id为3的数据,经过三次hash之后得到的值是3,9,12,在bitmap中这三个值都为1那就说明id为3的数据存在呀,那我们知道,id为3的数据其实是不存在的,这个时候就存在了误判。

在这里插入图片描述

那怎么解决这个问题呢?其实误判率我们是可以控制的,设置一个误判率,一般在5%以内

Redis进阶篇(附面试快速答法)_第7张图片

小总结

1、Redis的使用场景?

  • 根据自己简历上的业务进行回答

  • 缓存 穿透、击穿、雪崩、双写一致、持久化、数据过期、数据淘汰

  • 分布式锁 setnx、redisson

2、什么是缓存穿透?怎么解决

  • 缓存穿透:查询一个不存在的数据,mysql查询不到数据也不会直接写入缓存,就会导致每次请求都查数据库
  • 解决方案一:缓存空数据
  • 解决方案二:布隆过滤器

面试快速答法

Redis进阶篇(附面试快速答法)_第8张图片

2、缓存击穿

缓存击穿:给某一个key设置了过期时间,当key过期的时候,恰好这个时间点对这个key有大量的并发请求过来,这些并发的请求可能会瞬间把DB压垮

还是上面的栗子:

Redis进阶篇(附面试快速答法)_第9张图片

解决方案一:互斥锁

解决方案二:逻辑过期

我们先来看一下采用互斥锁方案

假设有两个线程:
Redis进阶篇(附面试快速答法)_第10张图片

优点:强一致

缺点:性能差

接下来看一下使用逻辑过期方案

Redis进阶篇(附面试快速答法)_第11张图片

优点:高可用(先返回一个数据再说)、性能优

缺点:不能保证数据的绝对一致

小总结

缓存击穿:

  • 缓存击穿:给某一个key设置了过期时间,当key过期的时候,恰好这个时间点对这个key有大量的并发请求过来,这些并发的请求可能会瞬间把DB压垮

  • 解决方案一:互斥锁,强一致,性能差

  • 解决方案二:逻辑过期,高可用,性能优,不能保证数据绝对一致

面试快速答法

Redis进阶篇(附面试快速答法)_第12张图片

3、缓存雪崩

缓存雪崩 : 是指在同一时段大量的缓存key同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力。

Redis进阶篇(附面试快速答法)_第13张图片

解决方案:

  • 给不同的key设置不同的过期时间,可以在原有的失效时间的基础上增加一个随机值,给1~5分钟随机
  • 利用Redis集群提高服务的可用性 哨兵模式、集群模式
  • 给缓存业务添加降级限流策略 nginx或gateway 保底策略
  • 给业务添加多级缓存 Guava或Caffeine

面试快速答法

Redis进阶篇(附面试快速答法)_第14张图片

4、双写一致性

Redis作为缓存,Mysql的数据如何与redis进行同步呢?

设置前提,首先介绍自己的业务背景,有两种情况

  • 数据一致性要求高
  • 允许短暂的不一致

我们先来看第一种情况:数据的强一致性

双写一致性:当修改了数据库的数据也要同时更新缓存的数据,缓存和数据库的数据要保存一致

Redis进阶篇(附面试快速答法)_第15张图片

  • 读操作:缓存命中,直接返回;缓存未命中就查询数据库,写入缓存,设定超时时间
  • 写操作:延时双删

Redis进阶篇(附面试快速答法)_第16张图片

这里其实有问题:先删除缓存呢?还是先修改数据库呢?

Redis进阶篇(附面试快速答法)_第17张图片

其实无论先删除缓存还是先删除数据库都有问题,所以采用双删的策略

那为什么要延时呢?其实啊一般情况下数据库是主从模式读写分离,我们延时一会儿,让主节点将数据同步到从节点

但是这个延时的时间不好控制,延时双删并不能保证强一致性,也有脏数据的风险

要想保证数据的强一致性,可以使用分布式锁

Redis进阶篇(附面试快速答法)_第18张图片

但是性能较低,可以优化一下:

我们知道,缓存的数据一般是读多写少的情况,我们可以使用读写锁进行控制

  • 共享锁:读锁readLock,加锁之后,其他线程可以共享读操作
  • 排他锁:独占锁writeLock,加锁之后,阻塞其他线程读写操作

Redis进阶篇(附面试快速答法)_第19张图片

对比分布式锁,性能提升了,也能保证数据的强一致性

具体的代码实现:

Redis进阶篇(附面试快速答法)_第20张图片

Redis进阶篇(附面试快速答法)_第21张图片

第二种情况:允许短暂的数据不一致,在实际的业务开发中用的最多

我们通过异步通知保证数据的最终一致性

基于MQ的异步通知:

Redis进阶篇(附面试快速答法)_第22张图片

基于canal的异步通知:

Redis进阶篇(附面试快速答法)_第23张图片

小总结

Redis作为缓存,mysql的数据如何与Redis进行同步呢?(双写一致性)

  1. 介绍自己简历上的业务,我们当时是把讲师的热点数据存入到了缓存中,虽然是热点数据,但是实时要求性并没有那么高,所以,我们当时采用的是异步的方案同步的数据

  2. 我们当时是把抢券的库存存入到了缓存中,这个需要实时的进行数据同步,为了保证数据的强一致,我们当时采用的是redisson提供的读写锁来保证数据的同步

介绍下异步的方案(介绍下Redisson读写锁的方案)

Redis进阶篇(附面试快速答法)_第24张图片

Redis进阶篇(附面试快速答法)_第25张图片

面试快速答法

Redis进阶篇(附面试快速答法)_第26张图片
Redis进阶篇(附面试快速答法)_第27张图片

5、持久化机制

在Redis中提供了两种数据持久化的方式:1、RDB 2、AOF

RDB全称Redis Database Backup file(Redis数据备份文件),也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据

Redis进阶篇(附面试快速答法)_第28张图片

Redis内部有触发RDB的机制,可以在redis.conf文件中找到,格式如下:
在这里插入图片描述

RDB的执行原理是什么?

bgsave开始时会fork主进程得到子进程,子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

Redis进阶篇(附面试快速答法)_第29张图片

fork采用的是copy-on-write技术:

  • 当主进程执行读操作时,访问共享内存;

  • 当主进程执行写操作时,则会拷贝一份数据,执行写操作。

AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件

Redis进阶篇(附面试快速答法)_第30张图片

AOF默认是关闭的,需要修改redis.conf配置文件来开启AOF:

在这里插入图片描述

AOF的命令记录的频率也可以通过redis.conf文件来配置:

Redis进阶篇(附面试快速答法)_第31张图片

配置项 刷盘时机 优点 缺点
Always 同步刷盘 可靠性高,几乎不丢数据 性能影响大
everysec 每秒刷盘 性能适中 最多丢失1秒数据
no 操作系统控制 性能最好 可靠性较差,可能丢失大量数据

因为是记录命令,AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作,但只有最后一次写操作才有意义。

通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果。

在这里插入图片描述

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置:

在这里插入图片描述

RDB与AOF对比

RDB和AOF各有自己的优缺点,如果对数据安全性要求较高,在实际开发中往往会结合两者来使用。

RDB AOF
持久化方式 定时对整个内存做快照 记录每一次执行的命令
数据完整性 不完整,两次备份之间会丢失 相对完整,取决于刷盘策略
文件大小 会有压缩,文件体积小 记录命令,文件体积很大
宕机恢复速度 很快
数据恢复优先级 低,因为数据完整性不如AOF 高,因为数据完整性更高
系统资源占用 高,大量CPU和内存消耗 低,主要是磁盘IO资源 但AOF重写时会占用大量CPU和内存资源
使用场景 可以容忍数分钟的数据丢失,追求更快的启动速度 对数据安全性要求较高常见

面试快速答法

Redis进阶篇(附面试快速答法)_第32张图片

6、数据过期策略

假如Redis的key过期后,会立即删除吗?

在这里插入图片描述

Redis对数据设置 数据的有效时间,数据过期以后,就需要将数据从内存中删除掉。

可以按照不同的规则进行删除,这种删除规则就被称之为数据的删除策略(数据过期策略)

  • 惰性删除
  • 定期删除

Redis数据删除策略-惰性删除

惰性删除:设置该key过期后,我们不去管它,当需要该key时,我们再检查其是否过期,如果过期,我们就删掉它;反之返回该key

在这里插入图片描述

优点 :对CPU友好,只会在使用该key时才会进行过期检查,对于很多用不到的key不用浪费时间进行过期检查

缺点 :对内存不友好,如果一个key已经过期,但是一直没有使用,那么该key就会一直存在内存中,内存永远不会释放

Redis数据删除策略-定期删除

定期删除:每隔一段时间,我们就对一些key进行检查,删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查,并删除其中的过期key)

定期清理有两种模式:

  • slow模式是定时任务,执行频率默认为10hz,每次不超过25ms,以通过修改配置文件redis.conf的hz选项来调整这个次数
  • fast模式执行频率不固定,但两次间隔不低于2ms,每次耗时不超过1ms

优点:可以通过限制删除操作执行的时长和频率来减少删除操作对CPU的影响。另外定期删除,也能有效释放过期key占用的内存

缺点:难以确定删除操作执行的时长和频率

Redis的过期删除策略:惰性删除 + 定期删除两种策略进行配合使用

小总结

Redis的数据过期策略?

  • 惰性删除:访问key的时候判断是否过期,如果过期,则删除

  • 定期删除:定期检查一定量的key是否过期( SLOW模式+ FAST模式)

面试快速答法

Redis进阶篇(附面试快速答法)_第33张图片

7、数据淘汰策略

假如缓存过多,内存是有限的,内存被占满了怎么办?(数据淘汰策略)

数据淘汰策略

​当Redis中的内存不够用时,此时再向Redis中添加新的key,那么Redis就会按照某种规则将内存中的数据删除掉。

Redis支持8种不同的策略来选择要删除的key:

  • noeviction:不淘汰任何key,但是内存满时不允许写入新数据,默认的策略

在这里插入图片描述

  • volatile-ttl:对设置了TTL的key,比较key的剩余的TTL值,TTL越小越先被淘汰

  • allkeys-random:对全体key,随机进行淘汰

  • volatile-random:对设置了TTL的key,随机进行淘汰

  • allkeys-lru:对全体key,基于LRU算法进行淘汰

  • volatile-lru:对设置了TTL的key,基于LRU算法进行淘汰

  • allkeys-lfu:对全体key,基于LFU算法进行淘汰

  • volatile-lfu:对设置了TTL 的key,基于LFU算法进行淘汰

Redis进阶篇(附面试快速答法)_第34张图片

LRU算法:
在这里插入图片描述

LFU算法:在这里插入图片描述

数据淘汰策略-建议使用

  1. 优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势,把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分,建议使用。

  2. 如果业务中数据访问频率差别不大,没有明显冷热数据区分,建议使用 allkeys-random,随机选择淘汰。

  3. 如果业务中有置顶的需求,可以使用 volatile-lru 策略,同时置顶数据不设置过期时间,这些数据就一直不被删除,会淘汰其他设置过期时间的数据。

  4. 如果业务中有短时高频访问的数据,可以使用 allkeys-lfu 或 volatile-lfu 策略。

数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ?

使用allkeys-lru(挑选最近最少使用的数据淘汰)淘汰策略,留下来的都是经常访问的热点数据

Redis的内存用完了会发生什么?

主要看数据淘汰策略是什么?如果是默认的配置( noeviction ),会直接报错

小总结

数据淘汰策略:

  1. Redis提供了8种不同的数据淘汰策略,默认是noeviction不删除任何数据,内存不足直接报错

  2. LRU:最近最少使用。用当前时间减去最后一次访问时间,这个值越大则淘汰优先级越高。

  3. LFU:最少频率使用。会统计每个key的访问频率,值越小淘汰优先级越高

平时开发过程中用的比较多的就是allkeys-lru(结合自己的业务场景)

面试快速答法

Redis进阶篇(附面试快速答法)_第35张图片

8、分布式锁

Redis分布式锁是如何实现的?

需要结合项目中的业务进行回答

通常情况下,分布式锁使用的场景:集群情况下的定时任务、抢单抢券、幂等性场景

抢券场景:

Redis进阶篇(附面试快速答法)_第36张图片

Redis进阶篇(附面试快速答法)_第37张图片

这里有个问题,就是多线程下可能会出现超卖问题,我们看下面这种情况:

Redis进阶篇(附面试快速答法)_第38张图片

刚开始库存为1,线程1和线程2 都去查询到的结果是1,这时线程1继续执行判断库存是否充足,扣减库存,此时库存为0;然后线程2一开始拿到的结果也是1,继续扣减库存,此时库存变为-1;这就导致了超卖问题

我们可以通过加锁的方式防止超买超卖的问题

Redis进阶篇(附面试快速答法)_第39张图片

但是这种方式保证本地加锁,如果你的项目是单体项目,并且只启动了一台服务,那么上述代码是没问题的

要是分布式服务呢?阁下又该如何应对?

Redis进阶篇(附面试快速答法)_第40张图片

Redis进阶篇(附面试快速答法)_第41张图片

我们发现两台服务都能拿到锁,因为我们加的synchronized锁,只能保证本地,目前这个锁是Jvm锁,每一个服务都有各自的Jvm,synchronized只能解决同一个Jvm下线程的互斥,解决不了多个Jvm下线程的互斥。

此时我们就可以使用分布式锁来解决这个问题

Redis进阶篇(附面试快速答法)_第42张图片

Redis分布式锁

Redis实现分布式锁主要利用Redis的setnx命令。setnx是SET if not exists(如果不存在,则 SET)的简写。

  • 获取锁(设置失效时间,否则可能发生死锁)

在这里插入图片描述

  • 释放锁

    在这里插入图片描述

Redis获取分布式锁的执行流程:

Redis进阶篇(附面试快速答法)_第43张图片

Redis实现分布式锁如何合理的控制锁的有效时长?

  • 根据业务执行时间预估
  • 给锁续期

Redis进阶篇(附面试快速答法)_第44张图片

在redisson的分布式锁中,提供了一个WatchDog(看门狗),一个线程获取锁成功以后, WatchDog会给持有锁的线程续期(默认是每隔10秒续期一次)

Redis进阶篇(附面试快速答法)_第45张图片

当我们尝试获取锁,如果传了第二个参数,看门狗监听会失效,Redisson认为可以自己控制锁的失效时间,不再做续期

Redis进阶篇(附面试快速答法)_第46张图片

Redis实现的分布式锁是不能实现重入的,但是Redisson实现的分布式锁是能实现重入的

每个线程都维护了一个线程id,锁能不能重入,取决于是不是同一个线程

上面的方法add1()调用add2()方法,它俩是在同一个线程,执行add2()方法的时候,确定之前获取的锁是不是同一个线程,同一个线程就可以获取锁成功

Redis进阶篇(附面试快速答法)_第47张图片

Java应用创建了分布式锁,将数据写入到主节点,正常情况下,主节点要将数据同步到从节点;但是假如还没来的及同步,主节点挂掉了

根据哨兵模式,会在从节点中选取一个作为主节点

Redis进阶篇(附面试快速答法)_第48张图片

此时,新的线程来了之后,会直接请求新的主节点,也会去尝试获取锁,因为之前的数据没同步过来,所以说新的线程也能加锁成功,此时就出现了两个线程同时持有同一把锁,没有互斥性了,可能会出现脏数据

Redis中提供了另外一个锁

RedLock(红锁):不能只在一个redis实例上创建锁,应该是在多个redis实例上创建锁(n / 2 + 1),避免在一个redis实例上加锁。

在这里插入图片描述
但是这种方式实现复杂,性能很差。如果业务中非要保证数据的强一致性,建议采用 zookeeper实现的分布式锁

小总结

Redisson实现的分布式锁

  • 底层基于redis的setnx命令做了改进封装,使用lua脚本保证命令的原子性

  • 利用hash结构,记录线程标示和重入次数;

  • 利用watchDog延续锁时间;

  • 控制锁重试等待

  • Redlock红锁解决主从数据一致的问题(不推荐)性能差

  • 如果业务非要保证强一致性,建议采用zookeeper实现的分布式锁

redis分布式锁,是如何实现的?

  • 先按照自己简历上的业务进行描述分布式锁使用的场景

  • 我们当使用的redisson实现的分布式锁,底层是setnx和lua脚本(保证原子性)

Redisson实现分布式锁如何合理的控制锁的有效时长?

​ 在redisson的分布式锁中,提供了一个WatchDog(看门狗),一个线程获取锁成功以后, WatchDog会给持有锁的线程续期(默认是每隔10秒续期一次)

Redisson的这个锁,可以重入吗?

​ 可以重入,多个锁重入需要判断是否是当前线程,在redis中进行存储的时候使用的hash结构,来存储线程信息和重入的次数

Redisson锁能解决主从数据一致的问题吗?

​ 不能解决,但是可以使用redisson提供的红锁来解决,但是这样的话,性能就太低了,如果业务中非要保证数据的强一致性,建议采用 zookeeper实现的分布式锁

面试快速答法

Redis进阶篇(附面试快速答法)_第49张图片

9、Redis集群

Redis集群有哪些方案, 知道嘛?

在Redis中提供的集群方案总共有三种

  • 主从复制

  • 哨兵模式

  • 分片集群

9.1、主从复制

单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离。

Redis进阶篇(附面试快速答法)_第50张图片

主从数据同步原理

主从全量同步

Redis进阶篇(附面试快速答法)_第51张图片

  • Replication Id:简称replid,是数据集的标记,id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replid

  • offset:偏移量,随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset,说明slave数据落后于master,需要更新。

主从增量同步(slave重启或后期数据变化)

Redis进阶篇(附面试快速答法)_第52张图片

小总结

介绍下redis的主从同步

单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离。

一般都是一主多从,主节点负责写数据,从节点负责读数据

能说一下,主从同步数据的流程

全量同步

  1. 从节点请求主节点同步数据(replication id、 offset )

  2. 主节点判断是否是第一次请求,是第一次就与从节点同步版本信息(replication id和offset)

  3. 主节点执行bgsave,生成rdb文件后,发送给从节点去执行

  4. 在rdb生成执行期间,主节点可能会接收其他的命令,把命令记录到缓冲区(一个日志文件)

  5. 把生成之后的命令日志文件发送给从节点进行同步

增量同步

  1. 从节点请求主节点同步数据,主节点判断不是第一次请求,不是第一次就获取从节点的offset值

  2. 主节点从命令日志中获取offset值之后的数据,发送给从节点进行数据同步

面试快速答法

Redis进阶篇(附面试快速答法)_第53张图片

9.2、哨兵模式

Redis提供了哨兵(Sentinel)机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下:

  • 监控:Sentinel 会不断检查您的master和slave是否按预期工作

  • 自动故障恢复:如果master故障,Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主

  • 通知:Sentinel充当Redis客户端的服务发现来源,当集群发生故障转移时,会将最新信息推送给Redis的客户端

Redis进阶篇(附面试快速答法)_第54张图片

服务状态监控

Sentinel基于心跳机制监测服务状态,每隔1秒向集群的每个实例发送ping命令:

  • 主观下线:如果某sentinel节点发现某实例未在规定时间响应,则认为该实例主观下线

  • 客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线,则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

Redis进阶篇(附面试快速答法)_第55张图片

哨兵选主规则

  • 首先判断主与从节点断开时间长短,如超过指定值就排该从节点

  • 然后判断从节点的slave-priority值,越小优先级越高

  • 如果slave-prority一样,则判断slave节点的offset值,越大优先级越高

  • 最后是判断slave节点的运行id大小,越小优先级越高。

redis集群脑裂

Redis进阶篇(附面试快速答法)_第56张图片

这是一个正常的主从架构,配合了哨兵模式。现在由于网络原因,这个主节点Master和哨兵都处于不同的网络分区,此时哨兵只能监测从节点,检测不到主节点了,这个时候哨兵就会在从节点中选择一个主节点,但是以前的主节点还没有挂,只是因为网络出现了问题,客户端还能正常连接,此时就有了两个Master,这就是脑裂

Redis进阶篇(附面试快速答法)_第57张图片

此时会有问题,客户端连接的是老的master,会持续往该节点写数据,新的节点不能同步数据,假如现在网络恢复了,哨兵会将老的master强制降为slave,降为slave之后会从新的master同步数据,它会把自己的数据清空,那之前客户端写入的数据就丢失了。

解决方案:

redis中有两个配置参数:

  • min-replicas-to-write 1 表示最少的salve节点为1个

  • min-replicas-max-lag 5 表示数据复制和同步的延迟不能超过5秒

Redis进阶篇(附面试快速答法)_第58张图片

小总结

怎么保证Redis的高并发高可用

哨兵模式:实现主从集群的自动故障恢复(监控、自动故障恢复、通知)

你们使用redis是单点还是集群,哪种集群

主从(1主1从)+哨兵就可以了。单节点不超过10G内存,如果Redis内存不足则可以给不同服务分配独立的Redis主从节点

redis集群脑裂,该怎么解决呢?

集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区,使得sentinel没有能够心跳感知到主节点,所以通过选举的方式提升了一个从节点为主,这样就存在了两个master,就像大脑分裂了一样,这样会导致客户端还在老的主节点那里写入数据,新节点无法同步数据,当网络恢复后,sentinel会将老的主节点降为从节点,这时再从新master同步数据,就会导致数据丢失

解决:我们可以修改redis的配置,可以设置最少的从节点数量以及缩短主从数据同步的延迟时间,达不到要求就拒绝请求,就可以避免大量的数据丢失

面试快速答法

Redis进阶篇(附面试快速答法)_第59张图片

9.3、分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决:

  • 海量数据存储问题

  • 高并发写的问题

使用分片集群可以解决上述问题,分片集群特征:

  • 集群中有多个master,每个master保存不同数据

  • 每个master都可以有多个slave节点

  • master之间通过ping监测彼此健康状态

  • 客户端请求可以访问集群任意节点,最终都会被转发到正确节点

Redis进阶篇(附面试快速答法)_第60张图片

分片集群结构-数据读写

Redis 分片集群引入了哈希槽的概念,Redis 集群有 16384 个哈希槽,每个 key通过 CRC16 校验后对 16384 取模来决定放置哪个槽,集群的每个节点负责一部分 hash 槽。

Redis进阶篇(附面试快速答法)_第61张图片

小总结

redis的分片集群有什么作用

  • 集群中有多个master,每个master保存不同数据

  • 每个master都可以有多个slave节点

  • master之间通过ping监测彼此健康状态

  • 客户端请求可以访问集群任意节点,最终都会被转发到正确节点

Redis分片集群中数据是怎么存储和读取的?

  • Redis 分片集群引入了哈希槽的概念,Redis 集群有 16384 个哈希槽

  • 将16384个插槽分配到不同的实例

  • 读写数据:根据key的有效部分计算哈希值,对16384取余(有效部分,如果key前面有大括号,大括号的内容就是有效部分,如果没有,则以key本身做为有效部分)余数做为插槽,寻找插槽所在的实例

面试快速答法

Redis进阶篇(附面试快速答法)_第62张图片

10、IO多路复用

Redis是单线程的,但是为什么还那么快

  • Redis是纯内存操作,执行速度非常快

  • 采用单线程,避免不必要的上下文切换可竞争条件,多线程还要考虑线程安全问题

  • 使用I/O多路复用模型,非阻塞IO

能解释一下I/O多路复用模型?

Redis是纯内存操作,执行速度非常快,它的性能瓶颈是网络延迟而不是执行速度, I/O多路复用模型主要就是实现了高效的网络请求

要聊清楚上面的问题,需要了解以下概念

  • 用户空间和内核空间

  • 常见的IO模型

    • 阻塞IO(Blocking IO)
    • 非阻塞IO(Nonblocking IO)
    • IO多路复用(IO Multiplexing)
  • Redis网络模型

用户空间和内核空间

  • Linux系统中一个进程使用的内存情况划分两部分:内核空间、用户空间

  • 用户空间只能执行受限的命令(Ring3),而且不能直接调用系统资源必须通过内核提供的接口来访问

  • 内核空间可以执行特权命令(Ring0),调用一切系统资源

Redis进阶篇(附面试快速答法)_第63张图片

Linux系统为了提高IO效率,会在用户空间和内核空间都加入缓冲区:

  • 写数据时,要把用户缓冲数据拷贝到内核缓冲区,然后写入设备

  • 读数据时,要从设备读取数据到内核缓冲区,然后拷贝到用户缓冲区

阻塞IO

顾名思义,阻塞IO就是两个阶段都必须阻塞等待:

阶段一:

①用户进程尝试读取数据(比如网卡数据)

②此时数据尚未到达,内核需要等待数据

③此时用户进程也处于阻塞状态

阶段二:

①数据到达并拷贝到内核缓冲区,代表已就绪

②将内核数据拷贝到用户缓冲区

③拷贝过程中,用户进程依然阻塞等待

④拷贝完成,用户进程解除阻塞,处理数据
Redis进阶篇(附面试快速答法)_第64张图片

可以看到,阻塞IO模型中,用户进程在两个阶段都是阻塞状态。

非阻塞IO

顾名思义,非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

阶段一:

①用户进程尝试读取数据(比如网卡数据)

②此时数据尚未到达,内核需要等待数据

③返回异常给用户进程

④用户进程拿到error后,再次尝试读取

⑤循环往复,直到数据就绪

阶段二:

①将内核数据拷贝到用户缓冲区

②拷贝过程中,用户进程依然阻塞等待

③拷贝完成,用户进程解除阻塞,处理数据

Redis进阶篇(附面试快速答法)_第65张图片

可以看到,非阻塞IO模型中,用户进程在第一个阶段是非阻塞,第二个阶段是阻塞状态。虽然是非阻塞,但性能并没有得到提高。而且忙等机制会导致CPU空转,CPU使用率暴增。

IO多路复用

是利用单个线程来同时监听多个Socket ,并在某个Socket可读、可写时得到通知,从而避免无效的等待,充分利用CPU资源。

阶段一:

①用户进程调用select,指定要监听的Socket集合

②内核监听对应的多个socket

③任意一个或多个socket数据就绪则返回readable

④此过程中用户进程阻塞

阶段二:

①用户进程找到就绪的socket

②依次调用recvfrom读取数据

③内核将数据拷贝到用户空间

④用户进程处理数据

Redis进阶篇(附面试快速答法)_第66张图片

IO多路复用是利用单个线程来同时监听多个Socket ,并在某个Socket可读、可写时得到通知,从而避免无效的等待,充分利用CPU资源。不过监听Socket的方式、通知的方式又有多种实现,常见的有:

  • select

  • poll

  • epoll

差异:

  • select和poll只会通知用户进程有Socket就绪,但不确定具体是哪个Socket ,需要用户进程逐个遍历Socket来确认

  • epoll则会在通知用户进程Socket就绪的同时,把已就绪的Socket写入用户空间

Redis网络模型

Redis通过IO多路复用来提高网络性能,并且支持各种不同的多路复用实现,并且将这些实现进行封装, 提供了统一的高性能事件库

Redis进阶篇(附面试快速答法)_第67张图片

小总结

能解释一下I/O多路复用模型?

I/O多路复用

是指利用单个线程来同时监听多个Socket ,并在某个Socket可读、可写时得到通知,从而避免无效的等待,充分利用CPU资源。

目前的I/O多路复用都是采用的epoll模式实现,它会在通知用户进程Socket就绪的同时,把已就绪的Socket写入用户空间,不需要挨个遍历Socket来判断是否就绪,提升了性能。

Redis网络模型

就是使用I/O多路复用结合事件的处理器来应对多个Socket请求

  • 连接应答处理器

  • 命令回复处理器,在Redis6.0之后,为了提升更好的性能,使用了多线程来处理回复事件

  • 命令请求处理器,在Redis6.0之后,将命令的转换使用了多线程,增加命令转换速度,在命令执行的时候,依然是单线程

面试快速答法

Redis进阶篇(附面试快速答法)_第68张图片

本文笔者参考了黑马面试视频整理,不得不说,黑马的视频讲的真的很棒
传送门:黑马面试专题

你可能感兴趣的:(redis,面试,java)