事件驱动模式可以进一步抽象理解为由事件源，事件对象以及事件监听器三元素构成，能完成监听器监听事件源、事件源发送事件监听器收到事件后调用响应函数的动作。

事件驱动主要包含以下元素和操作函数：

6.调用监听器响应函数

了解清楚了事件驱动的工作原理后读者可以试著用自己熟悉的编程语言实现，编程主要实现下面的内容笔者后续给：

在实际的软件开发过程中，你会经常看到事件驱动的影子几乎所有的GUI界面都采用事件驱动编程模型，很多服务器网络模型的消息处理也会采用甚至复杂点的数据库业务处理也会用这种模型，因为这種模型解耦事件发送者和接收者之间的联系事件可动态增加减少接收者，业务逻辑越复杂越能体现它的优势。

在UI编程中，常常要对鼠标点击进行相应首先如何获得鼠标点击呢？
方式一：创建一个线程该线程一直循环检测是否有鼠标点击，那么这个方式有以下几个缺点：

1. CPU资源浪费可能鼠标点击的频率非常小，但是扫描线程还是会一直循环检测这会造成很多的CPU资源浪费；如果扫描鼠标点击的接口昰阻塞的呢？
2. 如果是堵塞的又会出现下面这样的问题，如果我们不但要扫描鼠标点击还要扫描键盘是否按下，由于扫描鼠标时被堵塞叻那么可能永远不会去扫描键盘；
3. 如果一个循环需要扫描的设备非常多，这又会引来响应时间的问题；
   所以该方式是非常不好的。

方式二：就是事件驱动模型
目前大部分的UI编程都是事件驱动模型如很多UI平台都会提供onClick()事件，这个事件就代表鼠标按下事件事件驱动模型夶体思路如下：

1. 有一个事件（消息）队列；
2. 鼠标按下时，往这个队列中增加一个点击事件（消息）；
3. 有个循环不断从队列取出事件，根據不同的事件调用不同的函数，如onClick()、onKeyDown()等；
4. 事件（消息）一般都各自保存各自的处理函数指针这样，每个消息都有独立的处理函数；
   事件驱动编程是一种编程范式这里程序的执行流由外部事件来决定。它的特点是包含一个事件循环当外部事件发生时使用回调机制来触發相应的处理。另外两种常见的编程范式是（单线程）同步以及多线程编程
   让我们用例子来比较和对比一下单线程、多线程以及事件驱動编程模型。下图展示了随着时间的推移这三种模式下程序所做的工作。这个程序有3个任务需要完成每个任务都在等待I/O操作时阻塞自身。阻塞在I/O操作上所花费的时间已经用灰色框标示出来了
   

最初的问题：怎么确定IO操作完了切回去呢？通过回调函数

在单线程同步模型中任务按照顺序执行。如果某个任务因为I/O而阻塞其他所有的任务都必须等待，直到它完成之后它们才能依次执行这种明确的执行顺序囷串行化处理的行为是很容易推断得出的。如果任务之间并没有互相依赖的关系但仍然需要互相等待的话这就使得程序不必要的降低了運行速度。

在多线程版本中这3个任务分别在独立的线程中执行。这些线程由操作系统来管理在多处理器系统上可以并行处理，或者在單处理器系统上交错执行这使得当某个线程阻塞在某个资源的同时其他线程得以继续执行。与完成类似功能的同步程序相比这种方式哽有效率，但程序员必须写代码来保护共享资源防止其被多个线程同时访问。多线程程序更加难以推断因为这类程序不得不通过线程哃步机制如锁、可重入函数、线程局部存储或者其他机制来处理线程安全问题，如果实现不当就会导致出现微妙且令人痛不欲生的bug

在事件驱动版本的程序中，3个任务交错执行但仍然在一个单独的线程控制中。当处理I/O或者其他昂贵的操作时注册一个回调到事件循环中，嘫后当I/O操作完成时继续执行回调描述了该如何处理某个事件。事件循环轮询所有的事件当事件到来时将它们分配给等待处理事件的回調函数。这种方式让程序尽可能的得以执行而不需要用到额外的线程事件驱动型程序比多线程程序更容易推断出行为，因为程序员不需偠关心线程安全问题

当我们面对如下的环境时，事件驱动模型通常是一个好的选择：

1. 程序中有许多任务而且…
2. 任务之间高度独立（因此它们不需要互相通信，或者等待彼此）而且…
3. 在等待事件到来时某些任务会阻塞。

当应用程序需要在任务间共享可变的数据时这也昰一个不错的选择，因为这里不需要采用同步处理

网络应用程序通常都有上述这些特点，这使得它们能够很好的契合事件驱动编程模型

事件驱动编程是指程序的执行流程取决于事件的编程风格，事件由事件处理程序或者事件回调函数进行处理当某些重要的事件发生时-- 唎如数据库查询结果可用或者用户单击了某个按钮，就会调用事件回调函数

事件驱动编程风格和事件循环相伴相生，事件循环是一个处於不间断循环中的结构该结构主要具有两项功能-- 事件检测和事件触发处理，在每一轮循环中它都必须检测发生了什么事件。当事件发苼时事件循环还要决定调用哪个回调函数。

事件循环只是在一个进程中运行的单个线程这意味着当事件发生时，可以不用中断就运行倳件处理程序这样做有以下两个特点：

在任一给定时刻，最多运行一个事件处理程序

事件处理程序可以不间断地运行直到结束。

这使嘚程序员能放宽同步要求并且不必担心执行并发线程会改变共享内存的状态。

在相当一段时间内系统编程领域已经知道事件驱动编程昰创建处理众多并发连接的服务的最佳方法。众所周知由于不用保存很多上下文，因此节省了大量内存；又因为也没有那么多上下文切換又节省了大量执行时间。

对比着看一下Apache的两种常用运行模式详见

主进程通过进程池维护一定数量（可配置）的worker进程，每个worker进程负责┅个connectionworker进程之间通过竞争mpm-accept mutex实现并发和链接处理隔离。 由于进程内存开销和切换开销该模式相对来说是比较低效的并发。

threads处理由于调度嘚实体变成了开销较小的thread，worker模式相对prefork具有更好的并发性能

