学习之前先来看看对于以下问题你是否能跟面试官侃侃而谈呢?
下面一起来聊聊吧
我看你做的项目中,都用到了redis,你在最近的项目中哪些场景使用了redis呢?
这个时候一定要结合项目来回答
缓存
缓存三兄弟(穿透、击穿、雪崩)、双写一致、持久化、数据过期策略、数据淘汰策略
分布式锁
setnx、redisson
消息队列、延迟队列
何种数据结构
缓存穿透:查询一个不存在的
数据,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、什么是缓存穿透?怎么解决
缓存击穿:给某一个key设置了过期时间
,当key过期的时候,恰好这个时间点对这个key有大量的并发请求过来,这些并发的请求可能会瞬间把DB压垮
还是上面的栗子:
解决方案一:互斥锁
解决方案二:逻辑过期
我们先来看一下采用互斥锁方案
优点:强一致
缺点:性能差
接下来看一下使用逻辑过期方案
优点:高可用(先返回一个数据再说)、性能优
缺点:不能保证数据的绝对一致
缓存击穿:
缓存击穿:给某一个key设置了过期时间,当key过期的时候,恰好这个时间点对这个key有大量的并发请求过来,这些并发的请求可能会瞬间把DB压垮
解决方案一:互斥锁,强一致,性能差
解决方案二:逻辑过期,高可用,性能优,不能保证数据绝对一致
缓存雪崩 : 是指在同一时段大量的缓存key同时失效
或者Redis服务宕机
,导致大量请求到达数据库,带来巨大压力。
解决方案:
利用Redis集群
提高服务的可用性 哨兵模式、集群模式降级限流策略
nginx或gateway 保底策略多级缓存
Guava或CaffeineRedis作为缓存,Mysql的数据如何与redis进行同步呢?
设置前提,首先介绍自己的业务背景,有两种情况
我们先来看第一种情况:数据的强一致性
双写一致性:当修改了数据库的数据也要同时更新
缓存的数据,缓存和数据库的数据要保存一致
延时双删
这里其实有问题:先删除缓存呢?还是先修改数据库呢?
其实无论先删除缓存还是先删除数据库都有问题,所以采用双删
的策略
那为什么要延时呢?其实啊一般情况下数据库是主从模式
,读写分离
,我们延时一会儿,让主节点将数据同步到从节点
。
但是这个延时的时间不好控制,延时双删并不能保证强一致性,也有脏数据的风险
要想保证数据的强一致性,可以使用分布式锁
但是性能较低,可以优化一下:
我们知道,缓存的数据一般是读多写少的情况,我们可以使用读写锁
进行控制
对比分布式锁,性能提升了,也能保证数据的强一致性
具体的代码实现:
第二种情况:允许短暂的数据不一致,在实际的业务开发中用的最多
我们通过异步通知
保证数据的最终一致性
基于MQ的异步通知:
基于canal的异步通知:
Redis作为缓存,mysql的数据如何与Redis进行同步呢?(双写一致性)
介绍自己简历上的业务,我们当时是把讲师的热点数据存入到了缓存中,虽然是热点数据,但是实时要求性并没有那么高,所以,我们当时采用的是异步的方案同步的数据
我们当时是把抢券的库存存入到了缓存中,这个需要实时的进行数据同步,为了保证数据的强一致,我们当时采用的是redisson提供的读写锁来保证数据的同步
介绍下异步的方案(介绍下Redisson读写锁的方案)
在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和内存资源 |
使用场景 | 可以容忍数分钟的数据丢失,追求更快的启动速度 | 对数据安全性要求较高常见 |
假如Redis的key过期后,会立即删除吗?
Redis对数据设置 数据的有效时间
,数据过期以后,就需要将数据从内存中删除掉。
可以按照不同的规则进行删除,这种删除规则就被称之为数据的删除策略(数据过期策略)
Redis数据删除策略-惰性删除
惰性删除:设置该key过期后,我们不去管它,当需要该key时,我们再检查其是否过期,如果过期,我们就删掉它;反之返回该key
优点 :对CPU友好,只会在使用该key时才会进行过期检查,对于很多用不到的key不用浪费时间进行过期检查
缺点 :对内存不友好,如果一个key已经过期,但是一直没有使用,那么该key就会一直存在内存中,内存永远不会释放
Redis数据删除策略-定期删除
定期删除:每隔一段时间,我们就对一些key进行检查,删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查,并删除其中的过期key)
定期清理有两种模式:
优点:可以通过限制删除操作执行的时长和频率
来减少删除操作对CPU的影响。另外定期删除,也能有效释放过期key占用的内存
缺点:难以确定删除操作执行的时长和频率
Redis的过期删除策略:惰性删除 + 定期删除两种策略进行配合使用
Redis的数据过期策略?
惰性删除:访问key的时候判断是否过期,如果过期,则删除
定期删除:定期检查一定量的key是否过期( SLOW模式+ FAST模式)
假如缓存过多,内存是有限的,内存被占满了怎么办?(数据淘汰策略)
数据淘汰策略:
当Redis中的内存不够用时,此时再向Redis中添加新的key,那么Redis就会按照某种规则将内存中的数据删除掉。
Redis支持8种不同的策略来选择要删除的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 策略。
数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ?
使用allkeys-lru
(挑选最近最少使用的数据淘汰)淘汰策略,留下来的都是经常访问的热点数据
Redis的内存用完了会发生什么?
主要看数据淘汰策略是什么?如果是默认的配置( noeviction ),会直接报错
数据淘汰策略:
Redis提供了8种不同的数据淘汰策略,默认是noeviction不删除任何数据,内存不足直接报错
LRU:最近最少使用。用当前时间减去最后一次访问时间,这个值越大则淘汰优先级越高。
LFU:最少频率使用。会统计每个key的访问频率,值越小淘汰优先级越高
平时开发过程中用的比较多的就是allkeys-lru
(结合自己的业务场景)
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实现的分布式锁
Redis集群有哪些方案, 知道嘛?
在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的并发能力,就需要搭建主从集群,实现读写分离。
一般都是一主多从,主节点负责写数据,从节点负责读数据
能说一下,主从同步数据的流程
全量同步:
从节点请求主节点同步数据(replication id、 offset )
主节点判断是否是第一次请求,是第一次就与从节点同步版本信息(replication id和offset)
主节点执行bgsave,生成rdb文件后,发送给从节点去执行
在rdb生成执行期间,主节点可能会接收其他的命令,把命令记录到缓冲区(一个日志文件)
把生成之后的命令日志文件发送给从节点进行同步
增量同步:
从节点请求主节点同步数据,主节点判断不是第一次请求,不是第一次就获取从节点的offset值
主节点从命令日志中获取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集群脑裂
这是一个正常的主从架构,配合了哨兵模式。现在由于网络原因,这个主节点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的配置,可以设置最少的从节点数量以及缩短主从数据同步的延迟时间,达不到要求就拒绝请求,就可以避免大量的数据丢失
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决:
海量数据存储问题
高并发写的问题
使用分片集群可以解决上述问题,分片集群特征:
集群中有多个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本身做为有效部分)余数做为插槽,寻找插槽所在的实例
Redis是单线程的,但是为什么还那么快
Redis是纯内存操作,执行速度非常快
采用单线程,避免不必要的上下文切换可竞争条件,多线程还要考虑线程安全问题
使用I/O多路复用模型,非阻塞IO
能解释一下I/O多路复用模型?
Redis是纯内存操作,执行速度非常快,它的性能瓶颈是网络延迟
而不是执行速度, I/O多路复用模型主要就是实现了高效的网络请求
要聊清楚上面的问题,需要了解以下概念
用户空间和内核空间
常见的IO模型
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之后,将命令的转换使用了多线程,增加命令转换速度,在命令执行的时候,依然是单线程
本文笔者参考了黑马面试视频整理,不得不说,黑马的视频讲的真的很棒
传送门:黑马面试专题