共计 2141 个字符，预计需要花费 6 分钟才能阅读完成。
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 分钟，每天可能给 8 60/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 等）
2 Reactor 设计模式实现
NIO 是应用 reactor 设计模式十分经典的案例，传统的 IO 客户端过去一个连贯，服务端就须要专门一个线程来解决，每一个线程会将一次交互操作全副解决实现，包含读取和返回，外表上仿佛连贯不在线程外面，然而如果线程不够，新连贯将无奈失去解决。所以一个线程就肩负了连贯、读取、写入的责任。
这种解决模式海量并发的状况下即便引入线程池也不能满足需要，这个时候思考将一次残缺的申请切分为几个小的工作，就像医院把医生问诊和仪器查看离开一样，每个小工作都是非阻塞的，对于读写操作应用 NIO 对其进行读写。所以咱们把一次连贯操作拆分为多个工作，每个工作都是非阻塞的，这样就大大晋升了效率，然而这样做线程池中的线程数量业也会大大增长，然而线程更加简略且工作繁多，有点像咱们微服务的思维。
Reactor 从线程池和 Reactor 的抉择上能够细分为：Reactor 单线程模型，Reactor 多线程模型，Reactor 主从模型。
2.1 Reactor 单线程模型
单线程模型是针对客户端申请应用一个专门的线程去解决，这个线程循环监听是否有客户端的申请到达，一旦收到客户端申请，将其分发给相应解决线程进行解决。这种模式采纳了基于事件驱动的设计，当有事件触发时才会调用处理器进行数据处理。应用 Reactor 模式能够对线程的数量进行管制，能够应用一个线程去解决大量的事件。
2.2 Reactor 多线程模型
应用一个线程能够反对所有的 IO 解决，然而瓶颈也是不言而喻的，如果客户端屡次申请时在业务线程中解决较慢，后续的客户端会被积压，导致响应变慢，所以须要引入 Reactor 多线程模型。
能够将工作线程引入线程池，将处理器的执行放入线程池，并应用多线程解决业务逻辑。
2.3 Reactor 主从模型
对于多个 CPU 的机器，为了充分利用系统资源会将 Reactor 拆分为两局部。
1）Main Reactor 负责监听连贯，将监听到的连贯交给 Sub Reactor 解决，主 Reactor 用于响应连贯申请。
2）Sub Reactor 解决连贯，从 Reactor 用于解决 IO 操作申请。
3 架构模型
Handle：操作系统的句柄，能够是关上的文件、一个 Socket 连贯、Timer 定时器等。
Synchronous Event Demultiplexer：同步（多路）事件分离器，阻塞期待 Handles 中的事件产生。
Initiation Dispatcher：初始事件散发器，提供了注册、删除、转发 Event Handler 的办法
Event Handler：事件处理器的接口
Concrete Event Handler：事件处理器的理论实现，而且绑定了一个 Handle。因为在理论状况中，咱们往往不止一种事件处理器，因而这里将事件处理器接口和实现离开，与 C ++、Java 这些高级语言中的多态相似。
————————————————
