https://www.bilibili.com/video/BV1yT411H7YK P6-P19

Redis知识点

这个问题需要结合项目回答, 之后会拓展到很多话题

比如设计到缓存三兄弟, 就会做如下发问

知识点1 缓存穿透

假设你提供的服务遇到了一个Get请求, api/news/getById/1

这是一个根据id查询文章的接口, 做了缓存, 首先会在缓存中查询, 查询不到的话才会去数据库查询. 如果数据库也没有, 会导致无法建立缓存, 导致每次请求都会到数据库.

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

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

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

解决方案二：布隆过滤器

优点：内存占用较少，没有多余key
缺点：实现复杂，存在误判

知识点2 布隆过滤器

布隆过滤器(Bloom Filter)是一种空间效率极高的概率型数据结构，可以用于判断一个元素是否存在于集合中。它通过多个哈希函数将输入映射到不同的位数组上，并在这些位数组中设置相应的位来表示元素是否存在。

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

存储数据：id为1的数据，通过多个hash函数获取hash值，根据hash计算数组对应位置改为1
查询数据：使用相同hash函数获取hash值，判断对应位置是否都为1

当然, 有可能存在误判, 什么是误判呢?

假设现在已经存了id为1和2的数据

这个时候来了id为3的数据, 经过三次哈希, 发现对应的位置上都有, 就可以认为id为3的数据已存在. 但是实际并不存在

关于这个误判率, 数组越小误判率就越大，数组越大误判率就越小，但是同时带来了更多的内存消耗。

由于布隆过滤器实现起来比较复杂, 所以基本都是用框架, 比如优秀的分布式锁Redisson.

知识点3 缓存击穿

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

有俩个条件, 热点Key, 而且缓存重建时间较长

解决方案:

解决方案一：互斥锁

就是加锁, 不让一起访问, 具有强一致的特性, 但是性能差

解决方案二：逻辑过期

这个方案呢, 就是不设置TTL, 设置一个过期时间标识这个数据过期没

当查询缓存时发现这个数据过期了, 就开启一个独立线程去重建缓存

重建缓存时间段 来的请求都会得到过期数据

知识点4 缓存雪崩

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

知识点4 双写一致性

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

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

问题来了, 先删除缓存还是先删除数据库?

先删除缓存再操作数据库可能会出现数据不一致的现象.

先操作数据库, 再删除缓存也会有极低的概率出现问题

延迟双删比以上两种方案更加优秀

想要保证强一致性, 可以使用分布式锁, 性能上会差一点.

但是一般加入缓存的数据具有读多写少的特性

可以结合使用

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

获得更好的性能

---

大部分时候我们不需要数据的强一致性, 可以接受数据短暂的不一致

可以使用异步通知保证数据的最终一致性.

除了MQ还可以使用Canel实现异步通知

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

canal是基于mysql的主从同步来实现的. 当我们需要的表数据发生了变化, 可以在缓存服务获取变化之后的数据, 更新到缓存.

这种方式的好处是对业务代码零侵入.

知识点5 Redis持久化

第一种 RDB

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

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

RDB的执行原理？

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。

另一种:AOF

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

知识点6 数据过期策略

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

优点 ：对CPU友好，只会在使用该key时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查
缺点 ：对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放

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

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

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

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

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

数据淘汰策略-使用建议

• 优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。
• 如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。
• 如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。
• 如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略。

知识点8 分布式锁

在单机状态, 在抢券场景下, 需要对库存加锁, 防止超卖

而在服务集群部署的情况下

不同的Tomcat有不同的JVM, 这个时候就需要分布式锁了.

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

获取锁：

释放锁：

但是单纯的SetNX还很不完善, 存在以下问题, 我们选择现成的方案 Redisson.

重入问题：重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。

不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。

超时释放: 我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患。

主从一致性： 如果Redis提供了主从集群，当我们向集群写数据时，主机需要异步的将数据同步给从机，而万一在同步过去之前，主机宕机了，就会出现死锁问题。

redisson实现的分布式锁是可重入的, 利用hash结构记录线程id和重入次数

对于主从一致性, Redisson提供了RedLock(红锁)：不能只在一个redis实例上创建锁，应该是在多个redis实例上创建锁(n / 2 + 1)，避免在一个redis实例上加锁。