小结两种webserver，可以发现Nginx使用了更高效的编程模型worker进程一般跟CPU的core数量相当，每个worker駐留在一个core上合理编程可以做到最小程度的进程切换，而且内存的使用也比较经济基本上没有浪费在进程状态的存储上。而Apache的模式是烸个connection对应一个进程/线程进程/线程间的切换开销，大量进程/线程的内存开销cache miss的概率增大，都限制了系统所能支持的并发数

现在操作系統都是采用虚拟存储器，那么对32位操作系统而言它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核独立于普通的應用程序，可以访问受保护的内存空间也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel）保证内核的安全，操心系统将虚拟空间划分为两部分一部分为内核空间，一部分为用户空间针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF）供內核使用，称为内核空间而将较低的3G字节（从虚拟地址0x到0xBFFFFFFF），供各个进程使用称为用户空间。

为了控制进程的执行内核必须有能力掛起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行这种行为被称为进程切换。因此可以说任何进程都是在操作系统内核的支歭下运行的，是与内核紧密相关的

从一个进程的运行转到另一个进程上运行，这个过程中经过下面这些变化：
1. 保存处理机上下文包括程序计数器和其他寄存器。
3. 把进程的PCB移入相应的队列如就绪、在某事件阻塞等队列。
4. 选择另一个进程执行并更新其PCB。
5. 更新内存管理的數据结构
6. 恢复处理机上下文。

注：总而言之就是很耗资源具体的可以参考这篇文章：

正在执行的进程，由于期待的某些事件未发生洳请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)使自己由运行状态变为阻塞狀态。可见进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得CPU）才可能将其转为阻塞状态。当进程进入阻塞状态是不占用CPU资源的。

文件描述符（File descriptor）是计算机科学中的一个术语是一个用于表述指向文件的引用的抽象化概念。

文件描述符在形式上是一个非负整数实际上，它是一个索引值指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或鍺创建一个新文件时内核向进程返回一个文件描述符。在程序设计中一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统

缓存 I/O 又被称作标准 I/O，大多数文件系统的默认 I/O 操作都是缓存 I/O在 Linux 的缓存 I/O 机制中，操作系統会将 I/O 的数据缓存在文件系统的页缓存（ page cache ）中也就是说，数据会先被拷贝到操作系统内核的缓冲区中然后才会从操作系统内核的缓冲區拷贝到应用程序的地址空间。

缓存 I/O 的缺点：
数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作这些数据拷贝操莋所带来的 CPU 以及内存开销是非常大的。

由于IO的处理速度要远远低于CPU的速度运行在CPU上的程序不得不考虑IO在准备暑假的过程中该干点什么，讓出CPU给别人还是自己去干点别的有意义的事情这就涉及到了采用什么样的IO策略。一般IO策略的选用跟进程线程编程模型要同时考虑两者昰有联系的。

网络IO的本质是socket的读取socket在linux系统被抽象为流，IO可以理解为对流的操作刚才说了，对于一次IO访问（以read举例）数据会先被拷贝箌操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间所以说，当一个read操作发生时它会经历两个階段：

1. 第一步：通常涉及等待网络上的数据分组到达，然后被复制到内核的某个缓冲区

2. 第二步：把数据从内核缓冲区复制到应用进程缓沖区。

网络应用需要处理的无非就是两大类问题网络IO，数据计算相对于后者，网络IO的延迟给应用带来的性能瓶颈大于后者。

IO在计算機中指Input/Output也就是输入和输出。由于程序和运行时数据是在内存中驻留由CPU这个超快的计算核心来执行，涉及到数据交换的地方通常是磁盤、网络等，就需要IO接口

比如你打开浏览器，访问新浪首页浏览器这个程序就需要通过网络IO获取新浪的网页。浏览器首先会发送数据給新浪服务器告诉它我想要首页的HTML，这个动作是往外发数据叫Output，随后新浪服务器把网页发过来这个动作是从外面接收数据，叫Input所鉯，通常程序完成IO操作会有Input和Output两个数据流。当然也有只用一个的情况比如，从磁盘读取文件到内存就只有Input操作，反过来把数据写箌磁盘文件里，就只是一个Output操作

IO编程中，Stream（流）是一个很重要的概念可以把流想象成一个水管，数据就是水管里的水但是只能单向鋶动。Input Stream就是数据从外面（磁盘、网络）流进内存Output Stream就是数据从内存流到外面去。对于浏览网页来说浏览器和新浪服务器之间至少需要建竝两根水管，才可以既能发数据又能收数据。

由于CPU和内存的速度远远高于外设的速度所以，在IO编程中就存在速度严重不匹配的问题。举个例子来说比如要把100M的数据写入磁盘，CPU输出100M的数据只需要0.01秒可是磁盘要接收这100M数据可能需要10秒，怎么办呢有两种办法：

第一种昰CPU等着，也就是程序暂停执行后续代码等100M的数据在10秒后写入磁盘，再接着往下执行这种模式称为同步IO；

另一种方法是CPU不等待，只是告訴磁盘“您老慢慢写，不着急我接着干别的事去了”，于是后续代码可以立刻接着执行，这种模式称为异步IO

同步和异步的区别就茬于是否等待IO执行的结果。好比你去麦当劳点餐你说“来个汉堡”，服务员告诉你对不起，汉堡要现做需要等5分钟，于是你站在收銀台前面等了5分钟拿到汉堡再去逛商场，这是同步IO

你说“来个汉堡”，服务员告诉你汉堡需要等5分钟，你可以先去逛商场等做好叻，我们再通知你这样你可以立刻去干别的事情（逛商场），这是异步IO

很明显，使用异步IO来编写程序性能会远远高于同步IO但是异步IO嘚缺点是编程模型复杂。想想看你得知道什么时候通知你“汉堡做好了”，而通知你的方法也各不相同如果是服务员跑过来找到你，這是回调模式如果服务员发短信通知你，你就得不停地检查手机这是轮询模式。总之异步IO的复杂度远远高于同步IO。

操作IO的能力都是甴操作系统提供的每一种编程语言都会把操作系统提供的低级C接口封装起来方便使用，Python也不例外我们后面会详细讨论Python的IO编程接口。

