本文章：重点是分析清楚运行架构以及并行度与slot的分配

1、JobManager和TaskManager

Flink中的节点可以分为JobManager和TaskManager。

JobManager处理器也称为Master，用于协调分布式任务执行。他们用来调度task进行具体的任务。TaskManager处理器也称为Worker，用于实际执行任务。

一个有效的Flink集群中可以包含多个JobManager组成高可用集群，也可以有多个TaskManager进行并行计算。他们可以直接在物理机上启动，也可以通过像Yarn这样的资源调度框架启动。

每一个处理器都是一个单独的JVM进程，也可以通过配置的方式管理他们占用的内存资源。在flink-conf.yaml配置文件中，可以通过jobmanager.memory.process.size属性配置jobmanager占用的内存大小，taskmanager.memory.process.size属性配置每个taskmanager占用的内存大小。这个内存大小包含了JVM占用的堆内存以及堆外的元数据区和堆外直接内存的大小。这些参数也可以在提交任务的时候进行干预。

而JobManager在接收到任务时，整体执行的流程会是这样。

客户端会往JobManager提交任务，JobManager会往ResouceManager申请资源，当资源足够时，再将任务分配给集群中的TaskManager去执行。

只不过在Standalone模式下，这个ResourceManager是由Flink自己担任的。而在Yarn模式下，则是转为由Yarn来担任ResourceManager角色。

2、并发度与Slots

每一个TaskManager是一个独立的JVM进程，他可以在独立的线程上执行一个或多个任务task。为了控制一个taskManager能接收多少个task，TaskManager上就会划分出多个slot来进行控制。 每个slot表示的是TaskManager上拥有资源的一个固定大小的子集。flink-conf.yaml配置文件中的taskmanager.numberOfTaskSlots属性就配置了配个taskManager上有多少个
slot。默认值是1，所以我们之前搭建的集群，有3个taskManager，集群内总共就只有3个slot。这些slot之间的内存管理也就是数据是相互隔离的。而这些slot其实都是在同一个JVM进程中，所以这里的隔离并不涉及到CPU等其他资源的隔离。

Task Slot是一个静态的概念，代表的是TaskManager具有的并发执行能力。另外还有一个概念并行度parallelism就是一个动态的概念，表示的是运行程序时实际需要使用的并发能力。这个是可以在flink程序中进行控制的。如果集群提供的slot资源不够，那程序就无法正常执行下去，会表现为任务阻塞或者超时异常。

程序运行时的parallelism管理有三个地方可以配置，优先级最低的是在flinkconf.yaml文件中的parallelism.default这个属性，默认值是1。优先级较高的是在提交任务时可以指定任务整体的并行度要求。这个并行度可以在提交任务的管理页
面和命令行中添加。 优先级最高的是在程序中指定的并行度。在flink的应用程序中，几乎每一个分布式操作都可以定制单独的并行度。这到底是是怎么回事呢？那现在我们就开发一个简单的flink应用了解一下。

3、开发环境搭建

flink提供了java和scala两套客户端API，我们这里采用java进行演示。

首先创建一个maven工程，在pom.xml文件中，引入客户端的依赖

<dependency><groupId>org.apache.flink</groupId><artifactId>flink-java</artifactId><version>1.12.5</version></dependency><dependency><groupId>org.apache.flink</groupId><artifactId>flink-clients_2.12</artifactId><version>1.12.5</version></dependency><dependency><groupId>org.apache.flink</groupId><artifactId>flink-streaming-java_2.12</artifactId><version>1.12.5</version></dependency>

后面这个依赖中最后的2.12表示是对应的scala版本。

然后就可以开发一个简单的flink应用程序。

