本篇文章给大家分享的是有关Reactor模型与Proactor模型的区别是什么，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

官渡ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18982081108（备注：SSL证书合作）期待与您的合作！

Reactor模型

它是同步非阻塞模型。也称为Dispatcher模型。想想如果每一个连接过来我们都得建一个线程来处理这个连接，那连接一多线程不得爆满，那可能有人说上线程池，对线程池肯定是要上的。但这只能解决线程数的问题，但还有一个问题就是资源利用率的问题，当连接没断开的时候，当这个连接暂时没请求的时候你的线程是不是得阻塞着等着请求呀，那线程等于还是被人占用了，别的连接有请求的时候也用不到这个线程，资源的浪费啊，性能低啊。

那如何解决这个问题呢？

当然是等连接有请求的时候线程再上去处理。那这个事情得找个“人”来做，咱们业务线程就处理业务，就是得有个“人”来管理所有的连接，他发现哪个连接有请求了就分配业务线程来处理。

这就叫Reactor模型。上面说的那个"人"我们称为reactor,中文翻译时反应堆的意思，也就是他就是那个监视的人，如果有情况来了他就有所反应，分发任务给业务线程处理。

可以有单Reactor单线程，单Reactor多线程，多Reactor多线程

单Reactor单线程

select会一直监听着事件，事件来了之后给dispatch分发，如果建立请求的事件则分配的acceptor,由acceptor创建一个handler来处理后续的业务，如果不是建立请求的事件则分配个之前对应的handler来处理后续业务

这个情况的优点就是简单。。。没有多线程共享资源争抢导致的问题。缺点就是就单线程，浪费了多CPU，并且同一时刻只有一个handler能处理，其他的得等着。

听起来好像没啥用啊这样，是的绝大部分场景不适合，但是redis就是这样用的。因为它处理业务够快。所以这种适合在业务处理极快的情况下使用。

单Reactor多线程

当业务处理不快就上多线程咯。

这个模式和上面的区别就在于具体业务实现不由handler处理的，handler只负责read数据，将数据给业务线程，然后业务线程处理完毕之后返回结果给handler，由handler send给客户端。

这个模式的优点就是可以充分利用CPU,适合业务处理不快的情况。缺点就是多线程之间共享资源的争抢产生的问题，并且只有一个Reactor来监听并响应，当请求量太大时，一个Reactor可能会成为性能瓶颈。

多Reactor多线程

所以多Reactor多线程就来啦。

mainReactor主要用来接受连接，由连接来就给acceptor,acceptor将新的连接分配个某个subReactor，然后这个subReactor将其加入自己的监听列表，并创建一个handler来处理这个连接。之后就都由这个subReactor来select监听来响应这个连接的请求，然后dispatch给对应的handler来read,业务处理，send。mainReactor就不管啦。

所以这种方案就等于主Reactor分流了，只有新的连接由主Reactor接受，老的连接都分给了subReactor来响应。

Proactor模型

它是异步非阻塞模型。中文翻译为前摄器。。不知道啥玩意,可以称之为主动器。也就是我们不必等待I/O数据准备好也就是内核缓存已经读数据到用户空间。这一切都有内核来帮我们搞定，数据准备好了之后就通知Proactor，然后Proactor就调用相应的Handler进行业务处理。相对于Reactor省去了遍历事件通知队列selector 的代价。

由initiator创建handler和proactor并通过Asynchronous Operation Processor注册到内核，然后Asynchronous Operation Processor完成I/O会通知proactor，proactor再调用对应的handler处理业务。

所以理论上Proactor的效率比Reactor高，但是linux并没有真正的实现Proactor模型，而是epoll模拟出Proactor模型。

以上就是Reactor模型与Proactor模型的区别是什么，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。

分享标题：Reactor模型与Proactor模型的区别是什么
文章来源：http://scpingwu.com/article/jcidjg.html