reactor模式

最新推荐文章于 2022-06-04 21:36:27 发布

后台服务器开发

最新推荐文章于 2022-06-04 21:36:27 发布

阅读量212

点赞数

分类专栏： libevent

本文链接：https://blog.csdn.net/Travelerwz/article/details/102636052

版权

libevent 专栏收录该内容

8 篇文章 2 订阅

订阅专栏

reactor 模式

一、reactor定义

来自Wikipedia上的定义：The reactor design pattern is an event handling pattern for handling service requests delivered concurrently by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to associated request handlers.”。

通过这个叙述，我们知道reactor基于事件驱动的，它有一个或多个并发输入源，有一个Service Handler，和有多个Request Handlers；如图1所示：

在这里插入图片描述

通过图片可知，reactor模式是将一个请求通过Service Handler分发给Request Handler；

用白话可以这么说，输入的请求（Event）也就是一个公司不同的产品经理，Service Handler相当于是技术老大，Request Handlers相当于程序员啦！！！不同的产品提出了不同的需求到技术老大这，老大比较实诚，来着不惧，直接将需求分派给不用的程序员去完成，原来受伤的还是程序员呀~~~

这就是reactor模式；

二、reactor实现

首先，我们看一个经常见到的类图：

在这里插入图片描述
从类图上我们可以看到，实现一个reactor还是比较麻烦的，主要由以下几部分组成：

reactor：反应堆；主要功能：注册事件、移除事件、分发事件
EventHandler:事件，事件处理
SynchronousEventDemultiplexer:采集事件
ConcreteEventHandler:请求事件

这里有一个比较简单易懂的reactor实现，可以研究一下：https://github.com/song0071000/Reactor_Implemention

大概粗略的说一下这个案例：

这个案例分为服务端和客户端两个，编译后可以运行：

服务端：服务端和普通linux上的服务程序是相同的，有客户端连接时，服务端会将标识符注册，并且不断检测fd的可读可写性，每2s向客户端发送时间
客户端：客户端实现也是相同的，也是通过注册fd，然后并且不断检测fd的可读可写性，向服务端发送消息

reactor是一种很有意义的模式，对我们在工作中也是有很大的作用。

三、reactor的优缺点

优点

1）响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；
4）可复用性，reactor框架本身与具体事件处理逻辑无关，具有很高的复用性；

缺点

1）相比传统的简单模型，Reactor增加了一定的复杂性，因而有一定的门槛，并且不易于调试。
2）Reactor模式需要底层的Synchronous Event Demultiplexer支持，比如操作系统的select系统调用支持，如果要自己实现Synchronous Event Demultiplexer可能不会有那么高效。
3） Reactor模式在IO读写数据时还是在同一个线程中实现的，即使使用多个Reactor机制的情况下，那些共享一个Reactor的Channel如果出现一个长时间的数据读写，会影响这个Reactor中其他Channel的相应时间，比如在大文件传输时，IO操作就会影响其他Client的相应时间，因而对这种操作，则不合适使用reactor模式

推荐文章：https://blog.csdn.net/caiwenfeng_for_23/article/details/8458299

想了解学习更多C++后台服务器方面的知识，请关注：
微信公众号：C++后台服务器开发