Reactor模式-IO模式

大家可能都了解很多种设计模式，但是对于我们常用的组件的设计模式了解比较少，甚至有很多人不知道组件为什么还有设计模式，比如常见的Ng和Redis都采用了Reactor模式，只有了解了这种模式，你才会发现NB的服务它的精华所在，你了解的越多，你口袋里的钱越多。

1. Reactor 模式

在传统的应用服务端设计当中，基本都是采用每个连接每个线程处理模式，这样请求少了都好说，可是一旦请求上来了，比如超过1w的request到达服务端，那么就会消耗1w个thread去处理请求，处理结束之后就会销毁这些线程，但是后续还有高并发请求到来，继续创建线程，而这无疑会加速耗尽服务器资源的速度，使得服务没办法处理后续的请求。

后来随着服务架构的发展和升级，就用线程池去做这个事情，每当有请求到来，立马从线程池获取线程去处理请求，直到线程池没有一个线程可用。为什么有线程池的设计呢？因为第一：线程池可以规避线程频繁的创建和销毁；第二：线程池有上限，比如1024，你最多只能处理这么多，这样可以防止无限开辟线程而导致服务资源耗尽挂掉。

但这毕竟还是有瓶颈的，因为线程池能够处理的并发有限，如何保证能用有限的资源去处理更多的请求呢？

这里就引入了Reactor模式，我们用餐厅顾客服务员举例,让大家了解下上面说的整个流程。

餐厅Reactor模式

我们用“餐厅”类比的话，就像下图：

对于每个新来的顾客，前台都需要找到一个服务员和厨师来服务这个顾客。

1. 服务员给出菜单，并等待点菜
2. 顾客查看菜单，并点菜
3. 服务员把菜单交给厨师，厨师照着做菜
4. 厨师做好菜后端到餐桌上

这就是传统的多线程服务器。每个顾客都有自己的服务团队（线程），在人少的情况下是可以良好的运作的。现在餐厅的口碑好，顾客人数不断增加，这时服务员就有点处理不过来了。

这时老板发现，每个服务员在服务完客人后，都要去休息一下，因此老板就说，“你们都别休息了，在旁边待命”。这样可能 10 个服务员也来得及服务 20 个顾客了。这也是“线程池”的方式，通过重用线程来减少线程的创建和销毁时间，从而提高性能。

但是客人又进一步增加了，仅仅靠剥削服务员的休息时间也没有办法服务这么多客人。老板仔细观察，发现其实服务员并不是一直在干活的，大部分时间他们只是站在餐桌旁边等客人点菜。

于是老板就对服务员说，客人点菜的时候你们就别傻站着了，先去服务其它客人，有客人点好的时候喊你们再过去。对应于下图：

最后，老板发现根本不需要那么多的服务员，于是裁了一波员，最终甚至可以只有一个服务员。

这就是 Reactor 模式的核心思想：减少等待。当遇到需要等待 IO 时，先释放资源，而在 IO 完成时，再通过事件驱动 (event driven) 的方式，继续接下来的处理。从整体上减少了资源的消耗。

强烈推荐大家看这篇文章，强烈推荐，强烈推荐 https://www.cnblogs.com/xiaolincoding/p/14706824.html

其次看下这篇文章 https://www.s0nnet.com/archives/deep-understanding-of-reactor-design-patterns