Reactor 模式的基本设计思想是基于I/O复用模型

Reactor 模式的基本设计思想是基于I/O复用模型来实现的。
这里说下I/O复用模型。和传统IO多线程阻塞不同，I/O复用模型中多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象等待。当某个连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。
什么意思呢？餐厅老板也发现了顾客点餐慢的问题，于是他采用了一种大胆的方式，只留了一个服务员。当客人点餐的时候，这个服务员就去招待别的客人，客人点好餐后直接喊服务员来进行服务。这里的顾客和服务员可以分别看作多个连接和一个线程。服务员阻塞在一个顾客那里，当有别的顾客点好餐后，她就立刻去服务其他的顾客。
了解了 reactor 的设计思想后，再来看下单 reactor 单线程的实现方案：

Reactor 通过 I/O复用程序监控客户端请求事件，收到事件后通过任务分派器进行分发。

针对建立连接请求事件，通过 Acceptor 处理，并建立对应的 handler 负责后续业务处理。
针对非连接事件，Reactor 会调用对应的 handler 完成 read->业务处理->write 处理流程，并将结果返回给客户端。
整个过程都在一个线程里完成。
单线程时代
Redis 是基于 Reactor 单线程模式来实现的。
IO多路复用程序接收到用户的请求后，全部推送到一个队列里，交给文件分派器。对于后续的操作，和在 reactor 单线程实现方案里看到的一样，整个过程都在一个线程里完成，因此 Redis 被称为是单线程的操作。

对于单线程的 Redis 来说，基于内存，且命令操作时间复杂度低，因此读写速率是非常快的。
多线程时代
Redis6 版本中引入了多线程。上边已经提到过 Redis 单线程处理有着很快的速度，那为什么还要引入多线程呢？单线程的瓶颈在什么地方？
先来看第二个问题，在 Redis 中，单线程的性能瓶颈主要在网络IO操作上。也就是在读写网络 read/write 系统调用执行期间会占用大部分 CPU 时间。如果要对一些大的键值对进行删除操作的话，在短时间内是删不完的，那么对于单线程来说就会阻塞后边的操作。
回想下上边讲得 Reactor 模式中单线程的处理方式。针对非连接事件，Reactor 会调用对应的 handler 完成 read->业务处理->write处理流程，也就是说这一步会造成性能上的瓶颈。