Reactor模式

对象行为类的设计模式,对同步事件分拣和派发。别名Dispatcher(分发器)

Reactor模式是处理并发I/O比较常见的一种模式,用于同步I/O,中心思想是将所有要处理的I/O事件注册到一个中心I/O多路复用器上,同时主线程阻塞在多路复用器上;一旦有I/O事件到来或是准备就绪(区别在于多路复用器是边沿触发还是水平触发),多路复用器返回并将相应I/O事件分发到对应的处理器中。

Reactor的事件处理机制

普通函数调用的机制:程序调用某函数->函数执行,程序等待->函数将结果和控制权返回给程序->程序继续处理。而所谓事件驱动,简单地说就是你点什么按钮(即产生什么事件),电脑执行什么操作(即调用什么函数)。

事件驱动模型

Reactor释义“反应堆”,是一种事件驱动机制。和普通函数调用的不同之处在于:应用程序不是主动的调用某个API完成处理,而是恰恰相反,Reactor逆置了事件处理流程,应用程序需要提供相应的接口并注册到Reactor上,如果相应的时间发生,Reactor将主动调用应用程序注册的接口,这些接口又称为“回调函数”。使用Libevent也是向Libevent框架注册相应的事件和回调函数;当这些时间发声时,Libevent会调用这些回调函数处理相应的事件(I/O读写、定时和信号)。

Reactor模式与Observer模式在某些方面极为相似:当一个主体发生改变时,所有依属体都得到通知。不过,观察者模式与单个事件源关联,而反应器模式则与多个事件源关联 。

Reactor模式的优点

Reactor模式是编写高性能网络服务器的必备技术之一,它具有如下的优点:

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

Reactor模式框架

使用Reactor模型,必备的几个组件事件源、Reactor框架、多路复用机制和事件处理程序

Reactor模型的整体框架

Reactor模型UML

Handle事件源

Handle代表操作系统管理的资源,包括:网络链接,打开的文件,计时器,同步对象等等。Linux上是文件描述符,Windows上就是Socket或者Handle了,这里统一称为“句柄集”;程序在指定的句柄上注册关心的事件,比如I/O事件。

event demultiplexer——事件多路分发机制

由操作系统提供的I/O多路复用机制,比如select和epoll。程序首先将其关心的句柄(事件源)及其事件注册到event demultiplexer上;

当有事件到达时,event demultiplexer会发出通知“在已经注册的句柄集中,一个或多个句柄的事件已经就绪”;程序收到通知后,就可以在非阻塞的情况下对事件进行处理了。 对应到libevent中,依然是select、poll、epoll等,但是libevent使用结构体eventop进行了封装,以统一的接口来支持这些I/O多路复用机制,达到了对外隐藏底层系统机制的目的。

事件分离器,由操作系统提供,在linux上一般是select, poll, epoll等系统调用,在一个Handle集合上等待事件的发生。接受client连接,建立对应client的事件处理器(Event Handler),并向事件分发器(Reactor)注册此事件处理器.

Reactor——反应器

Reactor,是事件管理的接口,内部使用event demultiplexer注册、注销事件;并运行事件循环,当有事件进入“就绪”状态时,调用注册事件的回调函数处理事件。

提供接口:注册,删除和派发Event Handler。Event Demultiplexer等待事件的发生,当检测到新的事件,就把事件交给Initiation Dispatcher,它去回调Event Handler。

对应到libevent中,就是event_base结构体。一个典型的Reactor声明方式

?


1

2

3

4

5

6

7

8

class Reactor

{

public:

int register_handler(Event_Handler *pHandler, int event);

int remove_handler(Event_Handler *pHandler, int event);

void handle_events(timeval *ptv);

// ...

};

Event Handler——事件处理程序

事件处理程序提供了一组接口,每个接口对应了一种类型的事件,供Reactor在相应的事件发生时调用,执行相应的事件处理。通常它会绑定一个有效的句柄。

事件处理器,负责处理特定事件的处理函数。一般在基本的Handler基础上还会有更进一步的层次划分,用来抽象诸如decode,process和encoder这些过程。比如对Web Server而言,decode通常是HTTP请求的解析,process的过程会进一步涉及到Listner和Servlet的调用。为了简化设计,Event Handler通常被设计成状态机,按GoF的state pattern来实现。对应到libevent中,就是event结构体。下面是两种典型的Event Handler类声明方式,二者互有优缺点。

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

class Event_Handler

{

public:

virtual void handle_read() = 0;

virtual void handle_write() = 0;

virtual void handle_timeout() = 0;

virtual void handle_close() = 0;

virtual HANDLE get_handle() = 0;

// ...

};

class Event_Handler

{

public:

// events maybe read/write/timeout/close .etc

virtual void handle_events(int events) = 0;

virtual HANDLE get_handle() = 0;

// ...

};

Concrete Event Handler

继承上面的类,实现钩子方法。应用把Concrete Event Handler注册到Reactor,等待被处理的事件。当事件发生,这些方法被回调。

应用场景举例

场景:长途客车在路途上,有人上车有人下车,但是乘客总是希望能够在客车上得到休息。

传统做法:每隔一段时间(或每一个站),司机或售票员对每一个乘客询问是否下车。

Reactor做法:汽车是乘客访问的主体(Reactor),乘客上车后,到售票员(acceptor)处登记,之后乘客便可以休息睡觉去了,当到达乘客所要到达的目的地后,售票员将其唤醒即可。

时间: 2024-10-20 04:50:01

Reactor模式的相关文章

