Redis的线程问题

redis是单线程还是多线程

首先应该清楚的是，redis的线程选择是根据版本进行更新的，所以不能单独的说redis是单线程还是多线程。

redis的版本有很多3.x，4.x，6.x，7.x

1.在redis3.x版本的时候redis是单线程实现的 

2.在redis4.x版本的时候，严格意义来说也不是单线程，而是负责处理客户端请求的线程是单线程，但是开始加了点多线程的东西(异步删除)

3.2020年5月版本的6.0.x后及2022年出的7.0版本后，告别了大家印象中的单线程，用一种全新的多线程来解决问题

redis的单线程是指什么

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

但Redis的其他功能，比如持久化RDB、AOF、异步删除、集群数据同步等等，其实是由额外的线程执行的。

Redis命令工作线程是单线程的，但是，整个Redis来说，是多线程的；

redis在单线程下还能很快地工作的的原因有

基于内存操作：redis所有的操作都是存在内存中的，所以所有的操作都是内存级别的，所以高性能

数据结构简单：Redis的数据结构都是专门设计的，这些简单的数据结构的查找和操作的时间复杂度大多都是o(1)

IO多路复用和非阻塞I/O：Redis使用I/O多路复用来监听多个socket连接客户端，这样可以一个线程处理多个请求，减少线程切换带来的开销，同时也避免了I/O阻塞操作

避免上下文切换：因为是单线程模型，所以避免了不必要的线程切换和多线程竞争问题，这样就省去了多线程切换带来时间和性能上的消耗，，而且单线程不会导致死锁问题

Redis4.x之前一直使用单线程的原因

1.使用单线程模型使Redis的开发和维护更加的简单，因为单线程下便于调试和维护

2.通过IO多路复用和非阻塞I/O，使Redis即便在单线程的情况下也能并发处理多客户端的请求

3.对于Redis而言，性能瓶颈主要在内存和网络带宽，并非CPU

为什么Redis需要多线程

对经典的问题就是Redis的大key删除问题

正常情况下使用 del 指令可以很快的删除数据，而当被删除的 key 是一个非常大的对象时，例如时包含了成千上万个元素的 hash 集合时，那么 del 指令就会造成 Redis 主线程卡顿。由于redis是单线程工作，del bigkey需要很久才能完成释放线程，那么在高并发的情况下会极度影响程序的性能

采用惰性删除

unlink key

flushdb async

flushall async

把删除工作交给了后台的小弟（子线程）异步来删除数据了。

因为Redis是单个主线程处理，redis之父antirez一直强调"Lazy Redis is better Redis".

而lazy free的本质就是把某些cost(主要时间复制度，占用主线程cpu时间片)较高删除操作，

从redis主线程剥离让子线程来处理，极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题。

Redis6/7多线程特性和I/O多路复用

对于redis的性能瓶颈主要是网络带宽和内存并非CPU

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

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

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

为了应对这个问题:

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

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

Unix网络编程中的五中网络模型

Blocking IO--阻塞IO

NoneBlocking IO--非阻塞IO

signal driven IO--信号驱动IO

asynchronous IO--异步IO

IO multiplexing--IO多路复用

IO多路复用什么？

是一种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪就能通知到对应的应用程序进行相应的读写操作，没有文件句柄就绪时就会阻塞应用程序，从而释放CPU资源

文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

也就是说一个或者一组线程呢能够处理多个TCP连接，使用单进程也能处理多个客户端的连接，无需创建或者维护过多的线程或者进程

实现IO多路复用的模型有三种：select  poll  epoll

场景体验：

模拟一个tcp服务器处理30个客户socket。

假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：

 

第一种选择(轮询)：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误,你用循环挨个处理socket，根本不具有并发能力。

 

第二种选择(来一个new一个，1对1服务)：你创建30个分身线程，每个分身线程检查一个学生的答案是否正确。 这种类似于为每一个用户创建一个进程或者线程处理连接。

 

第三种选择(响应式处理，1对多服务)，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。这种就是IO复用模型。Linux下的select、poll和epoll就是干这个的。

将用户socket对应的文件描述符(FileDescriptor)注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。

在单个线程通过记录跟踪每一个Sockek(I/O流)的状态来同时管理多个I/O流. 一个服务端进程可以同时处理多个套接字描述符。目的是尽量多的提高服务器的吞吐能力。

大家都用过nginx，nginx使用epoll接收请求，ngnix会有很多链接进来， epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。redis类似同理，这就是IO多路复用原理，有请求就响应，没请求不打扰。

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

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

 

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

总结

Redis为什么那么快？

1.首先自身设计优势，redis存储在内存当中，内存IO的效率高，提高了redis的性能。

2.其次redis在命令串行执行时采用单线程，可以避免了不必要的线程切换和多线程竞争问题，这样就省去了多线程切换带来时间和性能上的消耗，，而且单线程不会导致死锁问题

3.采用了IO多路复用的网络模型，通过实现一个线程监视多个句柄文件达到单进程也能与多个客户端连接，无需创建或者维护过多的进程或者线程

4.采用epoll函数，将用户socket对应的文件描述符(FileDescriptor)注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作