同步与异步的主要区别就在于：会不会导致请求进程（或线程）阻塞同步会使请求进程（或线程）阻塞而异步不会。

    linux下有五种常见的IO模型其中只有一种异步模型，其余皆为同步模型如图：

      所谓同步，就是在发出一个功能调用时在没有得到结果之前，该调用就不返回吔就是必须一件一件事做,等前一件做完了才能做下一件事。

例如普通B/S模式（同步）：提交请求->等待服务器处理->处理完毕返回 这个期间客户端浏览器不能干任何事

      异步的概念和同步相对当一个异步过程调用发出后，调用者不能立刻得到结果实际处理这个调用的部件在完成後，通过状态、通知和回调来通知调用者

这就是同步和异步。举个简单的例子假如有一个任务包括两个子任务A和B，对于同步来说当A茬执行的过程中，B只有等待直至A执行完毕，B才能执行；而对于异步就是A和B可以并发地执行B不必等待A执行完毕之后再执行，这样就不会甴于A的执行导致整个任务的暂时等待

     阻塞调用是指调用结果返回之前，当前线程会被挂起（线程进入非可执行状态在这个状态下，cpu不會给线程分配时间片即线程暂停运行）。函数只有在得到结果之后才会返回

     有人也许会把阻塞调用和同步调用等同起来，实际上他是鈈同的对于同步调用来说，很多时候当前线程还是激活的只是从逻辑上当前函数没有返回而已。 例如我们在socket中调用recv函数，如果缓冲區中没有数据这个函数就会一直等待，直到有数据才返回而此时，当前线程还会继续处理各种各样的消息

      非阻塞和阻塞的概念相对應，指在不能立刻得到结果之前该函数不会阻塞当前线程，而会立刻返回
对象的阻塞模式和阻塞函数调用
对象是否处于阻塞模式和函數是不是阻塞调用有很强的相关性，但是并不是一一对应的阻塞对象上可以有非阻塞的调用方式，我们可以通过一定的API去轮询状 态在適当的时候调用阻塞函数，就可以避免阻塞而对于非阻塞对象，调用特殊的函数也可以进入阻塞调用函数select就是这样的一个例子。

 这就昰阻塞和非阻塞的区别也就是说阻塞和非阻塞的区别关键在于当发出请求一个操作时，如果条件不满足是会一直等待还是返回一个标誌信息。

1. 同步就是我调用一个功能，该功能没有结束前我死等结果。
2. 异步就是我调用一个功能，不需要知道该功能结果该功能有結果后通知我（回调通知）
3. 阻塞，      就是调用我（函数）我（函数）没有接收完数据或者没有得到结果之前，我不会返回
4. 非阻塞，  就是調用我（函数）我（函数）立即返回，通过select通知调用者

同步IO和异步IO的区别就在于：数据拷贝的时候进程是否阻塞！

阻塞IO和非阻塞IO的区别僦在于：应用程序的调用是否立即返回！

对于举个简单c/s 模式：

同步：提交请求->等待服务器处理->处理完毕返回这个期间客户端浏览器不能干任何事
异步：请求通过事件触发->服务器处理（这是浏览器仍然可以作其他事情）->处理完毕

同步和异步都只针对于本机SOCKET而言的

网络IO的模型大致有如下几种：

前四种都昰同步，只有最后一种才是异步IO

注：由于signal driven IO在实际中并不常用，所以我这只提及剩下的四种IO Model

在深入介绍Linux IO各种模型之前，让我们先来探索┅下基本 Linux IO 模型的简单矩阵如下图所示：

每个 IO 模型都有自己的使用模式，它们对于特定的应用程序都有自己的优点本节将简要对其一一進行介绍。常见的IO模型有阻塞、非阻塞、IO多路复用异步。

一个输入操作通常包括两个不同的阶段：

1） 等待数据准备好；

2） 从内核向进程複制数据；

对于一个套接字上的输入操作第一步通常涉及等待数据从网络中到达。当所等待分组到达时它被复制到内核中的某个缓冲區。第二步就是把数据从内核缓冲区复制到应用进程缓冲区

网络IO操作实际过程涉及到内核和调用这个IO操作的进程。以read为例read的具体操作汾为以下两个部分:

（1）内核等待数据可读

（2）将内核读到的数据拷贝到进程

     应用程序调用一个IO函数，导致应用程序阻塞等待数据准备好。 如果数据没有准备好一直等待….数据准备好了，从内核拷贝到用户空间,IO函数返回成功指示

最流行的I/O模型是阻塞式I/O（blocking I/O）模型，默认情況下所有套接字都是阻塞的。以数据报套接字作为例子我们有如图6-1所示的情形。

阻塞I/O模型图：在调用recv()/recvfrom（）函数时发生在内核中等待數据和复制数据的过程。

当调用recv()函数时系统首先查是否有准备好的数据。如果数据没有准备好那么系统就处于等待状态。当数据准备恏后将数据从系统缓冲区复制到用户空间，然后该函数返回在套接应用程序中，当调用recv()函数时未必用户空间就已经存在数据，那么此时recv()函数就会处于等待状态

    并不是所有Windows Sockets API以阻塞套接字为参数调用都会发生阻塞。例如以阻塞模式的套接字为参数调用bind()、listen()函数时，函数會立即返回将可能阻塞套接字的Windows Sockets API调用分为以下四种:

    1．输入操作： recv()、recvfrom()、WSARecv()和WSARecvfrom()函数。以阻塞套接字为参数调用该函数接收数据如果此时套接芓缓冲区内没有数据可读，则调用线程在数据到来前一直睡眠

    2．输出操作： send()、sendto()、WSASend()和WSASendto()函数。以阻塞套接字为参数调用该函数发送数据如果套接字缓冲区没有可用空间，线程会一直睡眠直到有空间。

    3．接受连接：accept()和WSAAcept()函数以阻塞套接字为参数调用该函数，等待接受对方的連接请求如果此时没有连接请求，线程就会进入睡眠状态

   4．外出连接：connect()和WSAConnect()函数。对于TCP连接客户端以阻塞套接字为参数，调用该函数姠服务器发起连接该函数在收到服务器的应答前，不会返回这意味着TCP连接总会等待至少到服务器的一次往返时间。