NIO Reactor模式

Reactor模式和NIO——转: 本文可看成是对Doug Lea Scalable IO in Java一文的翻译. 当前分布式计算 Web Services盛行天下,这些网络服务的底层都离不开对socket的操作. 他们都有一个共同的结构:1. Read request2. Decode request3. Process service4. Encode reply5. Send reply 经典的网络服务的设计如下图,在每个线程中完成对数据的处理: 但这种模式在用户负载增加时,性能将下降

【转】Netty那点事(四)Netty与Reactor模式

[原文]https://github.com/code4craft/netty-learning/blob/master/posts/ch4-reactor.md 一:Netty.NIO.多线程? 时隔很久终于又更新了!之前一直迟迟未动也是因为积累不够,后面比较难下手.过年期间@李林锋hw发布了一个Netty5.0架构剖析和源码解读 http://vdisk.weibo.com/s/C9LV9iVqH13rW/1391437855,看完也是收获不少.前面的文章我们分析了Netty的结构,这次咱们

对于观察者模式,Reactor模式,Proactor模式的一点理解

最近就服务器程序IO效率这一块了解一下设计模式中的Reacotr模式和proactor模式,感觉跟观察者模式有些类似的地方,网上也看了一些其他人对三者之间区别的理解,都讲得很仔细,在此根据自己的理解做一点简单的记录和总结,如果理解不对的地方,以后再慢慢深入和更新. 观察者模式: 也可以称为为 发布-订阅 模式,主要适用于多个对象依赖某一个对象的状态并,当某对象状态发生改变时,要通知其他依赖对象做出更新.是一种1对多的关系.当然,如果依赖的对象只有一个时也是一种特殊的一对一关系.通常,观察者模式适

高性能IO设计中的Reactor模式与Proactor模式

在高性能的IO设计中,有两个比较著名的模式Reactor和Proactor模式,其中Reactor模式用于同步I/O,而Proactor运用于异步I/O操作.在比较这两个模式之前,我们首先要搞明白几个概念.什么是阻塞和非阻塞?什么是同步和异步?同步和异步是针对应用程序和内核的交互而言的,同步指的是用户进程触发IO操作并等待或者轮询的去查看IO操作是否就绪,而异步是指用户进程触发IO操作以后便开始做自己的事情,而当IO操作已经完成的时候会得到IO完成的通知(异步的特点就是通知).而阻塞和非阻塞是针

Nio学习3——基础模型:Reactor模式和多路复用

Reactor模式和NIO 本文可看成是对Doug Lea Scalable IO in Java一文的翻译. 当前分布式计算 Web Services盛行天下,这些网络服务的底层都离不开对socket的操作.他们都有一个共同的结构: 1. Read request 2. Decode request 3. Process service 4. Encode reply 5. Send reply 经典的网络服务的设计如下图,在每个线程中完成对数据的处理: 但这种模式在用户负载增加时,性能将下降

Reactor 模式的简单实现

Reactor 模式简单实现 在网上有部分文章在描述Netty时,会提到Reactor.这个Reactor到底是什么呢?为了搞清楚Reactor到底是什么鬼,我写了一个简单的Demo,来帮助大家理解他. 网上是这么描述Reactor的: The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients. Each

libevent之Reactor模式

通过前边的一篇博文轻量级网络库libevent初探,我们知道libevent实际上是封装了不同操作系统下的/dev/poll.kqueue.event ports.select.poll和epoll事件机制,从而给我们提供一个统一的接口. libevent采用了Reactor I/O 设计模式,而Reactor是基于同步I/O机制的,所以libevent实际是一个基于同步I/O机制的库. 对于I/O设计模式,与Reactor相对应的还有Proactor.下边我们先来看下这两者的不同之处. Rea

I/O并发模式—Reactor模式

好莱坞原则是"不要打电话给我们,我们会打电话通知你",其实Reactor模式就是如此,你不必一直询问某个事件是否发生了,当事件发生时,会主动通知你.一般用于服务器并发的处理请求.先来看几个Reactor模式中的参与者. 事件处理器:对应一个描述符,实现了应用程序在该描述符上提供的服务. Reactor管理器:是事件处理器的调度核心.用于控制事件调度,以及应用程序注册.删除事件处理器和相关的描述符.Reactor管理器使用同步事件分离器来等待事件的发生. 同步事件分离器(demultip

高性能IO之Reactor模式

讲到高性能IO绕不开Reactor模式,它是大多数IO相关组件如Netty.Redis在使用的IO模式,为什么需要这种模式,它是如何设计来解决高性能并发的呢? 最最原始的网络编程思路就是服务器用一个while循环,不断监听端口是否有新的套接字连接,如果有,那么就调用一个处理函数处理,类似:while(true){ socket = accept(); handle(socket) } 这种方法的最大问题是无法并发,效率太低,如果当前的请求没有处理完,那么后面的请求只能被阻塞,服务器的吞吐量太低.

muduo网络库学习笔记(9):Reactor模式的关键结构

Reactor模式简介 Reactor的意思是"反应堆",是一种事件驱动机制.它和普通函数调用的不同之处在于:应用程序不是主动的调用某个API完成处理,而是恰恰相反,Reactor逆置了事件处理流程,应用程序需要提供相应的接口并注册到Reactor上,如果相应的时间发生,Reactor将主动调用应用程序注册的接口,这些接口又称为"回调函数". moduo库Reactor模式的实现 muduo中Reactor的关键结构包括:EventLoop.Poller和Chann