原创 Redis选择单线程模型的原因分析

双线程的程序可以支持每秒几百万的请求量，众所周知，Redis 作为被广泛使用的内存数据库偏偏选择了单线程模型，这又是为什么呢？其实简单概括起来主要有以下三个原因，方便维护，可以并发的处理任务以及双线程不能解决Redis的性能瓶颈。下面我们来仔细分析一下Redis选择单线程模型的原因。

原因一：单线程模型更方便维护

相信我们都了解可维护性对一个项目的重要性，而Redis 使用单线程模型能带来更好的可维护性，方便开发和调试。如果代码难以调试和测试，问题也经常难以复现，这对于任何一个项目来说都会严重地影响项目的可维护性。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，代码的执行过程不再是串行的，多个线程同时访问的变量如果没有谨慎处理就会带来诡异的问题。而多线程带来的问题是很明显的，如果计算机中的两个进程（线程同理）同时尝试修改一个共享内存的内容，在没有并发控制的情况下，最终的结果依赖于两个进程的执行顺序和时机，如果发生了并发访问冲突，最后的结果就会是不正确的。

原因二：可以并发的处理任务。

虽然，Redis选择了单线程模型，但是这也不影响它能并发的处理客户端的请求。Redis 服务中运行的绝大多数操作的性能瓶颈都不是 CPU。用单线程模型也并不意味着程序不能并发的处理任务，Redis 虽然使用单线程模型处理用户的请求，但是它却使用 I/O 多路复用机制并发处理来自客户端的多个连接，同时等待多个连接发送的请求。在 I/O 多路复用模型中，最重要的函数调用就是 select 以及类似函数，该方法的能够同时监控多个文件描述符（也就是客户端的连接）的可读可写情况，当其中的某些文件描述符可读或者可写时，select 方法就会返回可读以及可写的文件描述符个数。使用 I/O 多路复用技术能够极大地减少系统的开销，系统不再需要额外创建和维护进程和线程来监听来自客户端的大量连接，减少了服务器的开发成本和维护成本

原因三：双线程不能解决Redis的性能瓶颈

这也是Redis选择单线程模型的最核心的原因。虽然多线程技术的能够帮助我们充分利用 CPU 的计算资源来并发的执行不同的任务，但是 CPU 资源往往都不是 Redis 服务器的性能瓶颈。哪怕我们在一个普通的 Linux 服务器上启动 Redis 服务，它也能在 1s 的时间内处理 1,000,000 个用户请求。

如果这种吞吐量不能满足我们的需求，更推荐的做法是使用分片的方式将不同的请求交给不同的 Redis 服务器来处理，而不是在同一个 Redis 服务中引入大量的多线程操作。所以Redis 并不是 CPU 密集型的服务，如果不开启 AOF 备份，所有 Redis 的操作都会在内存中完成不会涉及任何的 I/O 操作，这些数据的读写由于只发生在内存中，所以处理速度是非常快的；整个服务的瓶颈在于网络传输带来的延迟和等待客户端的数据传输，也就是网络 I/O，所以使用多线程模型处理全部的外部请求可能不是一个好的方案。

Redis选择单线程模型的原因分析就讲到这里了，综上所述，Redis选择单线程模型的好处更多，使用双线程其实是完全没有必要的。当然，以上的分析可能已经打破了大家对于单线程的固有印象，因此不是说双线程就一定比单线程好，又结合具体的实际情况来分析。