一、Redis单线程VS多线程
1.Redis的单线程部分
1.1 Redis为什么是单线程?
- Redis的版本很多3.x、4.x、6.x,版本不同架构也是不同的,不限定版本问是否单线程也不太严谨。
- 版本3.x ,最早版本,也就是大家口口相传的redis是单线程
- 版本4.x,严格意义来说也不是单线程,而是负责处理客户端请求的线程是单线程,但是开始加了点多线程的东西(异步删除)。
- 2020年5月版本的6.0.x后及2022年出的7.0版本后,告别了大家印象中的单线程,用一种全新的多线程来解决问题。
1.2 Redis所谓的“单线程”
主要是指Redis的网络IO和键值对读写是由一个线程来完成的,Redis在处理客户端的请求时包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理,这就是所谓的“单线程”。这也是Redis对外提供键值存储服务的主要流程。
但Redis的其他功能,比如持久化RDB、AOF、异步删除、集群数据同步等等,其实是由额外的线程执行的。
Redis命令工作线程是单线程的,但是,对整个Redis来说,是多线程的;
1.3 Redis演进变化
1.3.1 Redis 3.x单线程时代性能很快的原因
- 基于内存操作
- 所有Redis的数据都存在内存中,因此所有的运算都是内存级别的,所以他的性能高
- 数据结构简单
- Redis的数据结构是专门设计的,这些简单的数据结构的查找和操作时间大部分复杂度都是O(1),性能高
- 多路复用和非阻塞IO
- Redis使用I/O多路复用功能来监听多个socket连接客户端,这样可以使用一个线程来处理多个请求,减少线程切换带来额开销,同时也避免了I/O阻塞操作
- 避免上下文切换
- 因为是单线程模型,因此就避免了不必要的上下文切换和多线程竞争,这就省去了多线程切换带来的时间和性能上的消耗,而且单线程不会导致死锁问题的发生
1.3.2 Redis 4.0 之前一直采用单线程的主要原因有三个
- 使用单线程模型是 Redis 的开发和维护更简单,因为单线程模型方便开发和调试;
- 即使使用单线程模型也并发的处理多客户端的请求,主要使用的是IO多路复用和非阻塞IO;
- 对于Redis系统来说,主要的性能瓶颈是内存或者网络带宽而并非 CPU。
2. Redis单线程为什么加了多线程特性
-
因为单线程有单线程的问题,比如我要删除一个比较大的key
- del bigkey 会一直阻塞,等待删除完成,才能继续操作,会导致Redis主线程卡顿
-
所以引入了 惰性删除 可以有效避免Redis主线程卡顿
- 在 Redis 4.0 中就新增了多线程的模块,当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的。
-
unlink key flushdb async flushall async 把删除工作交给了后台的小弟(子线程)异步来删除数据了。 - 因为Redis是单个主线程处理,redis之父antirez一直强调"Lazy Redis is better Redis".
- 而lazy free的本质就是把某些cost(主要时间复制度,占用主线程cpu时间片)较高删除操作,从redis主线程剥离让BIO子线程来处理,极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题。
- 因为Redis是单个主线程处理,redis之父antirez一直强调"Lazy Redis is better Redis".
虽然引入了多个线程来实现数据的异步惰性删除等功能,但其处理读写请求的仍然只有一个线程,所以仍然算是狭义上的单线程
3.Redis 6/7 的多线程特性和IO多路复用入门篇
对于Redis 主要的性能瓶颈是内存或者网络带宽 而并非CPU
3.1 Redis 的瓶颈初步定为 网络IO
3.1.1 Redis 6/7 真正的多线程
- 在Redis6/7中,非常受关注的第一个新特性就是多线程。
- 这是因为,Redis一直被大家熟知的就是它的单线程架构,虽然有些命令操作可以用后台线程或子进程执行(比如数据删除、快照生成、AOF重写)。但是,从网络IO处理到实际的读写命令处理,都是由单个线程完成的。
- 随着网络硬件的性能提升,Redis的性能瓶颈有时会出现在网络IO的处理上,也就是说,单个主线程处理网络请求的速度跟不上底层网络硬件的速度
- 采用多个IO线程来处理网络请求,提高网络请求处理的并行度,Redis6/7就是采用的这种方法。
- 但是,Redis的多IO线程只是用来处理网络请求的,对于读写操作命令Redis仍然使用单线程来处理。这是因为,Redis处理请求时,网络处理经常是瓶颈,通过多个IO线程并行处理网络操作,可以提升实例的整体处理性能。而继续使用单线程执行命令操作,就不用为了保证Lua脚本、事务的原子性,额外开发多线程互斥加锁机制了(不管加锁操作处理),这样一来,Redis线程模型实现就简单了
- Redis 只是将 I/O 读写变成了多线程,而命令的执行依旧是由主线程串行执行的
3.1.2 主线程和IO线程的四个阶段(主线程和IO线程如何协作完成请求处理的)
- Redis6→7将网络数据读写、请求协议解析通过多个IO线程的来处理 ,对于真正的命令执行来说,仍然使用主线程操作
3.2 Unix网络编程的五种IO模型
在linux中一切都是文件
- 文件描述符(简称FD,句柄)
- 文件描述符(File descriptor)是计算机科学中的一个术语,是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上,它是一个索引值,指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时,内核向进程返回一个文件描述符。在程序设计中,文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。
- IO模型通过监视文件描述符来实现操作
Blocking IO 阻塞IO
- 使用系统调用,并一直阻塞直到内核将数据准备好,之后再由内核缓冲区复制到用户态,在等待内核准备的这段时间什么也干不了
- 下图函数调用期间,一直被阻塞,直到数据准备好且从内核复制到用户程序才返回,这种IO模型为阻塞式IO
- 阻塞式IO式最流行的IO模型
NoneBlocking IO 非阻塞IO
- 内核在没有准备好数据的时候会返回错误码,而调用程序不会休眠,而是不断轮询询问内核数据是否准备好
- 下图函数调用时,如果数据没有准备好,不像阻塞式IO那样一直被阻塞,而是返回一个错误码。数据准备好时,函数成功返回。
- 应用程序对这样一个非阻塞描述符循环调用成为轮询。
- 非阻塞式IO的轮询会耗费大量cpu,通常在专门提供某一功能的系统中才会使用。通过为套接字的描述符属性设置非阻塞式,可使用该功能
IO multiplexing IO多路复用
- IO
- 网络IO,尤其在操作系统层面指数据在内核态和用户态之间的读写操作
- 多路
- 多个客户端连接(连接就是套接字描述符,即socket 或者 channel)
- 复用
- 复用一个或几个线程
**PS:套接字描述符是访问套接字的一种路径,*套接字对*唯一标识一个网络上的每个TCP连接。
IO多路复用: 也就是一个或一组线程处理多个TCP连接,使用单进程就能够实现同时处理多个客户端的连接,无需创建或者维护过多的进程/线程
- 一个服务端进程可以同时处理多个套接字描述符
- 实现IO多路复用的模型有3种: select -> poll -> epoll 三个阶段
只使用一个服务端进程可以同时处理多个套接字描述符连接
所以Redis为什么快
- IO多路复用+epoll函数使用,才是redis为什么这么快的直接原因,而不是仅仅单线程命令+redis安装在内存中。
Signal driven IO 信号驱动IO
首先开启套接字的信号驱动式IO功能,并且通过sigaction(信号处理程序) 系统调用安装一个信号处理函数 ,该函数调用将立即返回,当前进程没有被阻塞 ,继续工作;当数据报准备好的时候,内核为该进程产生SIGIO 的信号,随后既可以在信号处理函数中调用recvfrom 读取数据报,并且通知主循环数据已经准备好等待处理;也可以直接通知主循环让它读取数据报;(其实就是一个待读取的通知和待处理的通知),基本不会用到。
Asynchronous IO 异步IO
线程和多进程的模型虽然解决了并发的问题,但是系统不能无限的增加线程,由于系统的切换线程的开销恒大,所以,一旦线程数量过多,CPU的时间就花在线程的切换上,真正运行代码的时间就会减少,结果导致性能严重下降
由于我们要解决的问题是CPU高速执行能力和IO设备的龟速严重不匹配,多线程和多进程只是解决这一个问题的一种方法。
另一种解决IO问题的方法是异步IO,当代码需要执行一个耗时的IO操作时,他只发出IO指令,并不等待IO结果然后就去执行其他代码,一段时间后,当IO返回结果是,在通知CPU进行处理
我们调用aio_read函数,给内核传递描述符,缓冲区指针,缓冲区大小,和文件偏移量,并且告诉内核当整个操作完成时如何通知我们,该函数调用后,立即返回,不会被阻塞
另一方面:从kernel的角度,当他收到一个aio_read之后,首先它立即返回,所以不会对用户进程产生block,然后kernel会等待数据准备完成,然后将数据拷贝到用户内存(copy由内核完成),当着一切完成后,kernel会给用户进程发送一个singal或者执行下一个基于线程回调函数来完成此次IO处理过程,告诉他read操作完成
3.3 Redis7开启多线程
在单机模式下,可以开启多线程,但是在其他模式,最好不开启
Redis实例的 CPU开销不大但吞吐量却没有提升,可以考虑使用Redis7的多线程机制,加速网络处理,进而提升实例的吞吐量
- 注意线程数
- 官方的建议是如果为 4 核的 CPU,建议线程数设置为 2 或 3,如果为 8 核 CPU 建议线程数设置为 6,线程数一定要小于机器核数,线程数并不是越大越好。
- 设置io-thread-do-reads配置项为yes,表示启动多线程。