Redis

Redis缓存三兄弟(穿透、击穿、雪崩)

缓存穿透

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

解决方案一：缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存

优点：简单

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

解决方案二：布隆过滤器

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

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

布隆过滤器技术原理及应用实战

bitmap(位图)：相当于是一个以(bit)位为单位的数组，数组中每个单元只能存储二进制数0或1

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

变量 hash函数个数位图大小

RedissonClient工具类中集成了BloomFilter，使用方法如下

import org.redisson.api.RBloomFilter;
import org.redisson.api.RedissonClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class BloomFilterService {

    @Autowired
    private RedissonClient redissonClient;

    /**
     * 创建布隆过滤器
     *
     * @param filterName          过滤器名称
     * @param falseProbability    误判率
     * @param expectedInsertions  预期插入数
     */
    public void createBloomFilter(String filterName, double falseProbability, long expectedInsertions) {
    	//创建布隆过滤器
        RBloomFilter<String> bloomFilter = redissonClient.getBloomFilter(filterName);
        //初始化布隆过滤器 
        bloomFilter.tryInit(expectedInsertions, falseProbability);
    }

    /**
     * 向布隆过滤器中添加元素
     *
     * @param filterName  过滤器名称
     * @param element     要添加的元素
     */
    public void addElementToBloomFilter(String filterName, String element) {
        RBloomFilter<String> bloomFilter = redissonClient.getBloomFilter(filterName);
        bloomFilter.add(element);
    }

    /**
     * 检查布隆过滤器是否可能包含指定的元素
     *
     * @param filterName  过滤器名称
     * @param element     要检查的元素
     * @return            布隆过滤器是否可能包含指定的元素
     */
    public boolean mightContainElement(String filterName, String element) {
        RBloomFilter<String> bloomFilter = redissonClient.getBloomFilter(filterName);
        return bloomFilter.contains(element);
    }
}

总结

Redis的使用场景

l根据自己简历上的业务进行回答 l缓存穿透、击穿、雪崩、双写一致、持久化、数据过期、淘汰策略 l分布式锁 setnx、redisson

什么是缓存穿透，怎么解决

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

解决方案一：缓存空数据 解决方案二：布隆过滤器

缓存击穿

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

**解决方案一：**互斥锁 **解决方案二：**逻辑过期

总结

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

l解决方案一：互斥锁，强一致，性能差 l解决方案二：逻辑过期，高可用，性能优，不能保证数据绝对一致

缓存雪崩

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

解决方案：

给不同的Key的TTL添加随机值
利用Redis集群提高服务的可用性哨兵模式、集群模式
给缓存业务添加降级限流策略 ngxin或spring cloud gateway
给业务添加多级缓存 Guava或Caffeine

总结

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

给不同的Key的TTL添加随机值
利用Redis集群提高服务的可用性
给缓存业务添加降级限流策略降级可做为系统的保底策略，适用于穿透、击穿、雪崩
给业务添加多级缓存

《缓存三兄弟》

穿透无中生有key，布隆过滤null隔离。 缓存击穿过期key，锁与非期解难题。 雪崩大量过期key，过期时间要随机。 面试必考三兄弟，可用限流来保底。

Redis 双写一致

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

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

先删除缓存，还是先修改数据库(都不行)

读锁（共享锁）

写锁（排它锁）

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

基于Canal的异步通知：

二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。

总结

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

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

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

那你来介绍一下异步的方案（你来介绍一下redisson读写锁的这种方案）

l允许延时一致的业务，采用异步通知 ①使用MQ中间中间件，更新数据之后，通知缓存删除 ②利用canal中间件，不需要修改业务代码，伪装为mysql的一个从节点，canal通过读取binlog数据更新缓存

l强一致性的，采用Redisson提供的读写锁 ①共享锁：读锁readLock，加锁之后，其他线程可以共享读操作 ②排他锁：独占锁writeLock也叫，加锁之后，阻塞其他线程读写操作

Redis持久化

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

RDB

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

[root@localhost ~]# redis-cli
127.0.0.1:6379> save #由Redis主进程来执行RDB，会阻塞所有命令
127.0.0.1:6379> bgsave #开启子进程执行RDB，避免主进程受到影响
Background saving started

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

# 900秒内，如果至少有1个key被修改，则执行bgsave 
save 900 1  
save 300 10  
save 60 10000

RDB执行原理

bgsave开始是回fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件。 fork采用的是copy-on-write技术： •当主进程执行读操作时，访问共享内存； •当主进程执行写操作时，则会拷贝一份数据，执行写操作。 fork类似于克隆

AOF

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

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

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof

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

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

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

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

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

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

RDB与AOF对比

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

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

Redis数据过期策略

Redis对数据设置数据的有效时间，数据过期以后，就需要将数据从内存中删除掉。可以按照不同的规则进行删除，这种删除规则就被称之为数据的删除策略(数据过期策略)。

Redis中提供了两种数据删除策略：惰性删除、定期删除

惰性删除

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

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

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

定期删除

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

定期清理有两种模式：

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

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

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

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

总结

Redis的数据过期策略

惰性删除：访问key的时候判断是否过期，如果过期，则删除

定期删除：定期检查一定量的key是否过期（ SLOW模式+ FAST模式）

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

Redis数据淘汰策略

数据的淘汰策略：在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（Least Recently Used）最近最少使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。例：key1是在3s之前访问的, key2是在9s之前访问的，删除的就是key2