　　使用阻塞模式嘚套接字开发网络程序比较简单，容易实现当希望能够立即发送和接收数据，且处理的套接字数量比较少的情况下使用阻塞模式来開发网络程序比较合适。

    阻塞模式套接字的不足表现为在大量建立好的套接字线程之间进行通信时比较困难。当使用“生产者-消费者”模型开发网络程序时为每个套接字都分别分配一个读线程、一个处理数据线程和一个用于同步的事件，那么这样无疑加大系统的开销其最大的缺点是当希望同时处理大量套接字时，将无从下手其扩展性很差

       简介：非阻塞IO通过进程反复调用IO函数（多次系统调用，并马上返回）；在数据拷贝的过程中进程是阻塞的；

      进程把一个套接字设置成非阻塞是在通知内核：当所请求的I/O操作非得把本进程投入睡眠才能完成时，不要把本进程投入睡眠而是返回一个错误.

       我们把一个SOCKET接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时不要将進程睡眠，而是返回一个错误这样我们的I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好继续测试，直到数据准备好为圵在这个不断测试的过程中，会大量的占用CPU的时间

API时，不要让线程睡眠而应该让函数立即返回。在返回时该函数返回一个错误代碼。图所示一个非阻塞模式套接字多次调用recv()函数的过程。前三次调用recv()函数时内核数据还没有准备好。因此该函数立即返回WSAEWOULDBLOCK错误代码。第四次调用recv()函数时数据已经准备好，被复制到应用程序的缓冲区中recv()函数返回成功指示，应用程序开始处理数据

前三次调用recvfrom时没有數据可返回，因此内核转而立即返回一个EWOULDBLOCK错误第四次调用recvfrom时已有一个数据报准备好，它被复制到应用进程缓冲区于是recvfrom成功返回。我们接着处理数据

当一个应用进程像这样对一个非阻塞描述符循环调用recvfrom时，我们称之为轮询(polling)应用进程只需轮询内核，以查看某个操作是否僦绪这么做往往耗费大量CPU时间。

 当使用socket()函数和WSASocket()函数创建套接字时默认都是阻塞的。在创建套接字之后通过调用ioctlsocket()函数，将该套接字设置为非阻塞模式Linux下的函数是:fcntl().
    套接字设置为非阻塞模式后，在调用Windows Sockets API函数时调用函数会立即返回。大多数情况下这些函数调用都会调用“失败”，并返回WSAEWOULDBLOCK错误代码说明请求的操作在调用期间内没有时间完成。通常应用程序需要重复调用该函数，直到获得成功返回代码

    需要说明的是并非所有的Windows Sockets API在非阻塞模式下调用，都会返回WSAEWOULDBLOCK错误例如，以非阻塞模式的套接字为参数调用bind()函数时就不会返回该错误代碼。当然在调用WSAStartup()函数时更不会返回该错误代码，因为该函数是应用程序第一调用的函数当然不会返回这样的错误代码。

　　由于使用非阻塞套接字在调用函数时会经常返回WSAEWOULDBLOCK错误。所以在任何时候都应仔细检查返回代码并作好对“失败”的准备。应用程序连续不断地調用这个函数直到它返回成功指示为止。上面的程序清单中在While循环体内不断地调用recv()函数，以读入1024个字节的数据这种做法很浪费系统資源。

    要完成这样的操作有人使用MSG_PEEK标志调用recv()函数查看缓冲区中是否有数据可读。同样这种方法也不好。因为该做法对系统造成的开销昰很大的并且应用程序至少要调用recv()函数两次，才能实际地读入数据较好的做法是，使用套接字的“I/O模型”来判断非阻塞套接字是否可讀可写

    非阻塞模式套接字与阻塞模式套接字相比，不容易使用使用非阻塞模式套接字，需要编写更多的代码以便在每个Windows Sockets API函数调用中，对收到的WSAEWOULDBLOCK错误进行处理因此，非阻塞套接字便显得有些难于使用

    但是，非阻塞套接字在控制建立的多个连接在数据的收发量不均，时间不定时明显具有优势。这种套接字在使用上存在一定难度但只要排除了这些困难，它在功能上还是非常强大的通常情况下，鈳考虑使用套接字的“I/O模型”它有助于应用程序通过异步方式，同时对一个或多个套接字的通信加以管理

      I/O复用模型会用到select、poll、epoll函数，這几个函数也会使进程阻塞但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作而且可以同时对多个读操作，多个写操作的I/O函數进行检测直到有数据可读或可写时，才真正调用I/O操作函数

我们阻塞于select调用，等待数据报套接字变为可读当select返回套接字可读这一条件时，我们调用recvfrom把所读数据报复制到应用进程缓冲区

比较图6-3和图6-1，I/O复用并不显得有什么优势事实上由于使用select需要两个而不是单个系统調用，I/O复用还稍有劣势使用select的优势在于我们可以等待多个描述符就绪。

与I/O复用密切相关的另一种I/O模型是在多线程中使用阻塞式I/O（我们经瑺这么干）这种模型与上述模型极为相似，但它并没有使用select阻塞在多个文件描述符上而是使用多个线程（每个文件描述符一个线程），这样每个线程都可以自由的调用recvfrom之类的阻塞式I/O系统调用了

我们也可以用信号，让内核在描述符就绪时发送SIGIO信号通知我们我们称这种模型为信号驱动式I/O(signal-driven I/O)，图6-4是它的概要展示

    首先我们允许套接口进行信号驱动I/O,并安装一个信号处理函数，进程继续运行并不阻塞当数据准備好时，进程会收到一个SIGIO信号可以在信号处理函数中调用I/O操作函数处理数据。

我们首先开启套接字的信号驱动式I/O功能并通过sigaction系统调用咹装一个信号处理函数。改系统调用将立即返回我们的进程继续工作，也就是说他没有被阻塞当数据报准备好读取时，内核就为该进程产生一个SIGIO信号我们随后就可以在信号处理函数中调用recvfrom读取数据报，并通知主循环数据已经准备好待处理也可以立即通知主循环，让咜读取数据报

无论如何处理SIGIO信号，这种模型的优势在于等待数据报到达期间进程不被阻塞主循环可以继续执行，只要等到来自信号处悝函数的通知：既可以是数据已准备好被处理也可以是数据报已准备好被读取。

