Reactor

作者 | 赵钰莹 近日，Linux 基金会宣布成立 Reactive 基金会。对于 Reactive，各位开发者应该并不陌生，尤其是 Node.js 开发者，但真正了解并意识到这件事情对开发方式带来的影响的恐怕不多。本文，InfoQ 有幸第一时间对推动阿里巴巴成为该基金会初创成员的阿里巴巴资深技术专家雷卷进行了独家采访，进一步全面了解 Reactive 基金会的成立背景及其对开发方式的发展推动。 Reactive 基金会是什么？ 近日，Linux 基金会 宣布启动 Reactive 基金会，旨在加速发展构建下一代网络应用程序的架构。该基金会由阿里巴巴、Facebook、Lightbend、Netifi 和 Pivotal 等初始成员组成。涉及成功的开源规范 Reactive Streams 和 RSocket，以及编程语言实现。<br /> <br />虽然 Reactive 基金会刚刚成立，但 Reactive，也就是开发者常说的响应式编程，已经发展多年。2011 年，Reactive 就开始步入大众视野， 当时微软在 .Net Framework 4.0 中内置了Reactive 支持，称之为 Reactive Extensions。2013 年，广大 Java 开发者熟知的 RxJava 发布。接下来，Reactive 进入飞速发展阶段，先后出现了 RxRuby、RxJS

什么是阻塞/非阻塞，什么是同/异步 简介：使用最通俗概念讲解 同步异步、堵塞和非堵塞 洗衣机洗衣服 洗衣机洗衣服（ 无论阻塞式IO还是非阻塞式IO，都是同步IO模型 ） 同步阻塞：你把衣服丢到洗衣机洗，然后看着洗衣机洗完，洗好后再去晾衣服（你就干等，啥都不做，阻塞在那边） 同步非阻塞：你把衣服丢到洗衣机洗，然后会客厅做其他事情，定时去阳台看洗衣机是不是洗完了，洗好后再去晾衣服 （等待期间你可以做其他事情，玩游戏，看视频等等）。 但即便如此，依然要时不时地去看一下洗衣机是不是把衣服洗完了， 然后才能去晾衣服。 异步阻塞: 你把衣服丢到洗衣机洗，然后看着洗衣机洗完，洗好后再去晾衣服（几乎没这个情况，几乎没这个说法，可以忽略， 异步不可能阻塞 ） 异步非阻塞：你把衣服丢到洗衣机洗，然后会客厅做其他事情，洗衣机洗好后会自动去晾衣服，晾完成后放个音乐告诉你洗好衣服并晾好了， 这里你不需要晾衣服。 同步有先后顺序，无论是否阻塞。异步没有先后顺序，各自完成各自的事情。 在讲解Netty之前，需要先说明一下什么是 Reactor 设计模式 设计模式 ——Reactor 模式(反应器设计模式)，是一种基于事件驱动的设计模式，在事件驱动的应用中，将 一个或多个客户的服务请求分离( demultiplex )和调度( dispatch )给应用程序。在事件驱动的应用中，同步 地

本文链接：https://blog.csdn.net/king866/article/details/54427447 Netty是一个高性能、异步事件驱动的NIO框架，它提供了对TCP、UDP和文件传输的支持，作为一个异步NIO框架，Netty的所有IO操作都是异步非阻塞的，通过Future-Listener机制，用户可以方便的主动获取或者通过通知机制获得IO操作结果。 作为当前最流行的NIO框架，Netty在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用，一些业界著名的开源组件也基于Netty的NIO框架构建 传统通信采用了同步阻塞IO，当客户端的并发压力或者网络时延增大之后，同步阻塞IO会由于频繁的wait导致IO线程经常性的阻塞，由于线程无法高效的工作，IO处理能力自然下降。 我们通过BIO通信模型图看下BIO通信的弊端 采用BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接，接收到客户端连接之后为客户端连接创建一个新的线程处理请求消息，处理完成之后，返回应答消息给客户端，线程销毁，这就是典型的一请求一应答模型。 该架构最大的问题就是不具备弹性伸缩能力，当并发访问量增加后，服务端的线程个数和并发访问数成线性正比，由于线程是JAVA虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统的性能急剧下降，随着并发量的继续增加

转自：http://blog.csdn.net/analogous_love/article/details/53319815 最近一直在看游双的《高性能 Linux 服务器编程》一书，下载链接： http://download.csdn.net/detail/analogous_love/9673008 书上是这么介绍Reactor模式的： 按照这个思路，我写个简单的练习： [cpp] view plain copy /** * @desc : 用reactor模式练习服务器程序，main.cpp * @author : zhangyl * @date : 2016.11.23 */ #include <iostream> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> //for htonl() and htons() #include <unistd.h> #include <fcntl.h> #include <sys/epoll.h> #include <signal.h> //for signal() #include <pthread.h> #include <semaphore.h>

