当前位置: 首页 > article >正文

面试题:Redis(一)

1. redis是单线程还是多线程?

2. IO多路复用听说过么?

3. Redis为什么快?

1. Redis是单线程还是多线程?

版本不同,Redis基于的架构也不同,所以单单问是单还是多线程并不严谨

3.x 之前 redis都是单线程

4.x 开始逐渐引入多线程,负责客户端请求处理时是单线程,但是添加了(异步删除)

6.x 开始确定为多线程

2. 厘清Redis是单线程是何意义? 

Redis单线程

主要是指Redis网络IO和键值对读写都是由一个线程完成,Redis处理客户端请求时主要包括:内容获取(Socker读)、解析、执行、内容返回(Socket写)等都是由主线程单独完成,这就是所谓的”单线程“,这也是Redis对外提供键值对读写服务的主要流程

但Redis的其他功能比如(持久化RDB、AOF、集群数据同步、异步删除)等都是由额外线程完成的

Redis工作命令是单线程,但是对于整个Redis来说是多线程

3. Redis3.x单线程时代性能依旧很快的主要原因?

他的大体意思是说 Redis 是基于内存操作的,因此他的瓶颈可能是机器的内存或者网络带宽而并非 CPU,既然 CPU 不是瓶颈,那么自然就采用单线程的解决方案了,况且使用多线程比较麻烦。但是在 Redis 4.0 中开始支持多线程了,例如后台删除、备份等功能。

 简单来说Redis4.x之前使用单线程主要有以下3个原因:

1. 使用单线程模型使Redis开发和维护更加简单,因为单线程模型方便开发和调试

2. 即使使用单线程模型也可以并发的处理多客户端请求,主要是使用IO多路复用和非阻塞IO

3. Redis的性能瓶颈主要是内存和网络带宽,并非CPU

4. 为什么逐渐加入多线程特性? 

单线程的局限

正常情况下Redis可以很快删除数据,而当删除的数据包含成千上万个hash集合时,del指令会造成线程卡顿

这也是Redis3.x单线程时代的经典故障,大key删除问题

由于redis是单线程的,del  bigKey .....

等待很久这个线程才会释放,类似加了一个synchronized锁,你可以想象高并发下,程序堵成什么样子?

解决方案

使用惰性删除可以有效避免Redis卡顿问题

因此在Redis4.x之后引入多线程实现数据的异步惰性删除等功能,但是处理数据读写功能仍由一个线程完成,所有Redis此时还算是狭义上的单线程

 5. Redis的性能瓶颈

在Redis6/7中,非常受关注的第一个新特性就是多线程。

这是因为,Redis一直被大家熟知的就是它的单线程架构,虽然有些命令操作可以用后台线程或子进程执行(比如数据删除、快照生成、AOF重写)。但是,从网络IO处理到实际的读写命令处理,都是由单个线程完成的。

 

随着网络硬件的性能提升,Redis的性能瓶颈有时会出现在网络IO的处理上,也就是说,单个主线程处理网络请求的速度跟不上底层网络硬件的速度,

 

为了应对这个问题:

采用多个IO线程来处理网络请求,提高网络请求处理的并行度,Redis6/7就是采用的这种方法。

 

但是,Redis的多IO线程只是用来处理网络请求的,对于读写操作命令Redis仍然使用单线程来处理。这是因为,Redis处理请求时,网络处理经常是瓶颈,通过多个IO线程并行处理网络操作,可以提升实例的整体处理性能。而继续使用单线程执行命令操作,就不用为了保证Lua脚本、事务的原子性,额外开发多线程互斥加锁机制了(不管加锁操作处理),这样一来,Redis线程模型实现就简单了

为解决网络io问题redis开启多个网络io线程,当有请求读写操作时主线程会到对应的io线程执行相对应的命令操作

多线程之前

I/O 的读和写本身是堵塞的,比如当 socket 中有数据时,Redis 会通过调用先将数据从内核态空间拷贝到用户态空间,再交给 Redis 调用,而这个拷贝的过程就是阻塞的,当数据量越大时拷贝所需要的时间就越多,而这些操作都是基于单线程完成的。

加入网络io多线程之后

从Redis6开始,就新增了多线程的功能来提高 I/O 的读写性能,他的主要实现思路是将主线程的 IO 读写任务拆分给一组独立的线程去执行,这样就可以使多个 socket 的读写可以并行化了,采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络IO的时间消耗),将最耗时的Socket的读取、请求解析、写入单独外包出去,剩下的命令执行仍然由主线程串行执行并和内存的数据交互。

结合上图可知,网络IO操作就变成多线程化了,其他核心部分仍然是线程安全的,是个不错的折中办法。

Redis6→7将网络数据读写、请求协议解析通过多个IO线程的来处理 ,

对于真正的命令执行来说,仍然使用主线程操作

演变总结

Redis自身出道就是优秀,基于内存操作、数据结构简单、多路复用和非阻塞 I/O、避免了不必要的线程上下文切换等特性,在单线程的环境下依然很快;

 

但对于大数据的 key 删除还是卡顿厉害,因此在 Redis 4.0 引入了多线程unlink key/flushall async 等命令,主要用于 Redis 数据的异步删除;

 

而在 Redis6/7中引入了 I/O 多线程的读写,这样就可以更加高效的处理更多的任务了,Redis 只是将 I/O 读写变成了多线程,而命令的执行依旧是由主线程串行执行的,因此在多线程下操作 Redis 不会出现线程安全的问题。


http://www.kler.cn/news/339198.html

相关文章:

  • 提升外贸营销效果,EDM策略与实践分享
  • Spring Boot读取resources目录下文件(打成jar可用),并放入Guava缓存
  • HJDQN环境配置
  • 栈_1(2024年10月08日)
  • 机器学习-支撑向量机SVM
  • 你要一直骑,骑到越来越远|VELO Senso TT坐垫,伴你大胆向前~
  • 老古董Lisp实用主义入门教程(12):白日梦先生的白日梦
  • 【SQL】DDL语句
  • vue3导入本地图片2种实现方法
  • [ESP32]ESP-IDF使用组件添加U8g2图形库
  • 1978 C. Manhattan Permutations
  • 网络编程(15)——服务器如何主动退出
  • SpringBoot中如何集成OSS对象存储服务
  • 数学基础-向量投影
  • 头歌实践教学平台 大数据编程 实训答案(二)
  • Vue基础指令用法
  • 【信息论基础第四讲】信息的流动——平均互信息及其性质
  • Java8新特性, 函数式编程及Stream流用法大全
  • 重装 open-vm-tools
  • 网络通信——OSPF和RIP的区别(总结)