package com.roy.flink.streaming;import org.apache.flink.api.common.functions.FlatMapFunction;import org.apache.flink.api.common.serialization.SerializationSchema;import org.apache.flink.api.common.serialization.SimpleStringSchema;import org.apache.flink.api.java.tuple.Tuple2;import org.apache.flink.api.java.utils.ParameterTool;import org.apache.flink.streaming.api.datastream.DataStream;import org.apache.flink.streaming.api.datastream.DataStreamSource;import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;import org.apache.flink.util.Collector;import java.nio.charset.StandardCharsets;public class SocketWordCount {public static void main(String[] args) throws Exception {final StreamExecutionEnvironment environment = StreamExecutionEnvironment.getExecutionEnvironment();final ParameterTool parameterTool = ParameterTool.fromArgs(args);String host = parameterTool.get("host");final int port = parameterTool.getInt("port");final DataStreamSource<String> inputDataStream = environment.socketTextStream(host, port);final DataStream<Tuple2<String, Integer>> wordcounts = inputDataStream.flatMap(new FlatMapFunction<String, Tuple2<String, Integer>>() {public void flatMap(String value, Collector<Tuple2<String, Integer>> out) throws Exception {final String[] words = value.split(" ");for (String word : words) {out.collect(new Tuple2<String, Integer>(word, 1));}}}).setParallelism(2).keyBy(value -> value.f0).sum(1).setParallelism(3);wordcounts.print();wordcounts.writeToSocket(host,port,new SerializationSchema<Tuple2<String, Integer>>(){@Overridepublic byte[] serialize(Tuple2<String, Integer> element) {return (element.f0+"-"+element.f1).getBytes(StandardCharsets.UTF_8);}});environment.execute("stream word count");}}

这个程序的作用就是连接一个socket服务端，读取socketStream文本流，然后进行最为经典的WordCount操作。

首先，执行这个测试程序需要有一个socket服务端。 我们可以在找1台Linux机器centos7使用nc指令模拟一个。 nc -lk 7777 在本地7777端口建立一个socket服务端。

然后，在本地的IDEA运行配置页面，指令要连接的host和port。

配置完成后，就可以在本地直接运行这个示例了。这也就是Flink所谓的LOCAL模式。

这个执行结果就是最终的wordcount结果。 但是，这里面有个有趣的现象。对hello的次数统计，是从1，一步一步统计到3的，而不是一次性统计到3。其实这也体现了流失计算的特点。这些词其实是一个一个统计的。

然后要注意一下我们代码中进行了多次setParallelism操作。在这个演示过程中，暂时没有体现出什么作用。在后续的演示中会有用。

4、提交到集群执行

这种本地执行的方式显然不具备生产使用的要求。我们可以使用maven进行编译，将这个代码编译成一个jar包，FlinkDemo-1.0.jar。

参考，我的这篇文章打包jar：SpringBoot打jar
参考，我的这篇文章搭建Flink集群：Flink集群搭建

访问控制台，打开 Submit New Job页面，选择 +Add New 按钮，提交jar包。


单独提供一个jar包还并不足以启动任务，因为启动任务还需要指定任务的入口。选择这个FlinkDemo-1.0.jar，继续配置一个任务。

在这里注意下，提交任务时可以指定这个应用整体的Parallism 并行度。

点击提交，就可以开启一个任务。在running job页面就可以看到正在执行的任务stream word count。选择这个任务，就能看到任务的执行情况。

这个数据流图展示了整个这个应用的具体执行的步骤。这些步骤整体就构成了数据流图。下面的数据流量会统计每个步骤经过的数据流量。在centos7机器上的nc服务中敲入字符，这个数据流量与记录数就会不断增加。

最后应用中通过print打印出来的消息会输入到应用的标准输出控制台。控制台的内容可以在TaskManagers菜单中查看。

5、并行度分析

这里我们重点分析每个蓝色方块下面的Parallelism参数。这里列出了每个步骤所占用的slot数量。而这里统计出来的slot数量就是按照之前所说的优先级确定的。整体优先级是这样。

程序中指定 > 提交任务时指定 > flink-conf.yaml中指定。

然后，我们回到Overview页面，查看下整体的slot情况。

接下来可以看到，我们这个job总共需要8个slot，但是集群中只有3个slot，程序也正常执行起来了。这也体现了slot复用的效果。也就是说slot可以在不同的执行步骤中处理不同的任务。只要集群资源能够支撑应用最大的并行度要求，整个应用就可以运行起来。实际上，Flink对于这个数据流图还会有一些自己的优化，例如某些相邻的操作，他们的并行度相同，任务也不是很复杂时，flink会将这些相邻的步骤进行合并。

