Redis单线程 Vs 多线程
一 面试题引入
1.1 Redis到底是单线程还是多线程?
1.2 IO多路复用
1.3 Redis为什么快?
1.4 Subtopic
二 Redis为什么选择单线程?
2.1 这种问法其实并不严谨,为啥这么说?
Redis的版本很多3.X、4.X、6.X,版本不同架构也是不同的,不限定版本问是否单线程是不严谨的。
- 版本3.X,最早版本,Redis是单线程
- 版本4.X,严格意义来说也不是单线程,而是负责处理客户端请求的线程是单线程。但是开始加入了点多线程的东西(异步删除)。
- 2020年5月版本6.0.X后及2022年出的7.0版本后,告别了大家印象中的单线程,用一种全新的多线程来解决问题。
2.2 Redis是单线程究竟何意?
Redis是单线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的,Redis在处理客户端的请求时包括获取(socket读)、解析、执行、内容返回(socket写)等都由一个顺序串行的主线程处理,这就是所谓的“单线程”。这也是Redis对外提供键值存储服务的主要流程。
但Redis的其他功能,比如持久化RDB、AOF、异步删除、集群数据同步等等,其实是由额外的线程执行的。
Redis命令工作线程是单线程的,但是整个Redis来说,是多线程的。
2.3 Redis3.X单线程时代但性能依旧很快的主要原因
- 基于内存操作:redis的所有数据都存在内存中,因此所有的运算都是内存级别的,所以它的性能比较高。
- 数据结构简单:Redis的数据结构是专门设计的,而这些简单的数据结构的查找和操作的时间大部分复杂度都是O(1),因此性能比较高。
- 多路复用和非阻塞I/O:Redis使用I/O多路复用功能来监听多个socket连接客户端,这样就可以使用一个线程连接来处理多个请求,减少线程切换带来的开销,同时也避免了I/O阻塞操作。
- 避免上下文切换:因为是单线程模型,因此就避免了不必要的上下文切换和多线程竞争,这就省去了多线程切换带来的时间和性能上的消耗,而且单线程不会导致死锁问题的发生。
简单来说,Redis4.0之前一直采用单线程的主要原因有以下三个原因:
- 使用单线程模型使Redis的开发和维护更简单,因为单线程模型方便开发和调试。
- 即使使用单线程模式也并发的处理多客户的请求,主要使用的是IO多路复用和非阻塞IO;
- 对于Redis系统来说,
主要的性能瓶颈是内存或者网络带宽而并非CPU
。
2.4 多线程的引入及其原因
比如当Redis需要删除一个很大的数据时,因为是单线程原子命令操作,这就会导致Redis服务卡顿。
于是在Redis 4.0 中就新增了多线程的模块,当然此版本中的多线程主要是为了解决删除数据效率比较低的问题。
unlink key
flushdb async
flushall async
把删除工作交给了后台的子线程异步来删除数据。
因为Redis是单个主线程处理,redis之父antirez一直强调“Lazy Redis is better Redis”。
而lazy free的本质就是把某些cost(主要时间复制度,占用主线程cpu时间片)较高删除操作。从Redis主线程剥离让子线程来处理。极大地减少主线程阻塞时间,从而减少删除导致性能和稳定性问题。
三 Redis为什么快?
3.1 Redis性能瓶颈
对于Redis主要的性能瓶颈是内存或者网络带宽而并非CPU。
Redis6/7 真正多线程登场:
在Redis6/7中,非常受关注的第一个新特性就是多线程。这是因为,Redis一直被大家熟知的就是它的单线程架构,虽然有些命令操作可以用后台线程或子线程执行(比如数据删除、快照生成、AOF重写)。但是,从网络IO处理到实际的读写命令处理,都是由单个线程完成的。
随着网络硬件的性能提升,Redis的性能瓶颈有时会出现在网络IO的处理上,也就是说,单个主线程处理网络请求的速度跟不上底层网络硬件的速度。
为了应对这个问题:采用多个IO线程来处理网络请求,提高网络请求处理的并行度,Redis6/7就是采用这种方法。
但是,Redis的多IO线程只是用来处理网络请求的,对于读写操作命令Redis仍然使用单线程来处理。 这是因为,Redis处理请求时,网络处理经常是瓶颈,通过多个IO线程并行处理网络操作,可以提升实力的整体处理性能。而继续使用单线程执行命令操作,就不用为了保证Lua脚本、事务的原子性,额外开发多线程互斥锁机制了
,这样一来,Redis线程模型实现就简单了。
3.2 主线程和IO线程是怎么协作完成请求处理的
3.3 Unix网络编程中五种IO模型
3.3.1 Blocking IO:阻塞IO
3.3.2 NoneBlocking IO:非阻塞IO
3.3.3 IO multiplexing IO:IO多路复用
-
Linux世界一切皆文件
文件描述符、检查FD,句柄。
FileDescriptor,文件描述符是计算机科学中的一个术语,是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上,它是一个索引值,指向内核为每一个进程锁维护的该进行打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时,内核向进程返回一个文件描述符。在程序设计中,文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。 -
多路复用
一种同步的IO模型,实现一个线程监视多个文件句柄,一旦某个文件句柄就绪就能够通知到对应应用程序进行相应的读写操作,没有文件句柄就绪时就会阻塞应用程序从而释放CPU资源。
概念:- I/O:网络I/O,尤其是操作系统层面指数据在内核态和用户态之间的读写操作。
- 多路:多个客户端连接(连接就是套接字描述符,即socket或者channel)。
- 复用:复用一个或几个线程。
- IO多路复用:也就是说一个或一组线程处理多个TCP连接,使用单进程就能够实现同时处理多个客户端的连接,无需创建或者维护过多的进程/线程。
总结: 一个服务端进行可以同时处理多个套接字描述符,实现IO多路复用的模型有3种,可以分select->poll->epoll三个阶段来描述。
IO多路复用模型:
小总结: 只使用一个服务端进行可以同时处理多个套接字描述符连接。
面试题:redis为什么这么快?
IO多路复用+epoll函数使用,才是redis为什么这么快的直接原因,而不是仅仅单线程命令+redis安装在内存中。
3.3.4 signal driven IO:信号驱动IO
3.3.5 asynchronous IO:异步IO
四 简单说明
Redis工作线程是单线程的,但是对于整个Redis来说是多线程的。
问题: 主线程和IO线程是怎么协作完成请求处理的?
I/O的读和写本身是堵塞的,比如当socket中有数据时,Redis会通过调用先将数据从内核态空间拷贝到用户态空间,再交给Redis调用,而这个拷贝的过程就是阻塞的,当数据量越大时拷贝所需要的时间就越多,而这些操作都是基于单线程完成的。
从Redis6开始,就新增了多线程的功能来提高IO的读写性能,他的主要实现思路是是将主线程的IO读写任务拆分给一组独立的线程去执行,
这样就可以使用多个socket的读写可以并行化了。采用多路I/O复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络IO的时间消耗),将最耗时的Socket的读取,请求解析、写入单独外包出去,剩下的命令执行仍然由主线程串行执行并和内存的数据交互。
结合上图可知:网络IO操作就变成多线程化了,其他核心部分仍然是线程安全的,是个不错的折中办法。
Redis6/7 将网络数据读写、请求协议解析通过多个IO线程来处理,对于真正的命令执行来说,仍然使用主线程操作。
五 Redis7默认是否开启了多线程?
在实际应用中,发现Redis实例的CPU开销不大但吞吐量却没有提升
,可以考虑使用Redis7的多线程机制,加速网络处理,进而提升实例的吞吐量。
Redis7将所有的数据放在内存中,内存的响应时长大约为100纳秒,对于小数据包,Redis服务器可以处理8W到10W的QPS,这也是Redis的处理极限了。对于80%的公司来说,单线程的Redis意见足够使用了。
- 设置io-thread-do-reads配置项为yes,表示启动多线程。
- 设置线程个数。关于线程数的设置,官方的建议是如果为4核的CPU,建议线程数设置为2或3,如果为8核CPU建议线程数设置为6,线程数一定要小于机器核数,线程数并不是越大越好。