LFU（Least Frequently Used）最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。例：key1最近5s访问了4次, key2最近5s访问了9次，删除的就是key1

数据淘汰策略-使用建议

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

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

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

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

其他面试问题

1.数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ? 使用allkeys-lru(挑选最近最少使用的数据淘汰)淘汰策略，留下来的都是经常访问的热点数据

2.Redis的内存用完了会发生什么？主要看数据淘汰策略是什么？如果是默认的配置（ noeviction ），会直接报错

总结

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

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

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

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

Redis分布式锁

现在的服务基本都是集群部署，不能使用本地的锁，本地锁只对自己有效，这时就需要使用分布式锁

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

# 获取锁
# 添加锁，NX是互斥、EX是设置超时时间 必须添加超时时间 避免服务宕机导致死锁问题
SET lock value NX EX 10

# 释放锁
# 释放锁，删除即可
DEL key

Redis实现分布式锁如何合理的控制锁的有效时长？ 1.根据业务执行时间预估不可靠 2.给锁续期

redisson实现的分布式锁-执行流程

redisson实现的分布式锁--可重入

public void add1(){
    RLock lock = redissonClient.getLock(“heimalock");
    boolean isLock = lock.tryLock();
    //执行业务
  add2();
    //释放锁
  lock.unlock();
}
public void add2(){
    RLock lock = redissonClient.getLock(“heimalock");
    boolean isLock = lock.tryLock();
    //执行业务
  //释放锁
  lock.unlock();
}

redisson实现的分布式锁-主从一致性

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

总结

redis分布式锁，是如何实现的？ l先按照自己简历上的业务进行描述分布式锁使用的场景 l我们当使用的redisson实现的分布式锁，底层是setnx和lua脚本（保证原子性）
Redisson实现分布式锁如何合理的控制锁的有效时长？在redisson的分布式锁中，提供了一个WatchDog(看门狗），一个线程获取锁成功以后， WatchDog会给持有锁的线程续期（默认是每隔10秒续期一次）
Redisson的这个锁，可以重入吗？可以重入，多个锁重入需要判断是否是当前线程，在redis中进行存储的时候使用的hash结构，来存储线程信息和重入的次数
Redisson锁能解决主从数据一致的问题吗不能解决，但是可以使用redisson提供的红锁来解决，但是这样的话，性能就太低了，如果业务中非要保证数据的强一致性，建议采用zookeeper实现的分布式锁

Redis集群方案

主从复制哨兵模式分片集群

主从复制

单节点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值之后的数据，发送给从节点进行数据同步

哨兵模式

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集群（哨兵模式）脑裂

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的配置，可以设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失

分片集群结构

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决： •海量数据存储问题 •高并发写的问题

使用分片集群可以解决上述问题，分片集群特征： •集群中有多个master，每个master保存不同数据 •每个master都可以有多个slave节点 •master之间通过ping监测彼此健康状态 •客户端请求可以访问集群任意节点，最终都会被转发到正确节点

分片集群结构--数据读写

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

总结

redis的分片集群有什么作用？ l集群中有多个master，每个master保存不同数据 l每个master都可以有多个slave节点 lmaster之间通过ping监测彼此健康状态 l客户端请求可以访问集群任意节点，最终都会被转发到正确节点

Redis分片集群中数据是怎么存储和读取的？ lRedis 分片集群引入了哈希槽的概念，Redis 集群有 16384 个哈希槽 l将16384个插槽分配到不同的实例 l读写数据：根据key的有效部分计算哈希值，对16384取余（有效部分，如果key前面有大括号，大括号的内容就是有效部分，如果没有，则以key本身做为有效部分）余数做为插槽，寻找插槽所在的实例

Redis单线程速度为什么快

Redis是单线程的，但是为什么还那么快？ lRedis是纯内存操作，执行速度非常快 l采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题 l使用I/O多路复用模型，非阻塞IO
能解释一下I/O多路复用模型？ Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度， I/O多路复用模型主要就是实现了高效的网络请求 l用户空间和内核空间 l常见的IO模型 Ø阻塞IO（Blocking IO） Ø非阻塞IO（Nonblocking IO） ØIO多路复用（IO Multiplexing） lRedis网络模型

用户空间和内核空间

Linux系统中一个进程使用的内存情况划分两部分：内核空间、用户空间 用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源必须通过内核提供的接口来访问 内核空间可以执行特权命令（Ring0），调用一切系统资源

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

阻塞IO

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

阶段一： ①用户进程尝试读取数据（比如网卡数据） ②此时数据尚未到达，内核需要等待数据 ③此时用户进程也处于阻塞状态

阶段二： ①数据到达并拷贝到内核缓冲区，代表已就绪 ②将内核数据拷贝到用户缓冲区 ③拷贝过程中，用户进程依然阻塞等待 ④拷贝完成，用户进程解除阻塞，处理数据

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

非阻塞IO

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

阶段一： ①用户进程尝试读取数据（比如网卡数据） ②此时数据尚未到达，内核需要等待数据 ③返回异常给用户进程 ④用户进程拿到error后，再次尝试读取 ⑤循环往复，直到数据就绪

阶段二： ①将内核数据拷贝到用户缓冲区 ②拷贝过程中，用户进程依然阻塞等待 ③拷贝完成，用户进程解除阻塞，处理数据

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

IO多路复用

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之后，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，依然是单线程