这些slot在同一个任务内部是可以不断复用的，但是在不同的任务之间，是不能共用的。所以，这时可以看到，集群中仅有的3个slot已经全部被这个stream wordcount应用给占满了，如果需要再启动应用，就无法执行了。这时jobmanager会不断的尝试重新申请slot，如果集群中有空出来的slot，那就可以分配给应用。如果一直申请不下来，jobmanager会不断重试，默认每重试10次就会休息一点时间，过后再继续申请。如果在attached模式下，在客户端可以很清晰的看到这个过程。

6、Flink整体运行流程

然后我们再回头来看Flink官方提供的集群结构图就比较清晰了。

客户端
对于Flink，可以通过执行一个Java/Scala程序，或者通过./bin/flink run … 指令启动一个客户端。客户端将把sataflow提交给JobManager。客户端的主要作用其实就是构建好一个Dataflow graph或者也称为JobGraph，然后提交给客户端。而这个JobGraph如果在客户端本地构建，这就是Per-job模式，如果是提交到JobManager由Flink集群来构建，这就是Application模式。然后将提交完成后，客户端可以选择立即结束，这就是detached模式。也可以选择继续执行，来不断跟踪JobManager反馈的任务执行情况，这就是默认的attached模式。

JobManager
JobManager会首先接收到客户端提交的应用程序。这个应用程序整体会包含几个部分：作业图JobGraph，数据流图logic dataflow graph以及打包了所有类库以及资源的jar包。这些资源都将分发给所有的TaskManager去真正执行任务。

JobGraph相当于是一个设计图，之前Yarn的Per-job模式，往集群提交的就是这个JobGraph。JobManger会把JobGraph转换成一个物理层面的数据流图，这个图被叫做执行图 ExecutionGraph，这其中包含了所有可以并发执行的任务，相当于是一个执行计划。接下来JobGraph会向资源管理器 例如Yarn的ResourceManager请求执行任务必要的资源，这些资源会表现为TaskManager上的slot插槽。一旦获得了足够多的资源，就会将执行图分发到真正运行任务的TaskManager上。而在运
行过程中，JobManager还会负责所有需要中央协调的操作，例如反馈任务执行结果，协调检查点备份，协调故障恢复等。

JobManager整体上由三个功能模块组成：

  • ResourceManager
    ResourceManager在Flink集群中负责申请、提供和注销集群资源，并且管理task slots。Flink中提供了非常多的ResourceManager实现，比如Yarn，Mesos，K8s和standalone模式。在standalone模式下，ResourceManager只负责在TaskManager之间协调slot的分配，而TaskManager的启动只能由TaskManager自己管理。

  • Dispatcher
    Dispatcher模块提供了一系列的REST接口来提交任务，Flink的控制台也是由这个模块来提供。并且对于每一个执行的任务，Dispatcher会启动一个新的JobMaster，来对任务进行协调。

  • JobMaster
    一个JobMaster负责管理一个单独的JobGraph。Flink集群中，同一时间可以运行多个任务，每个任务都由一个对应的JobMaster来管理。一个集群中最少有一个JobManager。而在高可用部署时，也可以有多个JobManager。这些JobManager会选举出一个作为Leader。而其他的节点就出于StandBy备用的状态。

TaskManager
TaskManager也成为Worker。每个TaskManager上可以有一个或多个Slot。这些Slot就是程序运行的最小单元。 在flink.conf.yaml文件中通过taskmanager.numberOfTaskSlots属性进行配置。

每一个TaskManager就是一个独立的JVM进程，而每个Slot就会以这个进程中的一个线程执行。这些Slot在同一个任务中是共享的，一个Slot就足以贯穿应用的整个处理流程。Flink集群只需要关注一个任务内的最大并行数，提供足够的slot即可，
而不用关注整个任务需要多少Slot。