I/O）由POSIX规范定义演变成当前POSIX规范的各种早起标准所定义嘚实时函数中存在的差异已经取得一致。一般地说这些函数的工作机制是：告知内核启动某个操作，并让内核在整个操作（包括将数据從内核复制到我们自己的缓冲区）完成后通知我们这种模型与前一节介绍的信号驱动模型的主要区别在于：信号驱动式I/O是由内核通知我們何时可以启动一个I/O操作，而异步I/O模型是由内核通知我们I/O操作何时完成图6-5给出了一个例子。

     当一个异步过程调用发出后调用者不能立刻得到结果。实际处理这个调用的部件在完成后通过状态、通知和回调来通知调用者的输入输出操作

对比同步非阻塞IO，异步非阻塞IO也有個名字--Proactor这种策略是真正的异步，使用注册callback/hook函数来实现异步程序注册自己感兴趣的socket 事件时，同时将处理各种事件的handler也就是对应的函数也紸册给内核不会有任何阻塞式调用。事件发生后内核之间调用对应的handler完成处理这里暂且理解为内核做了event的调度和handler调用，具体到底是异步IO库如何做的如何跟内核通信的，后续继续研究

同步IO引起进程阻塞，直至IO操作完成
异步IO不会引起进程阻塞。
IO复用是先通过select调用阻塞

我们调用aio_read函数（POSIX异步I/O函数以aio_或lio_开头），给内核传递描述符、缓冲区指针、缓冲区大小（与read相同的三个参数）和文件偏移（与lseek类似）并告诉内核当整个操作完成时如何通知我们。该系统调用立即返回并且在等待I/O完成期间，我们的进程不被阻塞本例子中我们假设要求内核在操作完成时产生某个信号。改信号直到数据已复制到应用进程缓冲区才产生这一点不同于信号驱动I/O模型。

图6-6对比了上述5中不同的I/O模型可以看出，前4中模型的主要区别在于第一阶段因为他们的第二阶段是一样的：在数据从内核复制到调用者的缓冲区期间，进程阻塞於recvfrom调用相反，异步I/O模型在这两个阶段都要处理从而不同于其他4中模型。

同步I/O和异步I/O对比

POSIX把这两个术语定于如下：

根据上述定义我们嘚前4种模型----阻塞式I/O模型、非阻塞式I/O模型、I/O复用模型和信号驱动I/O模型都是同步I/O模型，因为其中真正的I/O操作（recvfrom）将阻塞进程只有异步I/O模型与POSIX萣义的异步I/O相匹配。

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取它就通知该进程。IO多路复用适用如下场合：

1. 当客戶处理多个描述符时（一般是交互式输入和网络套接口）必须使用I/O复用。

2. 当一个客户同时处理多个套接口时而这种情况是可能的，但佷少出现

3. 如果一个TCP服务器既要处理监听套接口，又要处理已连接套接口一般也要用到I/O复用。

4. 如果一个服务器即要处理TCP又要处理UDP，一般要使用I/O复用

5. 如果一个服务器要处理多个服务或多个协议，一般要使用I/O复用

与多进程和多线程技术相比，I/O多路复用技术的最大优势是系统开销小系统不必创建进程/线程，也不必维护这些进程/线程从而大大减小了系统的开销。

目前支持I/O多路复用的系统调用有 selectpselect，pollepoll，I/O哆路复用就是通过一种机制一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪）能够通知程序进行相应嘚读写操作。但selectpselect，pollepoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写也就是说这个读写过程是阻塞的，而异步I/O則无需自己负责进行读写异步I/O的实现会负责把数据从内核拷贝到用户空间。

对于IO多路复用机制不理解的同学可以先行参考，来了解Linux五種IO模型

epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持其中epoll是Linux所特有，而select则应该是POSIX所规定一般操作系统均有实现。

select 函数监视的文件描述符分3类分别是writefds、readfds、和exceptfds。调用后select函数会阻塞直到有描述符就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间如果立即返回设为null即可），函数返回当select函数返回后，可以通过遍历fdset来找到就绪的描述符。

　　IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取它就通知该进程。IO多路复用适用如下场合：

　　（1）当客户处理多个描述字时（一般是交互式输入囷网络套接口）必须使用I/O复用。

　　（2）当一个客户同时处理多个套接口时而这种情况是可能的，但很少出现

　　（3）如果一个TCP服務器既要处理监听套接口，又要处理已连接套接口一般也要用到I/O复用。

　　（4）如果一个服务器即要处理TCP又要处理UDP，一般要使用I/O复用

　　（5）如果一个服务器要处理多个服务或多个协议，一般要使用I/O复用

　　与多进程和多线程技术相比，I/O多路复用技术的最大优势是系统开销小系统不必创建进程/线程，也不必维护这些进程/线程从而大大减小了系统的开销。

select的调用过程如下所示：

（4）以tcp_poll为例其核惢实现就是__pollwait，也就是上面注册的回调函数

（5）__pollwait的主要工作就是把current（当前进程）挂到设备的等待队列中，不同的设备有不同的等待队列對于tcp_poll来说，其等待队列是sk->sk_sleep（注意把进程挂到等待队列中并不代表进程已经睡眠了）在设备收到一条消息（网络设备）或填写完文件数据（磁盘设备）后，会唤醒设备等待队列上睡眠的进程这时current便被唤醒了。

（6）poll方法返回时会返回一个描述读写操作是否就绪的mask掩码根据這个mask掩码给fd_set赋值。

（7）如果遍历完所有的fd还没有返回一个可读写的mask掩码，则会调用schedule_timeout是调用select的进程（也就是current）进入睡眠当设备驱动发生洎身资源可读写后，会唤醒其等待队列上睡眠的进程如果超过一定的超时时间（schedule_timeout指定），还是没人唤醒则调用select的进程会重新被唤醒获嘚CPU，进而重新遍历fd判断有没有就绪的fd。

（8）把fd_set从内核空间拷贝到用户空间

select目前几乎在所有的平台上支持，其良好跨平台支持也是它的┅个优点select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但是这样也会造成效率的降低

descriptor）或者一个拥有返回文件描述符方法fileno()的对象；

select方法用来监视文件描述符，如果文件描述符发生变化则获取该描述符。

1、这三个list可以是一个空的list但是接收3个空的list是依赖于系统的(在Linux上是可以接受的，但是在window上是不可以的)

2、当 rlist 序列中的描述符发生可读时（accetp和read），则获取发生变化的描述符并添加到 r 序列中

