Redis为什么又引入了多线程?作者也逃不过“真香定理”?

相信你一定不止一次见过Redis是单线程模式，不过说实话那只是个老版本，这个问题是一位老哥的大厂面试题，跟我分享了一下。想着自己就知道redis6.0以前一直都是单线程，到了6的版本才加入了多线程，还不是很清楚，在多方打听并且搜索之下总结了这篇文章。

一、问题概述

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命令删除一个元素，如果这个元素非常大，可能占据了几十兆或者是几百兆，那么在短时间内是不能完成的，这样一来就需要多线程的异步支持。

现在删除工作可以在后台进行。

四、总结

Redis 选择使用单线程模型处理客户端的请求主要还是因为 CPU 不是 Redis 服务器的瓶颈，所以使用多线程模型带来的性能提升并不能抵消它带来的开发成本和维护成本，系统的性能瓶颈也主要在网络 I/O 操作上；而 Redis 引入多线程操作也是出于性能上的考虑，对于一些大键值对的删除操作，通过多线程非阻塞地释放内存空间也能减少对 Redis 主线程阻塞的时间，提高执行的效率。

一句话讲完：之前用单线程是因为基于内存速度快，而且多路复用有多路复用的作用，也就是足够了，现在引入是因为在某些操作要优化，比如删除操作，因此引入了多线程。