I/O复用,select和Reactor模式

I/O复用,select和Reactor模式,各自的概念其间的关系,以及最重要的,他们的优势在哪,与同类相比为什么能具有这样的优势。这就是写这篇文字最初的出发点。

I/O复用

I/O复用属于I/O模型中的一种:

1. 阻塞式I/O:

2. 非阻塞式I/O:

3. I/O复用模型

4. 信号驱动式I/O模型

5. 异步I/O模型

以上各个模型之间的比较如下:

select

select 是c语言中的函数,相对于诸如connect、accept、recv或recvfrom这样的阻塞程序来说,使用select就可以完成非阻塞(所谓非阻塞方式non-block,就是进程或线程执行此函数时不必非要等待事件的发生,一旦执行肯定返回,以返回值的不同来反映函数的执行情况,如果事件发生则与阻塞方式相同,若事件没有发生则返回一个代码来告知事件未发生,而进程或线程继续执行,所以效率较高)方式工作的程序,它能够监视我们需要监视的文件描述符的变化情况——读写或是异常。

监视(多个)文件描述符的变化情况就是select实现I/O复用的方式。任何一个可读、可写或异常都能唤醒select函数的当前进程继续工作,减少了进程阻塞的时间。

所以说,select的主要业务在于设置对一个或多个对象的监听,将所有的阻塞事件集中处理,一旦任一可用,即唤醒进程,多个本应在各自进程上执行的I/O被复用到一个进程中协调执行,达到I/O复用。

Reactor模式

意图

在事件驱动的应用中,将一个或多个客户的服务请求分离(demultiplex)和调度(dispatch)给应用程序。

问题

在分布式系统尤其是服务器这一类事件驱动应用中,虽然这些请求最终会被序列化地处理,但是必须时刻准备着处理多个同时到来的服务请求。在实际应用 中,这些请求总是通过一个事件(如CONNECTOR、READ、WRITE等)来表示的。在有序地处理这些服务请求之前,应用程序必须先分离和调度这些同时到达的事件。为了有效地解决这个问题,我们需要做到以下4方面:

  • 为了提高系统的可测量性和反应时间,应用程序不能长时间阻塞在某个事件源上而停止对其他事件的处理,这样会严重降低对客户端的响应度。
  • 为了提高吞吐量,任何没有必要的上下文切换、同步和CPU之间的数据移动都要避免。
  • 引进新的服务或改良已有的服务都要对既有的事件分离和调度机制带来尽可能小的影响。
  • 大量的应用程序代码需要隐藏在复杂的多线程和同步机制之后。

解决方法

在一个或多个事件源上等待事件的到来,例如,一个已经连接的Socket描述符就是一个事件源。将事件的分离和调度整合到处理它的服务中,而将分离和调度机制从应用程序对特定事件的处理中分离开,也就是说分离和调度机制与特定的应用程序无关。

具体来说,每个应用程序提供的每个服务都有一个独立的事件处理器与之对应。由事件处理器处理来自事件源的特定类型的事件。每个事件处理器都事先注册 到Reactor管理器中。Reactor管理器使用同步事件分离器在一个或多个事件源中等待事件的发生。当事件发生后,同步事件分离器通知 Reactor管理器,最后由Reactor管理器调度和该事件相关的事件处理器来完成请求的服务。

结构

在Reactor模式中,有5个关键的参与者。

  1. 描述符(handle):由操作系统提供,用于识别每一个事件,如Socket描述符、文件描述符等。在Linux中,它用一个整数来表示。事件可以来自外部,如来自客户端的连接请求、数据等。事件也可以来自内部,如定时器事件。
  2. 同步事件分离器(demultiplexer):是一个函数,用来等待一个或多个事件的发生。调用者会被阻塞,直到分离器分离的描述符集上有事件发生。Linux的select函数是一个经常被使用的分离器。
  3. 事件处理器接口(event handler):是由一个或多个模板函数组成的接口。这些模板函数描述了和应用程序相关的对某个事件的操作。
  4. 具体的事件处理器:是事件处理器接口的实现。它实现了应用程序提供的某个服务。每个具体的事件处理器总和一个描述符相关。它使用描述符来识别事件、识别应用程序提供的服务。
  5. Reactor 管理器(reactor):定义了一些接口,用于应用程序控制事件调度,以及应用程序注册、删除事件处理器和相关的描述符。它是事件处理器的调度核心。 Reactor管理器使用同步事件分离器来等待事件的发生。一旦事件发生,Reactor管理器先是分离每个事件,然后调度事件处理器,最后调用相关的模 板函数来处理这个事件。

    通过上述分析,我们注意到,是Reactor管理器而不是应用程序负责等待事件、分离事件和调度事件。实际上,Reactor管理器并没有被具体的 事件处理器调用,而是管理器调度具体的事件处理器,由事件处理器对发生的事件做出处理。这就是类似Hollywood原则的“反向控制”。应用程序要做的 仅仅是实现一个具体的事件处理器,然后把它注册到Reactor管理器中。接下来的工作由管理器来完成。这些参与者的相互关系如下图所示。

I/O复用,select和reactor

