看完本文，将可以回答三个非常常见的redis面试题
- redis到底是单线程还是多线程？
- IO多路复用听说过吗？
- redis为什么快？
redis4.0之前部分支持多线程，异步删除，redis6.之后支持多线程io
redis当年为什么选择单线程
Redis的主要是指Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取（socket读）、解析、执行、内容返回（socket写）等都由一个顺序中行的主线程处理，这就是所调的“单线程”。这也是Redis对外提供键值存储服务的主要流程
但Redis的其他功能，比如持久化RDB、AOF、异步删障、集群数据同步等等，其实是由额外的线程执行的。Redis命令工作线程是单线程的，但是整个Redis来说，是多线程的
redis3.0单线程快的主要原因
- 基于内存操作：Redis的所有数据都存在内存中，因此所有的运算都是内存级别的，所以他的性能比较高；
- 数据结构简单：Redis的数据结构是专门设计的，而这些简单的数据结构的查找和操作的时间大部分复杂度都是O（1)，因此性
- ** 多路复用和非阻塞I/O ：Redis使用 IO多路复用功能 ** 来监听多个socket连接客户端，这样就可以使用一个线程连接来处理多个请求，减少线程切换带来的开销，同时也避免了IO阻塞
- 避免上下文切换： 因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的消耗，也避免产生死锁问题
在官网中有一段这样的话
https://redis.io/docs/latest/develop/get-started/faq/
CPU 成为 Redis 瓶颈的情况并不常见，因为通常 Redis 要么是内存，要么是网络绑定的。（redis的瓶颈不在cpu，自然就可以采用单线程，反正多线程也麻烦）
从 4.0 版本开始，Redis 已经开始实现多线程操作。目前，这仅限于删除后台的对象和阻止通过 Redis 模块实现的命令。对于后续版本，计划是让 Redis 越来越线程化。（但是现在有新的要求了）
简单来说，Redis4.0之前一直采用单线程的主要原因有以下三个：
- 使用单线程模型是Redis的开发和维护更简单，因为单线程模型方便开发和调试；
- 即使使用单线程模型也并发的处理多客户端的请求，主要使用的是IO多路复用和非阻塞IO；
- 对于Redis系统来说，主要的性能瓶颈是内存或者网络带宽而并非CPU。
既然单线程这么好，为什么又逐渐加入了多线程特性
- 硬件的发展
cpu都是多核时代了，只有一个单线程对硬件的使用不是很充分，虽然cpu不是reids的瓶颈
我们都知道redis的命令都是原子的，正常情况下使用del指令可以很快的删除数据，而当被删除的key是一个非常大的对象时，例如时包含了成千上万个元素的hash集合时，那么del指令就会造成Redis主线程卡顿。
这就是redis3.x单线程时代最经典的故障，大key删除的头疼问题，
由于redis是单线程的，del bigKey….
等待很久这个线程才会释放，类似加了一个synchronized锁，你可以想象高并发下，程序堵成什么样子？
怎么解决呢？
使用惰性删除可以有效的避免大key删除的阻塞问题
比如当我（Redis）需要删除一个很大的数据时，因为是单线程原子命令操作，这就会导致Redis服务卡顿，
于是在Redis4.0中就新增了多线程的模块，当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的。
unlink key
flushdb async
flushall async
把删除工作交给了后台的小弟（子线程）异步来剧除数据了。
因为Redis是单个主线程处理，redis之父antirez一直强调"Lazy Redisis better Redis".
而lazyfree的本质就是把某些cost（主要时间复制度，占用主线程cpu时间片）较高删除操作，
从redis主线程剥离让bio子线程来处理，极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题。
redis6/7的多线程特性和lO多路复用
通过上文我们明确一个点：redis的** 主要性能瓶颈是内存或者网络带宽而非cpu **
但现在的计算机内存其实也至少16gb起步了，也很难成为瓶颈，Redis的瓶颈可以初步定为：网络IO
在Redis6/7中，非常受关注的第一个新特性就是多线程。
这是因为，Redis一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF重写）但是，从网络IO处理到实际的读写命令处理，都是由单个线程完成的。
随着网络硬件的性能提升，Redis的性能瓶颈有时会出现在网络IO的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度，
为了应对这个间题：
采用多个IO线程来处理网络请求，提高网络请求处理的并行度，Redis6/7就是采用的这种方法。
但是，Redis的多IO线程只是用来** 处理网络请求的 **，对于读写操作命令Redis仍然使用单线程来处理。这是因为，Redis处理请求时，网络处理经常是瓶颈，通过多个IO线程并行处理网络操作，可以提升实例的整体处理性能。而继续使用单线程执行命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制了（不管加锁操作处理） ，这样一来，Redis线程模型实现就简单了
在这里只是初步解析，之后源码详解部分更深入的进行分析
主线程和IO线程是怎么协作完成请求处理的
- 阶段一：服务端和客户端建立Socket连接，并分配处理线程
首先，主注程负责注收建立连接调求。当有客户端调求和实例建立Socket连接时，主细程会创建和客户端的连接，并把Socket放入全局等待队列中。紧接看，主线程通过轮询方法把Socket连接分配给I/O线程， - 阶段二：I/O线程读取并解析请求
主线程一旦把Socket分配给IO线程，就会进入阻塞状态，等特IO线程完成客户端请求读取和解析，因为有多IO0线程在并行处理，所以，这个过程很快就可以完成。 - 阶段三：主线程执行请求操作
等到IO线程解析完请求，主线程还是会以单线程的方式执行这些命令操作。 - 阶段四：IO线程回写Socket和主线程清空全局队列
当主线程执行完清求操作后，会把需要返回的结果写入缓冲区，然后，主线程会阻塞等待IO线程，把这些结果回写到Socket中，并返回给客户端，和IO线程读取和解析请求一样，IO线程回写Socket时，也是有多个线程在并发执行，所以回写Socke速度也很快。等到IO线程回写Socke完毕，主线程会清空全周队列，等待客户端的后续清求
Unix网络编程中的五种IO模型
Blocking IO-阻塞IO
NoneBlocking IO-非阻塞IO
I0multiplexing-IO多路复用
signal drivenIO-信号驱动IO
asynchronous IO-异步IO
详细说一下IO多路复用
FileDescriptor
Linux世界一切皆文件，文件描述符、简称FD，句柄
文件描述符（Filedescriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。
首次浅谈IO多路复用，IO多路复用是什么
一种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪就能够通知到对应应用程序进行相应的读写操作，没有文件句柄就绪时就会阻塞应用程序，从而释放CPU资源
I/O：网络I/O，尤其在操作系统层面指数据在内核态和用户态之间的读写操作
多路：多个客户端连接（连接就是套接字描述符，即socket或者channel）
复用：复用一个或几个线程。
IO多路复用：也就是说一个或一组线程处理多个TCP连接，使用单进程就能够实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程
一个服务端进程可以同时处理多个套接字描述符。实现lO多路复用的模型有3种：可以分select->poll->epoll三个阶段来描述。
IO复用模型
场景解析
模拟一个tcp服务器处理30个客户ocket。
假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：
第一种选择（轮询）：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有个学生卡住，全班都会被耽误，你用循环挨个处理socket，根本不具有并发能力。
第二种选择（来一个new一个，1对1服务）：你创建30个分身线程，每个分身线程检查一个学生的答案是否正确。这种类似于为每一个用户创建一个
进程或者线程处理连接。
第三种选择（响应式处理，1对多服务），你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。这种就是IO复用模型，Linux下的select、poll和epoll就是干这个的。
简单理解io多路复用
将用户socket对应的文件描述符（FileDescriptor)注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。
在单个线程通过记录跟踪每一个Sockek（I/O流）的状态来同时管理多个I/O流， 一个服务端进程可以同时处理多个套接字描述符。目的是尽量多的提高服务器的吞吐能力。
大家都用过nginx，nginx使用epoll按收请求，ngnix会有很多链按进来，epoll会把他们都监视起米，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。redis类似同理，这就是IO多路复用原理，有请求就响应，没请求不打扰。
总结来说就是：只使用一个服务端进程可以同时处理多个套接字描述符连接
客户端请求服务端时，实际就是在服务端的Socket文件中写大客户端对应的文件描述符（FileDescriptor)，如果有多个客户端同时请求服务端，为每次请求分配一个线程，类似每次来都new一个如此就会比较耗费服务端资源.因此，我们只使用一个线程来监听多个文件描述符，这就是IO多路复用
采用多路I/O复用技术可以让单个线程高效的处理多个连接请求一个服务端进程可以同时处理多个套接字描述符。
现在可以回答reids为什么这么快了：
IO多路复用+epoll函数使用，才是redis为什么这么快的直接原因，而不是仅仅单线程命令+redis安装在内存中。
I/O的读和写本身是堵塞的，比如当socket中有数据时，Redis会通过调用先将数据从内核态空间拷贝到用户态空间，再交给Redis调用，而这个拷贝的过程就是阻塞的，当数据量越大时拷贝所需要的时间就越多，而这些操作都是基于单线程完成的。
从Redis6开始，就新增了多线程的功能来提高 I/O 的读写性能，他的主要实现思路是将主线程的 IO读写任务拆分给一组独立的线程去执行,
这样就可以使多个 socket 的读写可以并行化了，采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络IO的时间消耗)，将最耗时的Socket的读取、请求解析、写入单独外包出去，剩下的命令执行仍然由主线程串行执行并和内存的数据交互。
Redis6-7将网络数据读写、请求协议解析通过多个IO线程的来处理，
对于真正的命令执行来说，仍然使用主线程操作，一举两得，便宜占尽！！！o（V）d
如果你在实际应用中，发现Redis实例的CPU开销不大但吞吐量却没有提升
可以考虑使用Redis7的多线程机制，加速网络处理，进而提升实例的吞吐量
Redis7将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redls服务器可以处理8W到10W的QPS，
这也是Redis处理的极限了，对于80%的公司来说，单线程的Redis已经足够使用了。
在Redis6.0及7后，多线程机制默认是关闭的如果需要使用多线程功能，需要在redis.conf中完成两个设置
