一、问题概述
Redis 6.0 之后的版本抛弃了单线程模型这一设计，原本使用单线程运行的 Redis 也开始选择性使用多线程模型，乍一看Redis的作者这么牛，也逃不过“真香定律”，
仔细想想，这个问题其实可以拆分，拆分为两个主要的问题：
（1）为什么 Redis 一开始选择单线程模型（单线程的好处）？
（2）为什么 Redis 在 6.0 之后加入了多线程（在某些情况下，单线程出现了缺点，多线程可以解决）？
其实，作者并不是没有逃脱真香定理，而是随着时间的推移，出现的问题也越来越多，原来的设计肯定就有些不合时宜，该做出改变就做出改变。OK，带着俩问题，我们就来好好地分析一下。
二、为什么Redis一开始使用单线程
不管是单线程或者是多线程都是为了提升Redis的开发效率，因为Redis是一个基于内存的数据库，还要处理大量的外部的网络请求，这就不可避免的要进行多次IO。好在Redis使用了很多优秀的机制来保证了它的高效率。那么为什么Redis要设计成单线程模式的呢？可以总结如下：
（1）IO多路复用
我们来看一下Redis顶层设计。
FD是一个文件描述符，意思是表示当前文件处于可读、可写还是异常状态。使用 I/O 多路复用机制同时监听多个文件描述符的可读和可写状态。你可以理解为具有了多线程的特点。
一旦受到网络请求就会在内存中快速处理，由于绝大多数的操作都是纯内存的，所以处理的速度会非常地快。也就是说在单线程模式下，即使连接的网络处理很多，因为有IO多路复用，依然可以在高速的内存处理中得到忽略。
（2）可维护性高
尽管多线程模型表现出色，但它会引入不确定性的程序执行顺序，从而带来并发读写相关的问题。单线程模式下，可以方便地进行调试和测试。
（3）基于内存，单线程状态下效率依然高
多线程能够充分利用CPU的资源，但对于Redis来说，由于基于内存速度那是相当的高，能达到在一秒内处理10万个用户请求，如果一秒十万还不能满足，那我们就可以使用Redis分片的技术来交给不同的Redis服务器。这种烹饪方法避免了在同一个 Redis 服务中引入大量的多线程操作。
除非需要进行AOF备份，否则这种操作基本上不涉及任何I/O操作，因为它是基于内存的。这些数据的读写由于只发生在内存中，所以处理速度是非常快的；用多线程模型处理全部的外部请求可能不是一个好的方案。
现在我们知道了基本上可以总结成两句话，基于内存而且使用多路复用技术，单线程速度很快，又保证了多线程的特点。因为没有必要使用多线程。
三、为什么引入多线程？
刚才我们提到了单线程的优点，但是现在我要谈一下为什么需要引入多线程，并克服对它的不适应。引入多线程说明Redis在有些方面，单线程已经不具有优势了。
因为读写网络的read/write系统调用在Redis执行期间占用了大部分CPU时间，如果把网络读写做成多线程的方式对性能会有很大提升。
Redis的多线程仅用于网络数据读写和协议解析，而命令执行仍然是单线程的。之所以这么设计是不想 Redis 因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。
Redis 在最新的几个版本中加入了一些可以被其他线程异步处理的删除操作，也就是我们在上面提到的 UNLINK、FLUSHALL ASYNC 和 FLUSHDB ASYNC，我们为什么会需要这些删除操作，而它们为什么需要通过多线程的方式异步处理？
我们知道Redis可以使用del命令删除一个元素，如果这个元素非常大，可能占据了几十兆或者是几百兆，那么在短时间内是不能完成的，这样一来就需要多线程的异步支持。
现在删除工作可以在后台进行。