知识点9 主从复制

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

主从数据同步原理

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

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

主从全量同步：

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

知识点10 哨兵模式

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哨兵模式中的脑裂现象（Split-Brain）是指当集群中的主节点（Master）与其它节点（Slaves）失去联系后，哨兵节点（Sentinels）会自动选举一台从节点作为新的主节点。但有时候，当网络发生分区（Network partition）时，主节点与一部分从节点无法通信，而另一部分从节点可以与主节点正常通信。这种情况下，可能会出现两个分区各自选举出不同的主节点，导致出现多个主节点同时存在的情况，这就是脑裂现象。

脑裂现象会导致数据一致性和可用性的问题，因此需要一些机制来避免或者解决这种情况。Redis中可以通过设置quorum来保证只有超过一半的哨兵节点才能进行选举，从而避免脑裂现象的发生。此外，还可以通过增加哨兵节点数量来提高系统的健壮性。

知识点11 分片集群

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

• 海量数据存储问题
• 高并发写的问题

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

分片集群结构-数据读写

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

知识点12 IO多路复用

用户空间和内核空间

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

Redis问答

1 什么是缓存穿透 ? 怎么解决 ?

缓存穿透是指在请求数据时, 在缓存中查不到, 在数据库也查不到的现象.

由于数据库中没有数据, 所以无法建立缓存来缓解数据库压力.

导致这个请求每次都会查询数据库, 给数据库造成压力.

解决办法呢 一般有两种

第一种就是在缓存中缓存空值, 但是有可能会造成短期的数据不一致

第二种呢就是使用布隆过滤器, 当查询到数据不存在时直接返回, 缺点呢是实现起来比较复杂, 有一定的误判率

2 你能介绍一下布隆过滤器吗？

布隆过滤器主要是用来判断一个元素是不是在一个集合里边. 我们使用的是Redisson提供的布隆过滤器.

布隆过滤器的底层呢, 是一个比较大的数组, 里面存二进制的数据.

当来了一个数据, 就经过三次哈希, 将对应的三个位置数据置为1.

查找就是看它三次哈希完了那个位置上是不是都是1, 都是1就认为它在这里面

布隆过滤器会产生一定的误判, 这个误判率是可以设置的, 占用的存储空间越大误判率就越低.

3 什么是缓存击穿 ? 怎么解决?

缓存击穿就是热点Key刚好过期了, 而他的重建缓存时间又比较长, 这个时候大量请求同时进入数据库, 可能会把数据库压垮

解决办法呢一般有两种

一种呢就是互斥锁, 只让一个线程拿到锁去重建缓存, 其他的线程等待. 这种方案能保证强一致性, 但是性能较差

另一种呢就是逻辑过期, 这个方案就是数据永不过期, 但是会有一个过期时间字段标识数据是否过期. 当查询缓存时发现这个数据过期了就开启一个独立线程去重建缓存, 重建期间所有请求拿到的都是过期数据. 这种方案具有高可用性, 但不保证数据的绝对一致.

4 什么是缓存雪崩 ? 怎么解决 ?

缓存雪崩呢就是大量缓存同时过期, 导致大量请求同时到达数据库, 给数据库造成巨大压力. 这个也可能由Redis服务宕机导致

解决办法呢主要

第一针对缓存设置随机的TTL

第二呢搭建Redis的集群保障缓存服务的高可用

第三呢可以给业务加一个限流策略作为兜底

第四可以考虑搭建多级缓存

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

对于商铺查询缓存, 虽然是热点数据, 但是实时性要求并没有那么高.

我采用的是先更新数据库再删除缓存的方案. 在查询缓存未命中时, 查询数据库, 将数据库的结果写入缓存, 并设置超时时间.

---

而对于优惠券这种数据, 我采用的是Redisson分布式锁来实现的.

6 Redis做为缓存，数据的持久化是怎么做的？

Redis提供了两种数据持久化方案, RDB和AOF

RDB (Redis Database Backup file)是数据库备份文件, 它是将Redis内存存储的数据写到磁盘上. 默认开启

AOF是Append Only File, 他保存了Redis的每一个写命令. 默认关闭

