#1 反应堆模式和非阻塞I/O

一.阻塞 I/O

对于使用阻塞式I/O 的 web server,不能在同一个线程中同时处理多个connections。每一个I/O 操作都会阻塞其它的connection。所以传统处理并发的web server,一般采取多线程或一个进程(或在进程池中重用一个taken),这样,当一个线程被I/O操作阻塞时,不会影响其他的请求,因为它们采用分开的线程的处理方式。

缺点:
blocking io.jpg
  • 当与数据库或filesystem交互时,我们需要等待操作完成的结果
  • 线程对于系统资源的花销是很昂贵,这样并不是很效率

二.非阻塞式 I/O

除了上面的阻塞式I/O,现在的操作系统都支持另一种访问资源的方式,叫做非阻塞 I/O。系统永远立即返回,而不用等待数据被读取或写入。如果在调用时没有结果可以获取,函数将返回预先定义的常量,表示当时没有数据可获取。

最基本的实现非阻塞式I/O的方式是,通过轮询资源(polling loop),直到实际的数据被返回,这种方式称之为busy-waiting,但是这样做会消耗大量CPU资源,所以并不效率

三.事件多路分解器(Event demultiplexing)

上面介绍的Busy-waiting 很明显不适合处理非阻塞资源。幸运的是,现在操作系统提供了一种原生的,高效率的处理并发,非阻塞资源的方法,称之为 同步事件多路分解器(synchronous event demultiplexer)事件通知接口(event notification interface)

这个组件收集和队列一系列来自被观察资源的 I/O事件,并且屏蔽它们,直到新的事件能够处理。

Event demultiplxer.jpg

伪代码过程:

socketA, pipeB;
watchedList.add(socketA, FOR_READ); // [1]
watchedList.add(pipeB, FOR_READ);
while(events = demultiplexer.watch(watchedList)) { // [2]
  // 事件循环
  foreach(event in events) {   // [3]
    // 这个read方法,永远不会被阻塞
    // 并且永远返回数据
    data = event.resource.read();
    if (data === RESOURCE_CLOSED) {
      // 资源被关闭,则将其从观察列表中移除
      demultiplexer.unwatch(event.resource);
    } else {
      // 一些实际的数据被接受并被处理
      consumeData(data);
    }
  }
}

伪代码中比较重要的步骤:

  • [1]: 资源和相应的特定操作(例如read操作)添加到数据结构中
  • [2]: 事件通知器设置一系列资源被观测。这个调用是同步的,阻塞的,知道任何被观测的资源被 read。当这发生时,事件多路分解器从调用中返回,并且新的一系列事件能够被处理
  • 被事件分解器处理的每个事件被返回。资源和相应的事件确保准备读取,这个操作是非阻塞的。当事件被处理,这个工作流再次阻塞直到新的事件重新可以被处理。这个过程称之为 event loop

四.反应堆模式(Reactor pattern)

主要思想是,通过handler(在Node.js中以 callback 函数表示)结合每个 I/O 操作,当事件产生并且通过事件循环处理时,这个handler将被调用。结构如下:

上图即是应用使用反应堆模式时的状态:

1.应用通过提交请求到Event Demultiplexer产生新的I/O操作。应用同时指定handler,当操作完成时调用(即回调函数)。提交新的请求到Event Demultiplexer是一个非阻塞调用,它立即返回control到应用

2.当一系列的I/O操作完成,Event Demultiplexer将新的事件添加到事件队列(Event Queue)中

3.此时 Event Loop迭代 事件队列 中的 items

4.对于每个event,相应的handler被调用

5.handler执行完毕之后,将返回control到event loop中(5a);然而,在执行handler的过程中,新的异步操作可能被请求(5b),在control返回到event loop之前, 引起新的操作被插入到Event Demultiplexer(第1步)中

6.当Event Queue中所有的项目被被处理,这个循环将重新阻塞在Event Demultiplexer,知道一个新的事件的到来。

总结: reactor pattern通过阻塞来处理I/O,知道来自一组被观察资源的新事件可用,然后通过将每个事件分派到相关联的处理程序来做出反应。

NodeJS底层通过C语言库 libuv来兼容主流平台和
规范不同类型资源的非阻塞行为。libuv现在用于表示Node.js底层的I/O引擎。libuv介绍

NodeJS底层架构:

nodejs framework.jpg

总结

主要涉及Node.js的一些基本概念:

  • 事件多路分解器(Event demultiplexer)
  • 非阻塞I/O操作
  • 事件队列Event Queue
  • Reactor pattern: 异步的特点,通过回调函数的方式来消除线程和竞态的担忧
  • event loop
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 195,980评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,422评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,130评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,553评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,408评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,326评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,720评论 3 386
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,373评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,678评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,722评论 2 312
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,486评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,335评论 3 313
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,738评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,009评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,283评论 1 251
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,692评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,893评论 2 335

推荐阅读更多精彩内容