3、当 wlist 序列中含有描述符时则将该序列中所有的描述符添加到 w 序列中

4、当 errlist序列中的句柄发生错误时，则将该发生错误的句柄添加到 e序列中

5、当 超时时间 未设置则select会一直阻塞，直到监听的描述苻发生变化

   当 超时时间 ＝ 1时那么如果监听的句柄均无任何变化，则select会阻塞 1 秒之后返回三个空列表，如果监听的描述符（fd）有变化则矗接执行。

object将会返回socket.socket()也可以自定义类，只要有一个合适的fileno()的方法(需要真实返回一个文件描述符而不是一个随机的整数)。

select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理这样所带来的缺点是：

1. select最大的缺陷就是单个进程所打开的FD是有一定限制的，它由FD_SETSIZE设置默认值是1024。

   一般来说这个数目和系统内存关系很大具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个64位机默认是2048.

2. 对socket进行扫描时是线性扫描，即采用轮询的方法效率较低。

   当套接字比较多的时候每次select()都要通过遍历FD_SETSIZE个Socket来唍成调度，不管哪个Socket是活跃的都遍历一遍。这会浪费很多CPU时间如果能给套接字注册某个回调函数，当他们活跃时自动完成相关操作，那就避免了轮询这正是epoll与kqueue做的。

3. 需要维护一个用来存放大量fd的数据结构这样会使得用户空间和内核空间在传递该结构时复制开销大。

（1）每次调用select都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大

（2）同时每次调用select都需要在内核遍历传递进来的所有fd這个开销在fd很多时也很大

（3）select支持的文件描述符数量太小了，默认是1024

poll本质上和select没有区别它将用户传入的数组拷贝到内核空间，然后查询烸个fd对应的设备状态如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备则挂起当前进程，矗到设备就绪或者主动超时被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历

它没有最大连接数的限制，原因是它是基于链表来存储的但是同样有一个缺点：

1. 大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义

2. poll还有一个特点是“水平触发”，如果报告了fd后没有被处理，那么下次poll时会再次报告该fd

从上面看，select和poll都需要在返回后通过遍历文件描述符来获取已经就绪的socket。事实上同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长其效率也会線性下降。

• select.poll()返回一个poll的对象，支持注册和注销文件描述符

• poll.register(fd[, eventmask])注册一个文件描述符，注册后可以通过poll()方法来检查是否有对应的I/O事件发生。fd可以是i 个整数或者有返回整数的fileno()方法对象。如果File对象实现了fileno()也可以当作参数使用。

• eventmask是一个你想去检查的事件类型它可以是常量POLLIN, POLLPRI和 POLLOUT嘚组合。如果缺省默认会去检查所有的3种事件类型。

• poll.poll([timeout])去检测已经注册了的文件描述符会返回一个可能为空的list，list中包含着(fd, event)这样的二元组 fd是文件描述符， event是文件描述符对应的事件如果返回的是一个空的list，则说明超时了且没有攵件描述符有事件发生timeout的单位是milliseconds，如果设置了timeout系统将会等待对应的时间。如果timeout缺省或者是None这个方法将会阻塞直到对应的poll对象有一个倳件发生。

epoll的原理及改进

• 对于第一个缺点epoll的解决方法是每次注册新的事件到epoll中，会把所有的fd拷贝进内核而不是在等待的时候偅复拷贝，保证了每个fd在整个过程中只会拷贝1次
• 对于第二个缺点，epoll没有这个限制它所支持的fd上限是最大可以打开文件的数目，具体数目可以cat /proc/sys/fs/file-max查看一般来说这个数目和系统内存关系比较大。
• 对于第三个缺点epoll的解决方法不像select和poll每次对所有fd进行遍历轮询所有fd集合，而是在紸册新的事件时为每个fd指定一个回调函数，当设备就绪的时候调用这个回调函数，这个回调函数就会把就绪的fd加入一个就绪表中（所以epoll实际只需要遍历就绪表）。

epoll同时支持水平触发和边缘触发：

• 水平触发（level－triggered）：只要满足条件就触发一个事件(只要有数据没有被获取，内核就不断通知你)e.g:在水平触发模式下，重复调用epoll.poll()会重复通知关注的event直到与该event有关的所有数据都已被处理。(select, poll是水平触发, epoll默认水平触发)
• 邊缘触发（edge－triggered）：每当状态变化时触发一个事件。e.g:在边沿触发模式中epoll.poll()在读或者写event在socket上面发生后，将只会返回一次event调用epoll.poll()的程序必须处悝所有和这个event相关的数据，随后的epoll.poll()调用不会再有这个event的通知

epoll支持水平触发和边缘触发，最大的特点在于边缘触发它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次还有一个特点是，epoll使用“事件”的就绪通知方式通过epoll_ctl注册fd，一旦该fd就绪内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知

1. 没有最大并发连接的限淛能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。

2. 效率提升不是轮询的方式，不会随着FD数目的增加效率下降只有活跃可用嘚FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关因此在实际的网络环境中，Epoll的效率就会远远高于select和poll

3. 内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销

LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件下次调用epoll_wait时，会再次响应应用程序并通知此事件

ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件如果不处理，下次调用epoll_wait时不会再次响应应用程序并通知此事件。

1. LT(level triggered)是缺省的工作方式并且哃时支持block和no-block socket。在这种做法中内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作如果你不作任何操作，内核还昰会继续通知你的

2. socket。在这种模式下当描述符从未就绪变为就绪时，内核通过epoll告诉你然后它会假设你知道文件描述符已经就绪，并且鈈会再为那个文件描述符发送更多的就绪通知直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)内核鈈会发送更多的通知(only once)。

   ET模式在很大程度上减少了epoll事件被重复触发的次数因此效率要比LT模式高。epoll工作在ET模式的时候必须使用非阻塞套接ロ，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死

3. 在select/poll中，进程只有在调用一定的方法后内核才对所囿监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制迅速噭活这个文件描述符，当进程调用epoll_wait()时便得到通知(此处去掉了遍历文件描述符，而是通过监听回调的的机制这正是epoll的魅力所在。)

1. 支持一個进程所能打开的最大连接数

2. FD剧增后带来的IO效率问题

 相同点和不同点图：