如果可以容忍数分钟的数据丢失, 追求更快地启动速度, 选择RDB;

如果对数据安全性要求较高, 可以选择AOF. 一般二者结合使用.

7 Redis的数据过期策略有哪些 ?

Redis是惰性删除和定期删除两种策略结合使用滴

惰性删除是指Key过期了不管他, 访问到它发现他过期了就把他删掉

定期删除是指每隔一段时间就对一些Key做检查, 删除里面过期的Key. 分为Slow模式和Fast模式

8 Redis的数据淘汰策略有哪些 ?

有八种数据淘汰策略. 默认是noeviction, 内存满了就不写入新数据, 也不淘汰任何Key, 直接报错.

其余策略大致分为LRU和LFU,

LRU是最近最少使用, LFU是最少频率使用.

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

可以使用 allkeys-lru （挑选最近最少使用的数据淘汰）淘汰策略，那留下来的都是经常访问的热点数据

10 redis分布式锁，是如何实现的？

可以基于Redis的setnx命令实现, set if not exists. 结合ex过期避免死锁

但是自己实现的通常会存在以下问题

重入问题 不可重试 超时释放 主从一致

Redisson则是比较成熟的解决方案

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

Redisson可以对锁的超时时间和最大等待时间做设置,

当锁的一个业务没有完成的时候, 在Redisson中引入了一个看门狗机制, 就是每隔一段时间检查当前业务是否还持有锁, 如果持有就增加锁的持有时间.

也就是说，如果一个拿到锁的线程一直没有完成逻辑，那么看门狗会帮助线程不断的延长锁超时时间，锁不会因为超时而被释放。

12 Redisson的这个锁，可以重入吗？

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

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

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

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

在Redis中提供的集群方案总共有三种：主从复制、哨兵模式、Redis分片集群

15 那你来介绍一下主从同步

嗯，是这样的，单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，可以搭建主从集群，实现读写分离。一般都是一主多从，主节点负责写数据，从节点负责读数据，主节点写入数据之后，需要把数据同步到从节点中

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

主从同步分为两个阶段, 全量同步和增量同步

全量同步大概有这么个步骤

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

2 主节点判断从节点是不是第一次请求, 是第一次就与从节点同步版本信息

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

4 rdb生成期间, 主节点会把接收到的命令记录到缓冲区(一个日志文件)

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

增量同步呢

从节点向主节点请求数据, 主节点发现不是第一次请求, 根据从节点的offset值将offset之后的数据发送给从节点进行同步

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

可以搭建主从集群实现读写分离,

再加上哨兵模式, 实现主从集群的自动故障恢复. 当指定数量以上的哨兵监测认为master节点主观下线了, 就会从slave节点中选举出新的master.

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

我们当时采用的是一主一从加哨兵.

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

这个在项目中很少见

关于脑裂我的理解是这样的, 他是由于网络原因导致哨兵认为主节点下线, 选举出了新的主节点, 但是实际上主节点并没有下线, 这样就存在了两个master, 就跟大脑分裂了一样

网络恢复后, 老的master会被降为slave, 从新的master中同步数据, 这样会导致老master中大量数据丢失

解决办法呢 一是增加哨兵节点, 二是配置正确的quorum,就是当足够多的哨兵认为其主观下线了才客观下线该master

20 redis的分片集群有什么作用

集群中有多个master可以保存不同数据, 可以存储海量数据, 实现高并发写

然后呢 每个master又可以有多个slave节点, 可以高并发读

master之间可以ping互相监测彼此健康状态

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

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

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

将16384个哈希槽分配到不同的实例

读写数据是根据Key的有效部分计算哈希值, 对16384取余, 余数作为插槽, 寻找插槽所在的实例.

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

Redis是纯内存操作, 执行速度很快

使用单线程, 可以避免不必要的上下文切换, 也不用考虑线程安全问题

使用IO多路复用模型

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

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

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

Redis捏就是使用IO多路复用结合事件的处理器来应对多个Socket请求

分为连接应答处理器 - 命令回复处理器 - 命令请求处理器

在Redis6.0的时候, 使用了多线程来处理回复事件, 命令的转换也使用了多线程,

命令的执行仍然是单线程