现在IO模型主要分三类：BIO(同步阻塞IO),NIO(同步非阻塞IO),AIO()。 先来看看BIO。 1. BIO 服务端接受到请求后，要指派或新建一个线程去处理客户端的IO请求，直到收到断开连接的指令。这么做的弊端是什么呢？当服务端收到大量来自客户端的IO请求时，需要新建大量线程来处理请求，服务器资源很可能被耗尽，高并发情况下，导致大量连接被挂起，服务器资源严重不足。因为BIO是同步阻塞模型，所以针对每个socket连接，服务器都要新建线程，哪怕是使用了线程池，也会造成因为线程上下文切换而造成大量开销。 NIO NIO是非阻塞IO,使用Reactor模型。Reactor模型中，NIO只有acceptor的服务线程是堵塞进行的，其它读写线程是通过注册事件的方式，有读写事件激活时才调用线程资源去执行，不会一直堵塞等着读写操作。Reactor的瓶颈主要是在acceptor的执行，所有的读写事件都是在acceptor分发。 AIO 与NIO不同，AIO需要一个连接注册读写事件和回调方法，当进行读写操作时，只须直接调用API的read或write方法即可。这两种方法均为异步的，对于读操作而言，当有流可读取时，操作系统会将可读的流传入read方法的缓冲区，并通知应用程序；对于写操作而言，当操作系统将write方法传递的流写入完毕时，操作系统主动通知应用程序。总结：用户发起IO操作立即返回

一：Netty、NIO、多线程？ 时隔很久终于又更新了！之前一直迟迟未动也是因为积累不够，后面比较难下手。过年期间 @李林锋hw 发布了一个Netty5.0架构剖析和源码解读 http://vdisk.weibo.com/s/C9LV9iVqH13rW/1391437855 ，看完也是收获不少。前面的文章我们分析了Netty的结构，这次咱们来分析最错综复杂的一部分-Netty中的多线程以及NIO的应用。 理清NIO与Netty的关系之前，我们必须先要来看看Reactor模式。Netty是一个典型的多线程的Reactor模式的使用，理解了这部分，在宏观上理解Netty的NIO及多线程部分就不会有什么困难了。 本篇文章依然针对Netty 3.7，不过因为也看过一点Netty 5的源码，所以会有一点介绍。 二：Reactor，反应堆还是核电站？ 1、Reactor的由来 Reactor是一种广泛应用在服务器端开发的设计模式。Reactor中文大多译为“反应堆”，我当初接触这个概念的时候，就感觉很厉害，是不是它的原理就跟“核反应”差不多？后来才知道其实没有什么关系，从Reactor的兄弟“Proactor”（多译为前摄器）就能看得出来，这两个词的中文翻译其实都不是太好，不够形象。实际上，Reactor模式又有别名“Dispatcher”或者“Notifier”

一、从《Apeche Kafka源码剖析》上搬来的概念和图 Kafka网络采用的是Reactor模式，是一种基于事件驱动的模式。熟悉Java编程的读者应该了解Java NIO提供了Reactor模式的API。常见的单线程Java NIO编程模式如图所示。 熟悉NIO编程都应该知道这个Selector，我们可以通过轮询它来获取监听事件，然后通过事件来进行不同的处理，比如OP_ACCEPT连接，OP_READ读取数据等等。 这样简单的处理对于客户端是没什么问题，但对于服务端来说就有些缺点了。在服务端，我们要求读取请求、处理请求以及发送响应各个环节必须能迅速完成，并且要尽可能做到互不影响。所以我们就需要对上述简单的模型进行修改。 为了满足高并发的需求，也为了充分利用服务器的资源，我们对上述的架构稍作调整，将网络读写的逻辑与业务处理的逻辑进行拆分，让其由不同的线程池来处理，如图所示。 二、套餐一：直接撸Kafka源码 如果不想看本文下面这个很挫的Reactor模型，可以直接看Kafka的源码 ~ 如果需要稍微借助一点中文注释，我已经标注了十分多的注释~ 可以直接看这个版本， 基于Kafka0.10.0.1的源码解读 ，当然也可以直接去看 官方版本 。 SocketServer就是它的入口。 其中，内部类 Acceptor 负责建立并配置新连接 内部类 Processor 负责处理IO事件。

Before you link me to other answers related to this, note that I've read them and am still a bit confused. Alrighty, here we go. So I am creating a webapp in Django. I am importing the newest scrapy library to crawl a website. I am not using celery (I know very little about it, but saw it in other topics related to this). One of the url's of our website, /crawl/, is meant to start the crawler running. It's the only url in our site that requires scrapy to be used. Here is the function which is called when the url is visited: def crawl(request): configure_logging({'LOG_FORMAT': '%(levelname)s: %