思维导图

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

下面一起来聊聊吧

Redis使用场景

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

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

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

• 分布式锁 setnx、redisson

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

1、缓存穿透

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

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

解决方案一:

​ 缓存空数据

​ 查询返回的数据为空，仍把这个空结果进行缓存

优点：简单

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

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

解决方案二:

​ 布隆过滤器

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

优点：内存占用较少，没有多余的key

缺点：实现复杂，存在误判

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

布隆过滤器

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

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

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

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

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

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

小总结

1、Redis的使用场景？

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

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

• 分布式锁 setnx、redisson

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

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

面试快速答法

2、缓存击穿

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

还是上面的栗子：

解决方案一：互斥锁

解决方案二：逻辑过期

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

假设有两个线程：

优点：强一致

缺点：性能差

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

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

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

小总结

缓存击穿：

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

• 解决方案一：互斥锁，强一致，性能差

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

面试快速答法

3、缓存雪崩

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

解决方案：

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

面试快速答法

4、双写一致性

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

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

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

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

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

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

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

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

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

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

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

但是性能较低，可以优化一下：

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

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

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

具体的代码实现：

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

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

基于MQ的异步通知：

基于canal的异步通知：

小总结

Redis作为缓存，mysql的数据如何与Redis进行同步呢？（双写一致性）

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

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

介绍下异步的方案（介绍下Redisson读写锁的方案）

面试快速答法

5、持久化机制

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

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

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

RDB的执行原理是什么？

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

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

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

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

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

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

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

配置项	刷盘时机	优点	缺点
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和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见

面试快速答法

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模式）

面试快速答法

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算法进行淘汰

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（结合自己的业务场景）

面试快速答法

8、分布式锁

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

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

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

抢券场景：

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

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

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

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

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

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

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

Redis分布式锁

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

• 获取锁（设置失效时间，否则可能发生死锁）

• 释放锁

  

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

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

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

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

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

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

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

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

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

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

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

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实现的分布式锁

面试快速答法

9、Redis集群

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

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

• 主从复制

• 哨兵模式

• 分片集群

9.1、主从复制

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

主从数据同步原理

主从全量同步：

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

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

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

小总结

介绍下redis的主从同步

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

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

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

全量同步：

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

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

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

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

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

增量同步：

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

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

面试快速答法

9.2、哨兵模式

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

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

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

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

服务状态监控

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

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

• 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

哨兵选主规则

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

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

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

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

redis集群脑裂

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

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

解决方案:

redis中有两个配置参数：

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

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

小总结

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

哨兵模式：实现主从集群的自动故障恢复（监控、自动故障恢复、通知）

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

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

redis集群脑裂，该怎么解决呢？

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

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

面试快速答法

9.3、分片集群

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

• 海量数据存储问题

• 高并发写的问题

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

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

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

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

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

分片集群结构-数据读写

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

小总结

redis的分片集群有什么作用

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

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

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

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

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

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

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

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

面试快速答法

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），调用一切系统资源

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

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

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

阻塞IO

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

阶段一：

①用户进程尝试读取数据（比如网卡数据）

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

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

阶段二：

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

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

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

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

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

非阻塞IO

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

阶段一：

①用户进程尝试读取数据（比如网卡数据）

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

③返回异常给用户进程

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

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

阶段二：

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

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

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

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

IO多路复用

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

阶段一：

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

②内核监听对应的多个socket

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

④此过程中用户进程阻塞

阶段二：

①用户进程找到就绪的socket

②依次调用recvfrom读取数据

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

④用户进程处理数据

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

• select

• poll

• epoll

差异：

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

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

Redis网络模型

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

小总结

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

I/O多路复用

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

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

Redis网络模型

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

• 连接应答处理器

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

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

面试快速答法

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