select是reactor设计模式中的一个组件,也可以说是最核心的组件,为整个模块提供注册事件和监听事件的功能,从另一个的角度来说就是事件的派发,他将可能引起的阻塞等待集中到自身这一个地方进行协调处理,可以实现在单个进程中高效的I/O复用。

如此一来,reactor模式就为服务器处理多个请求提供了一个新的思路——我们不一定非要依靠多个线程来处理,而且多线程之间的频繁切换所带来的系统开销也是非常巨大的。相比之下,表面上看起来多做了好多无谓工作的select操作在具体的应用中会带来更好的效果。而其具体优势可参考上文“Reactor模式”中的“问题”一栏。

时间: 2024-11-05 22:44:13

I/O复用,select和Reactor模式的相关文章

C++服务器设计(一):基于I/O复用的Reactor模式

I/O模型选择 在网络服务端编程中,一个常见的情景是服务器需要判断多个已连接套接字是否可读,如果某个套接字可读,则读取该套接字数据,并进行进一步处理. 在最常用的阻塞式I/O模型中,我们对每个连接套接字通过轮流read系统调用获取可读数据.如图3-1所示,read系统调用将会把该线程阻塞,直到数据报到达且被复制到应用进程的缓冲区中时才会返回. 图3-1 阻塞式I/O模型 在阻塞式I/O模型中,数据可读和读取数据这两个操作被合并在了一个系统调用中,对于单个套接字是否可读的判断,必须要等到实际数据接

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

Reactor模式

对象行为类的设计模式,对同步事件分拣和派发.别名Dispatcher(分发器) Reactor模式是处理并发I/O比较常见的一种模式,用于同步I/O,中心思想是将所有要处理的I/O事件注册到一个中心I/O多路复用器上,同时主线程阻塞在多路复用器上:一旦有I/O事件到来或是准备就绪(区别在于多路复用器是边沿触发还是水平触发),多路复用器返回并将相应I/O事件分发到对应的处理器中. Reactor的事件处理机制 普通函数调用的机制:程序调用某函数->函数执行,程序等待->函数将结果和控制权返回给程

IO复用(Reactor模式和Preactor模式)——用epoll来提高服务器并发能力

上篇线程/进程并发服务器中提到,提高服务器性能在IO层需要关注两个地方,一个是文件描述符处理,一个是线程调度. IO复用是什么?IO即Input/Output,在网络编程中,文件描述符就是一种IO操作. 为什么要IO复用? 1.网络编程中非常多函数是阻塞的,如connect,利用IO复用可以以非阻塞形式执行代码. 2.之前提到listen维护两个队列,完成握手的队列可能有多个就绪的描述符,IO复用可以批处理描述符. 3.有时候可能要同时处理TCP和UDP,同时监听多个端口,同时处理读写和连接等.

Reactor模式,或者叫反应器模式 - 为什么用多路io复用提供吞吐量

Reactor这个词译成汉语还真没有什么合适的,很多地方叫反应器模式,但更多好像就直接叫reactor模式了,其实我觉着叫应答者模式更好理解一些.通过了解,这个模式更像一个侍卫,一直在等待你的召唤,或者叫召唤兽. 并发系统常使用reactor模式,代替常用的多线程的处理方式,节省系统的资源,提高系统的吞吐量. 先用比较直观的方式来介绍一下这种方式的优点,通过和常用的多线程方式比较一下,可能更好理解. 以一个餐饮为例,每一个人来就餐就是一个事件,他会先看一下菜单,然后点餐.就像一个网站会有很多的请

高性能IO之Reactor模式

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

(转)reactor模式

转自: http://www.blogjava.net/DLevin/archive/2015/09/02/427045.html Reactor模式详解 前记 第一次听到Reactor模式是三年前的某个晚上,一个室友突然跑过来问我什么是Reactor模式?我上网查了一下,很多人都是给出NIO中的 Selector的例子,而且就是NIO里Selector多路复用模型,只是给它起了一个比较fancy的名字而已,虽然它引入了EventLoop概 念,这对我来说是新的概念,但是代码实现却是一样的,因而

ACE - Reactor模式源码剖析及具体实现(大量源码慎入)

原文出自http://www.cnblogs.com/binchen-china,禁止转载. 在之前的文章中提到过Reactor模式和Preactor模式,现在利用ACE的Reactor来实现一个基于Reactor框架的服务器. 首先回顾下Reactor模式和Preactor模式. Reactor模式: Reactor模式实现非常简单,使用同步IO模型,即业务线程处理数据需要主动等待或询问,主要特点是利用epoll监听listen描述符是否有响应,及时将客户连接信息放于一个队列,epoll和队列

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

Reactor这个词译成汉语还真没有什么合适的,很多地方叫反应器模式,但更多好像就直接叫reactor模式了,其实我觉着叫应答者模式更好理解一些.通过了解,这个模式更像一个侍卫,一直在等待你的召唤. 1.reactor的形象比喻入门 并发系统常使用reactor模式,代替常用的多线程的处理方式,节省系统的资源,提高系统的吞吐量. 先用比较直观的方式来介绍一下这种方式的优点,通过和常用的多线程方式比较一下,可能更好理解. 以一个餐饮为例,每一个人来就餐就是一个事件,他会先看一下菜单,然后点餐.就像