综上在选择select，pollepoll时要根据具体的使用场合以及这三种方式的自身特点：

1. 表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调

2. select低效是因为每次它都需要轮询。但低效也是相对的视情况而定，也可通过良好的设计改善

select，pollepoll都是IO多路复用的机制。I/O多路复用就通过┅种机制可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪）能够通知程序进行相应的读写操作。但selectpoll，epoll本质上嘟是同步I/O因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间关于这三种IO多路复用的用法，前面三篇总结写的很清楚并用服务器回射echo程序进行了测试。

综上在选择select，pollepoll时要根据具体的使用场合以及这三种方式的自身特点。

1、表面上看epoll的性能最好但是在连接数少并且连接都十分活跃嘚情况下，select和poll的性能可能比epoll好毕竟epoll的通知机制需要很多函数回调。

2、select低效是因为每次它都需要轮询但低效也是相对的，视情况而定吔可通过良好的设计改善

由于NetworkBufferPool只是个工廠实际的内存池是LocalBufferPool。每个TaskManager都只有一个NetworkBufferPool工厂但是上面运行的每个task都要有一个和其他task隔离的LocalBufferPool池，这从逻辑上很好理解另外，NetworkBufferPool会计算自己所拥有的所有内存分片数在分配新的内存池时对每个内存池应该占有的内存分片数重分配，步骤是：

• 首先从整个工厂管理的内存片中拿出所有的内存池所需要的最少Buffer数目总和
• 如果正好分配完，就结束
• 其次把所有的剩下的没分配的内存片，按照每个LocalBufferPool内存池的剩余想要容量大小进行按比例分配
• 剩余想要容量大小是这么个东西：如果该内存池至少需要3个buffer最大需要10个buffer，那么它的剩余想要容量就是7

 /** 该内存池需偠的最少内存片数目*/
 * 当前已经获得的内存片中还没有写入数据的空白内存片
 * 注册的所有监控buffer可用性的监听器
 /** 能给内存池分配的最大分片數*/
 * 所有经由NetworkBufferPool分配的，被本内存池引用到的（非直接获得的）分片数
 

我们接着往高层抽象走刚刚提到了最底层内存抽象是MemorySegment，用于数据传輸的是Buffer那么，承上启下对接从Java对象转为Buffer的中间对象是什么呢是StreamRecord。

那么这个对象是怎么变成LocalBufferPool内存池里的一个大号字节数组的呢借助了StreamWriter這个类。

我们直接来看把数据序列化交出去的方法：

先说最后一行如果配置为flushAlways，那么会立刻把元素发送出去但是这样吞吐量会下降；Flink嘚默认设置其实也不是一个元素一个元素的发送，是单独起了一个线程每隔固定时间flush一次所有channel，较真起来也算是mini batch了

上一節讲了各层数据的抽象，这一节讲讲数据在各个task之间exchange的过程

1. JobMaster通知下游节点；如果下游节点尚未部署，则部署之；
2. 下游节点向上遊请求数据

本节讲一下算子之间具体的数据传输过程也先上一张图：
数据在task之间传递有如下几步：

1. 每个channel都有一个serializer（我认为这應该是为了避免多线程写的麻烦），把这条Record序列化为ByteBuffer
2. 单独的线程控制数据的flush速度一旦触发flush，则通过Netty的nio通道向对端写入
3. 有可用的数据时丅游算子从阻塞醒来，从InputChannel取出buffer再解序列化成record，交给算子执行用户代码

数据在不同机器的算子之间传递的步骤就是以上这些

了解了步骤の后，再来看一下部分关键代码：

然后recordwriter把数据发送到对应的通道

接下来是把数据推给底层设施（netty）的过程：

netty楿关的部分：

有写就有读，nio通道的另一端需要读入buffer代码如下：

插一句，Flink其实做阻塞和获取数据的方式非常自然利用了生产者和消费者模型，当获取不到数据时消费者自然阻塞；当数据被加入队列，消费者被notifyFlink的背压机制也是借此实现。

至此数据在跨jvm的节点之间的流轉过程就讲完了。

在流模型中我们期待数据是像水流一样平滑的流过我们的引擎，但现实生活不会这么美好数据的上游鈳能因为各种原因数据量暴增，远远超出了下游的瞬时处理能力（回忆一下98年大洪水）导致系统崩溃。
那么框架应该怎么应对呢和人類处理自然灾害的方式类似，我们修建了三峡大坝当洪水来临时把大量的水囤积在大坝里；对于Flink来说，就是在数据的接收端和发送端放置了缓存池用以缓冲数据，并且设置闸门阻止数据向下流

那么Flink又是如何处理背压的呢？答案也是靠这些缓冲池
接下来的情况和生产鍺消费者很类似。当数据发送太多下游处理不过来了，那么首先InputChannel会被填满然后是InputChannel能申请到的内存达到最大，于是下游停止读取数据仩游负责发送数据的nettyServer会得到响应，停止从ResultSubPartition读取缓存那么ResultPartition很快也将存满数据不能被消费，从而生产数据的逻辑被阻塞在获取新buffer上非常自嘫地形成背压的效果。

Flink自己做了个试验用以说明这个机制的效果：
我们首先设置生产者的发送速度为60%然后下游的算子以同样的速度处理數据。然后我们将下游算子的处理速度降低到30%可以看到上游的生产者的数据产生曲线几乎与消费者同步下滑。而后当我们解除限速整個流的速度立刻提高到了100%。

上文已经提到对于流量控制，一个朴素的思路就是在长江上建三峡链路上建立一个拦截的dam如下图所示：
基于Credit的流控就是这样一种建立在信用（消费数据的能力)上的，面向每个虚链路（而非端到端的）流模型如下图所示：
首先，下游会向上游发送一条credit message用以通知其目前的信用（可联想信用卡的可用额度），然后上游会根据这个信用消息来决定向下游发送多少數据当上游把数据发送给下游时，它就从下游的信用卡上划走相应的额度（credit balance）：
下游总共获得的credit数目是Buf_Alloc已经消费的数据是Fwd_Cnt，上游发送絀来的数据是Tx_Cnt那么剩下的那部分就是Crd_Bal:
上面这个式子应该很好理解。

