在Reactor模式下，处理web请求时通常有两种体系结构：基本架构、事件驱动架构
基于线程的thread-based architecture体系结构通常使用多线程处理来自客户端的请求。每当接收到一个请求，便开启一个独立的线程来处理这种方案是直观的，但是由于仅适用于并发访问量不大的场景是线程需要占用一定的内存资源，且操作系统在线程之间的切换也需要一定的开销，如果线程数量过多，web服务器的性能明显下降。 以及当线程在处理I/O操作，在等待输入的这段时间线程处于空闲的状态，同样也会造成cpu资源的浪费典型设计如下。
事件驱动体系结构是当前广泛使用的体系结构之一。 此方式为定义一系列的事件处理器来响应事件的发生，然后为将服务端接受连接与对事件的处理分离。 其中，事件是状态的变化。 例如，在tcp中，socket的new incoming connection、ready for read、ready for write。
reactor reactor设计模式采用event-driven architecture的实现方式处理多个客户端同时向服务器端请求服务的场景。每种服务在服务端可能由多个方法组成reactor同时解除绑定请求的服务，并将其分发给相应的事件处理器进行处理。 目前，许多常见的开源框架都使用包含Java nio的reactor模型，例如netty、node.js等。
Redis单线程模型详细了解Redis 基于 Reactor 模式来设计开发了自己的一套高效的事件处理模型。 (Netty的线程模型也基于Reactor模式，Reactor模式不愧是高性能IO的基础)。 该事件处理模型对应于Redis的文件事件处理器（file event handler）。 Redis通常被称为单线程模型，因为文件事件处理器(file event handler )在单线程中工作。
既然是单线程，那怎么监听大量的客户端连接呢？
Redis在IO 多路复用程序上侦听来自客户端的大量连接，并在将感兴趣的事件及类型(读、写）注册到内核中并监听每个事件是否发生上。
这样的好处很明显。 http://www.Sina.com/(与nio的Selector组件类似。
此外，Redis服务器是事件驱动程序，服务器需要处理两种类型的事件。 1 .文件事件； 2 .时间事件。
时间上的事件不需要花时间知道。 我们接触最多的还是I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接，降低了资源的消耗()客户端进行读写等操作，涉及一系列网络通信。
Redis基于Reactor模式开发了自己的网络事件处理器。 这个处理器被称为文件事件处理器(file event handler )。 文件处理器文件事件
当监听到的套接字准备执行连接应答(accept )、读取)、写入)、关闭)等操作时，发生与操作对应的文件事件，此时文件事件处理器与套接字相关联
文件事件处理器在单线程中运行，但通过使用I/O复用器接收多个套接字，文件事件处理器可以使用使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字，并根据 套接字目前执行的任务来为套接字关联不同的事件处理器和Redis服务器中的其他类似方式接收单线程这是3358www.Sina.com/。
请注意，“文件事件处理器”(file event handler )主要包括四个部分。
多个socket (客户端连接) IO复用器)支持多个客户端连接的密钥)文件事件调度器)事件处理器)响应处理器，命令为什么不使用多线程？ 虽然Redis说是单线程模型，但实际上是高性能的网络通信模型
但是，在Redis 4.0中添加的多线程主要是保持了 Redis 内部单线程设计的简单性，这些命令将导致使用非主处理线程进行“异步处理”。
大体上，Redis 在 4.0 之后的版本中就已经加入了对多线程的支持。
我认为主要的理由有以下三个：
单线程编程容易，维护容易； Redis的性能瓶颈不在于CPU，而主要在于内存和网络； 多线程存在死锁、线程上下文切换等问题，也会影响性能。针对一些大键值对的删除操作的命令
在Redis6.0中引入多线程主要是为了提高网络I/o的读写性能，这是Redis的性能瓶颈之一。 Redis的瓶颈主要局限于内存和网络。
Redis6.0引入了多线程，但Redis的多线程仅用于读/写网络数据等耗时的操作，命令的执行按单线程顺序执行。 因此，也不用担心线程安全。