1 源于生活的设计模式

我们在生活中有一个非常不愿意去但是却又不得不去的地方就是医院，我们去医院看病需要经历一下流程：

第1步：挂号

第2步：等待叫号

第3步：找对应的医生讲述病情，医生根据症状开化验单

第4步：我们带上化验单使用设备化验

第5步：等待化验结果出来之后我们要拿上化验单再去找医生

第6步：医生根据化验结果对症下药。

每个人都不愿意去医院，因为我们感觉去医院非常麻烦，经历上面的流程一天的时间就过去了，在这所有的流程中等待叫号和等化验结果时间是最长的，有的化验单可能好几天才能出来，化验单出来之后也需要排队让医生看化验结果。

作为病人希望到医院之后有一对一的服务，到医院之后有对应的医生给我们全程跟踪看病。

但是如果我们作为医院的管理者会怎么思考这个问题呢，医院的医生和设备数量是有限的，但是每天的病人却很多，基本上是医生的几十倍，如何使用有限的医生和设备资源解决更多病人的问题呢。

假设医院有10个医生，20台设备，医生执行第3步需要10分钟，执行第6步需要10分钟，设备执行第4步需要20分钟，第5步需要20分钟。如果医生接到病人之后给病人开化验单，然后等着病人出结果之后给病人开药，再送走，就是从第3步到第6步一直有医生跟着，这样会非常耗时，一个医生看一个病人需要花费 10+20+20+10=60分钟 的时间，一天8小时只能给8病人看病，一个医院每天只能接待108=80个病人。但是如果医生开完化验单之后病人去化验这段时间给下个挂过号的病人看病，即执行完第3步之后，医生可以继续叫号执行第2步，病人拿到化验单之后即执行完第5步之后可以再去找医生执行第6步，这样就把资源充分利用起来了，一个医生看一个病人只需要精力第3步和第6不，花费10+10=20分钟，每天能够给860/20=24个人看病，整个医院每天能接待10*24=240个病人。这就是Reactor设计模式最核心的思想，解决了一对多的问题，大大提升了资源的使用率。

【文章福利】需要C/C++ Linux服务器架构师学习资料加群1106747042（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等）

image

2 Reactor设计模式实现

NIO是使用reactor设计模式非常经典的案例，传统的IO客户端过来一个连接，服务端就需要专门一个线程来处理，每一个线程会将一次交互操作全部处理完成，包括读取和返回，表面上似乎连接不在线程里面，但是如果线程不够，新连接将无法得到处理。所以一个线程就肩负了连接、读取、写入的责任。

这种处理模式海量并发的情况下即使引入线程池也不能满足需要，这个时候考虑将一次完整的请求切分为几个小的任务，就像医院把医生问诊和仪器检查分开一样，每个小任务都是非阻塞的，对于读写操作使用NIO对其进行读写。所以我们把一次连接操作拆分为多个任务，每个任务都是非阻塞的，这样就大大提升了效率，但是这样做线程池中的线程数量业也会大大增长，但是线程更加简单且任务单一，有点像我们微服务的思想。

Reactor从线程池和Reactor的选择上可以细分为：Reactor单线程模型，Reactor多线程模型，Reactor主从模型。

2.1 Reactor单线程模型

单线程模型是针对客户端请求使用一个专门的线程去处理，这个线程循环监听是否有客户端的请求抵达，一旦收到客户端请求，将其分发给相应处理线程进行处理。这种模式采用了基于事件驱动的设计，当有事件触发时才会调用处理器进行数据处理。使用Reactor模式可以对线程的数量进行控制，可以使用一个线程去处理大量的事件。

image

2.2 Reactor多线程模型

使用一个线程可以支持所有的IO处理，但是瓶颈也是显而易见的，如果客户端多次请求时在业务线程中处理较慢，后续的客户端会被积压，导致响应变慢，所以需要引入Reactor多线程模型。

可以将工作线程引入线程池，将处理器的执行放入线程池，并使用多线程处理业务逻辑。

image

2.3 Reactor主从模型

对于多个CPU的机器，为了充分利用系统资源会将Reactor拆分为两部分。

1）Main Reactor 负责监听连接，将监听到的连接交给Sub Reactor处理，主Reactor用于响应连接请求。

2）Sub Reactor 处理连接，从Reactor用于处理IO操作请求。

image

3 架构模型

image

Handle：操作系统的句柄，可以是打开的文件、一个Socket连接、Timer定时器等。

Synchronous Event Demultiplexer ：同步（多路）事件分离器，阻塞等待Handles中的事件发生。

Initiation Dispatcher ：初始事件分发器，提供了注册、删除、转发Event Handler的方法

Event Handler ：事件处理器的接口

Concrete Event Handler ：事件处理器的实际实现，而且绑定了一个Handle。因为在实际情况中，我们往往不止一种事件处理器，因此这里将事件处理器接口和实现分开，与C++、Java这些高级语言中的多态类似。

————————————————