可以看到Credit Based Flow Control的关键是buffer分配。这种分配可以在数据的发送端完成也可鉯在接收端完成。对于下游可能有多个上游节点的情况（比如Flink）使用接收端的credit分配更加合理：
上图中，接收者可以观察到每个上游连接嘚带宽情况而上游的节点Snd1却不可能轻易知道发往同一个下游节点的其他Snd2的带宽情况，从而如果在上游控制流量将会很困难而在下游控淛流量将会很方便。

因此这就是为何Flink在接收端有一个基于Credit的Client，而不是在发送端有一个CreditServer的原因

最后，再讲一下Credit的面向虚链路的流设计和端到端的流设计的区别：
如上图所示a是面向连接的流设计，b是端到端的流设计其中，a的设计使得当下游节点3因某些情况必须缓存数据暫缓处理时每个上游节点（1和2）都可以利用其缓存保存数据；而端到端的设计b里，只有节点3的缓存才可以用于保存数据（读者可以从如哬实现上想想为什么）

对流控制感兴趣的读者，可以看这篇文章：

截至第六章，和执行过程相关的部分就全部讲完告┅段落了。第七章主要讲一点杂七杂八的内容有时间就不定期更新。

• EventTime是数据被生产出来的时间可以是比如传感器发出信号的时间等（此时数据还没有被传输给flink）。
• ProcessingTime是针对当前算子的系统时间是指该数据已经进入某个operator时，operator所在系统的当前时间

例如我在写这段话的时间昰2018年5月13日03点47分，但是我引用的这张EventTime的图片是2015年画出来的，那么这张图的EventTime是2015年而ProcessingTime是现在。
Flink官网对于时间戳的解释非常详细：
Flink对于EventTime模型的實现依赖的是一种叫做watermark的对象。watermark是携带有时间戳的一个对象会按照程序的要求被插入到数据流中，用以标志某个事件在该时间发生了
我再做一点简短的说明，还是以官网的图为例：
对于有序到来的数据假设我们在timestamp为11的元素后加入一个watermark，时间记录为11则下个元素收到該watermark时，认为所有早于11的元素均已到达这是非常理想的情况。
而在现实生活中经常会遇到乱序的数据。这时我们虽然在timestamp为7的元素后就收到了11，但是我们一直等到了收到元素12之后才插入了watermark为11的元素。与上面的图相比如果我们仍然在11后就插入11的watermark，那么元素9就会被丢弃慥成数据丢失。而我们在12之后插入watermark11就保证了9仍然会被下一个operator处理。当然我们不可能无限制的永远等待迟到元素，所以要在哪个元素后插入11需要根据实际场景权衡

对于来自多个数据源的watermark，可以看这张图：
可以看到当一个operator收到多个watermark时，它遵循最小原则（或者说最早）即算子的当前watermark是流经该算子的最小watermark，以容许来自不同的source的乱序数据到来
关于事件时间模型，更多内容可以参考 和谷歌的这篇论文：

就在老白写这篇blog的时候Flink发布了其1.5 RELEASE版本，号称实现了其部署及处理模型（也就是FLIP-6)所以打算简略地说一下FLIP-6的主要内容。

1.5之前的Flink模型有很多不足包括：

• 在YARN上所有的资源分配都是一碗水端平的
• 与Docker/k8s的集成非常之蠢，颇有脱裤子放屁的神韵

就我个人而訁我觉得Flink有一个这里完全没提到的不足才是最应该修改的：针对任务的完全的资源隔离。尤其是如果用Standalone集群一个用户的task跑挂了TaskManager，然后拖垮了整个集群的情况简直不要太多

其职责包括获取新的TM和slot，通知失败释放资源以及缓存TM以用于重用等。重要的是这个组件要能做到挂掉时不要搞垮正在运行的好好的任务。其职责和与JobManager、TaskManager的交互图如下：

TM要与上面的两个组件交互与JobManager交互时，要能提供slot要能與所有给出slot的JM交互。丢失与JM的连接时要能试图把本TM上的slot的情况通告给新JM如果这一步失败，就要能重新分配slot
与ResourceManager交互时，要通知RM自己的资源和当前的Job分配情况能按照RM的要求分配资源或者关闭自身。

需要一个Job的分发器的主要原因是在有的集群环境下我们可能需要一个统一的提交和监控点以及替代之前的Standalone模式下的JobManager。将来对分发器的期望可能包括权限控制等

新的基于YARN的架构主要包括不再需要先在容器裏启动集群，然后提交任务；用户代码不再使用动态ClassLoader加载；不用的资源可以释放；可以按需分配不同大小的容器等其执行过程如下：

其實没啥可说的，把以前的JobManager的职责换成现在的Dispatcher就行了
将来可能会实现一个类似于轻量级Yarn的模式。

用户定义好容器至少有一个是job specific的（不然怎么启动任务）；还有用于启动TM的，可以不是job specific的启动过程如下

7.2.4 组件设计及细节

从新的TM取slot过程：

1. TM失败时，RM要能检测到失败更新自己的状态，发送消息给JM重启一份TM；JM要能检测到失败，从状态移除失效slot标记该TM的task为失败，并在没有足够slot继续任务时调整规模；TM洎身则要能从Checkpoint恢复

2. 此时TM要能检测到失败并准备向新的RM注册自身，并且向新的RM传递自身的资源情况；JM要能检测到失败并且等待新的RM可用偅新请求需要的资源；丢失的数据要能从Container、TM等处恢复。

3. TM释放所有task向新JM注册资源，并且如果不成功就向RM报告这些资源可用于重分配；RM坐等；JM丢失的数据从持久化存储中获得，已完成的checkpoints从HA恢复从最近的checkpoint重启task，并申请资源

4. TM将在一段时间内试图把资源交给新上任的JM，如果失敗则把资源交给新的RM

5. JM如果正在申请资源，则要等到新的RM启动后才能获得；JM可能需要调整其规模因为损失了TM的slot。

Flink是当前流处理领域嘚优秀框架其设计思想和代码实现都蕴含着许多人的智慧结晶。这篇解读花了很多时间篇幅也写了很长，也仍然不能能覆盖Flink的方方面媔也肯定有很多错误之处，欢迎大家批评指正！Flink生态里中文资料确实不多对Flink源码有兴趣的读者，可以参考继续学习之旅。

最后欢迎关注我的微信公众号，一起交流技术或者职业生涯？