reactor模式---事件触发模型

Posted soqu36

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了reactor模式---事件触发模型相关的知识,希望对你有一定的参考价值。

Reactor这个词译成汉语还真没有什么合适的,很多地方叫反应器模式,但更多好像就直接叫reactor模式了,其实我觉着叫应答者模式更好理解一些。通过了解,这个模式更像一个侍卫,一直在等待你的召唤。

1.reactor的形象比喻入门

 

并发系统常使用reactor模式,代替常用的多线程的处理方式,节省系统的资源,提高系统的吞吐量。

 

先用比较直观的方式来介绍一下这种方式的优点,通过和常用的多线程方式比较一下,可能更好理解。

以一个餐饮为例,每一个人来就餐就是一个事件,他会先看一下菜单,然后点餐。就像一个网站会有很多的请求,要求服务器做一些事情。处理这些就餐事件的就需要我们的服务人员了。

 

在多线程处理的方式会是这样的:

一个人来就餐,一个服务员去服务,然后客人会看菜单,点菜。 服务员将菜单给后厨。

二个人来就餐,二个服务员去服务……

五个人来就餐,五个服务员去服务……

 

这个就是多线程的处理方式,一个事件到来,就会有一个线程服务。很显然这种方式在人少的情况下会有很好的用户体验,每个客人都感觉自己是VIP,专人服务的。如果餐厅一直这样同一时间最多来5个客人,这家餐厅是可以很好的服务下去的。

 

来了一个好消息,因为这家店的服务好,吃饭的人多了起来。同一时间会来10个客人,老板很开心,但是只有5个服务员,这样就不能一对一服务了,有些客人就要没有人管了。老板就又请了5个服务员,现在好了,又能每个人都受VIP待遇了。

 

越来越多的人对这家餐厅满意,客源又多了,同时来吃饭的人到了20人,老板高兴不起来了,再请服务员吧,占地方不说,还要开工钱,再请人就攒不到钱了。怎么办呢?老板想了想,10个服务员对付20个客人也是能对付过来的,服务员勤快点就好了,伺候完一个客人马上伺候另外一个,还是来得及的。综合考虑了一下,老板决定就使用10个服务人员的线程池啦~~~

 

但是这样有一个比较严重的缺点就是,如果正在接受服务员服务的客人点菜很慢,其他的客人可能就要等好长时间了。有些火爆脾气的客人可能就等不了走人了。

 

Reactor如何处理这个问题呢:

老板后来发现,客人点菜比较慢,大部服务员都在等着客人点菜,其实干的活不是太多。老板能当老板当然有点不一样的地方,终于发现了一个新的方法,那就是:当客人点菜的时候,服务员就可以去招呼其他客人了,等客人点好了菜,直接招呼一声“服务员”,马上就有个服务员过去服务。嘿嘿,然后在老板有了这个新的方法之后,就进行了一次裁员,只留了一个服务员!这就是用单个线程来做多线程的事。

 

实际的餐馆都是用的Reactor模式在服务。一些设计的模型其实都是从生活中来的。

 

Reactor模式主要是提高系统的吞吐量,在有限的资源下处理更多的事情。

 

在单核的机上,多线程并不能提高系统的性能,除非在有一些阻塞的情况发生。否则线程切换的开销会使处理的速度变慢。就像你一个人做两件事情,1、削一个苹果。2、切一个西瓜。那你可以一件一件的做,我想你也会一件一件的做。如果这个时候你使用多线程,一会儿削苹果,一会切西瓜,可以相像究竟是哪个速度快。这也就是说为什么在单核机上多线程来处理可能会更慢。

 

但当有阻碍操作发生时,多线程的优势才会显示出来,现在你有另外两件事情去做,1、削一个苹果。2、烧一壶开水。我想没有人会去做完一件再做另一件,你肯定会一边烧水,一边就把苹果削了。

 

首先来回想一下普通函数调用的机制:程序调用某函数?函数执行,程序等待?函数将结果和控制权返回给程序?程序继续处理。
Reactor释义“反应堆”,是一种事件驱动机制。和普通函数调用的不同之处在于:应用程序不是主动的调用某个API完成处理,而是恰恰相反,Reactor逆置了事件处理流程,应用程序需要提供相应的接口并注册到Reactor上,如果相应的时间发生,Reactor将主动调用应用程序注册的接口,这些接口又称为“回调函数”。使用Libevent也是想Libevent框架注册相应的事件和回调函数;当这些时间发声时,Libevent会调用这些回调函数处理相应的事件(I/O读写、定时和信号)。
    用“好莱坞原则”来形容Reactor再合适不过了:不要打电话给我们,我们会打电话通知你。
    举个例子:你去应聘某xx公司,面试结束后。
“普通函数调用机制”公司HR比较懒,不会记你的联系方式,那怎么办呢,你只能面试完后自己打电话去问结果;有没有被录取啊,还是被据了;

“Reactor”公司HR就记下了你的联系方式,结果出来后会主动打电话通知你:有没有被录取啊,还是被据了;你不用自己打电话去问结果,事实上也不能,你没有HR的留联系方式。

 

 

2 Reactor模式的优点
Reactor模式是编写高性能网络服务器的必备技术之一,它具有如下的优点:
    1)响应快,不必为单个同步时间所阻塞,虽然Reactor本身依然是同步的;
    2)编程相对简单,可以最大程度的避免复杂的多线程及同步问题,并且避免了多线程/进程的切换开销;
    3)可扩展性,可以方便的通过增加Reactor实例个数来充分利用CPU资源;
    4)可复用性,reactor框架本身与具体事件处理逻辑无关,具有很高的复用性;

3 Reactor模式框架
    使用Reactor模型,必备的几个组件:事件源、Reactor框架、多路复用机制和事件处理程序,先来看看Reactor模型的整体框架,接下来再对每个组件做逐一说明。
 

 

1) 事件源
Linux上是文件描述符,Windows上就是Socket或者Handle了,这里统一称为“句柄集”;程序在指定的句柄上注册关心的事件,比如I/O事件。

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

3) Reactor——反应器
    Reactor,是事件管理的接口,内部使用event demultiplexer注册、注销事件;并运行事件循环,当有事件进入“就绪”状态时,调用注册事件的回调函数处理事件。
对应到libevent中,就是event_base结构体。
一个典型的Reactor声明方式

 

[cpp] view plain copy
 
  1. class Reactor       
  2. {       
  3. public:       
  4.     int register_handler(Event_Handler *pHandler, int event);       
  5.     int remove_handler(Event_Handler *pHandler, int event);       
  6.     void handle_events(timeval *ptv);       
  7.     // ...       
  8. };      
  9. class Reactor    
  10. {    
  11. public:    
  12.     int register_handler(Event_Handler *pHandler, int event);    
  13.     int remove_handler(Event_Handler *pHandler, int event);    
  14.     void handle_events(timeval *ptv);    
  15.     // ...    
  16. };    


4) Event Handler——事件处理程序
    事件处理程序提供了一组接口,每个接口对应了一种类型的事件,供Reactor在相应的事件发生时调用,执行相应的事件处理。通常它会绑定一个有效的句柄。
对应到libevent中,就是event结构体。
下面是两种典型的Event Handler类声明方式,二者互有优缺点。

 

 

[cpp] view plain copy
 
  1. class Event_Handler       
  2. {       
  3. public:       
  4.     virtual void handle_read() = 0;       
  5.     virtual void handle_write() = 0;       
  6.     virtual void handle_timeout() = 0;       
  7.     virtual void handle_close() = 0;       
  8.     virtual HANDLE get_handle() = 0;       
  9.     // ...       
  10. };       
  11. class Event_Handler       
  12. {       
  13. public:       
  14.     // events maybe read/write/timeout/close .etc       
  15.     virtual void handle_events(int events) = 0;       
  16.     virtual HANDLE get_handle() = 0;       
  17.     // ...       
  18. };      
  19. class Event_Handler    
  20. {    
  21. public:    
  22.     virtual void handle_read() = 0;    
  23.     virtual void handle_write() = 0;    
  24.     virtual void handle_timeout() = 0;    
  25.     virtual void handle_close() = 0;    
  26.     virtual HANDLE get_handle() = 0;    
  27.     // ...    
  28. };    
  29. class Event_Handler    
  30. {    
  31. public:    
  32.     // events maybe read/write/timeout/close .etc    
  33.     virtual void handle_events(int events) = 0;    
  34.     virtual HANDLE get_handle() = 0;    
  35.     // ...    
  36. };    

 

 

4 Reactor事件处理流程
前面说过Reactor将事件流“逆置”了,那么使用Reactor模式后,事件控制流是什么样子呢?
可以参见下面的序列图。
 

 

关于读写事件响应:
1、读响应:
在socket建链以后,就在其上add读响应句柄,一旦socket缓冲区上有数据可读,就会自动触发响应的读方法进行处理;
2、写响应:
设置了一个bReadable的标志位,每次需要发送数据时,将此标志位置为true,这样在onTimeOut响应函数中,一旦发现bReadable为true,则对socket绑定上写响应句柄;
在写响应函数中,对要发送数据进行发送之前,socket要去除写响应句柄;
也就是说:每次需要发送数据时,就绑定一次写响应句柄,发送时,就去除此句柄;
因为写响应句柄,在socket发送缓冲区为空的时候,会一直触发调用写响应函数。因此需要再onTimeout响应中根据发送需要,临时绑定/去绑定写响应句柄。

以上是关于reactor模式---事件触发模型的主要内容,如果未能解决你的问题,请参考以下文章

Proactor和Reactor模型

网络IO模型Reactor 模式

网络IO模型Reactor 模式

一个 Reactor 模型的实现

一个 Reactor 模型的实现

Reactor 线程模型