Flink的部署模式

大家好我是栗子鑫，今天主要想给大家介绍一下在面对不同的运行环境和任务需求的时候应该以哪种方式部署我们的Flink程序，希望对大家有所帮助，正文如下：

部署模式主要按照程序的生命周期和资源隔离来划分：

1.生命周期：是指整个程序的Runtime是否随着job的结束而结束。

2.资源隔离：多个任务共享一个JobManger还是每一个任务有自己特有的JobManger

其实这两个条件可以理解为程序的主函数的main方法是在本地的client上面执行还是在jobManger上面执行：

1.在本地client执行：由client来生成的jobgraph，并且上传到jobManger上。

2.在jobManger上面:application mode 整个程序的main函数在集群上运行，代码资源也放在集群里。

—

会话模式标题内容1

第一部分的正文内容从这里开始。

会话模式是为最常规的模式，在会话模式中整个Flink的集群中只有一个JobManer(JM)，所有的任务都是先由对应的客户端进行解析生成JobGraph，然后将所需要的Jar一并打包，提交到了JM上。可以理解为JM一直在运行中，任务提交后开始执行，具体示意图如下（本博客所有的来源:资源管理器支持和高可用^[1]）

会话模式的运行特点：

所有的JobManger 和 taskManger 共享
JobManger的生命周期不受提交的Job影响，会一直运行。
JobGraph 需要在客户端生成然后提交到JM上

会话模式的优缺点：

优点：

JM和所有的TM都是共享的，所以资源会重复利用。
Job 的管理是在 session 集群之中的，运维相对来说不是在resource management，所以更简单一些

缺点：所有的资源共享，资源的隔离相对差一些。

—

Per-Job模式

Per-Job模式顾名思义就是针对每一个Job都会临时创建一个JM，然后启动对于的TM和生成对应的运行图。具体模式如下：

Per-Jon模式的运行特点

单个Job独有JobManger 和 taskManger 。
TM中的slot数量等资源由Job决定。
JobGraph 需要在客户端生成然后提交到JM上。
TM的生命周期和Job的生命周期一样。

Per-Jon模式的优缺点：

优点：

每个任务都有自己JM和TM，所以隔离行比较好。
隔离行好，那么对于每个 job 的灵活度就更高，比如其中的 taskManager 之中的 slot 个数就可以随着 job 本身来进行定义。

缺点：

JobManager 本身也需要消耗资源，为每一个 job 单独启动一个 JobManager，会存在资源浪费。
彼此隔离，各个资源的调度就只能将管理交给 Cluster Management。管理难。

—

应用模式

会话模式和 per-job 模式下面，都是先将对应的 jar 在 client 进行解析，然后提交到 JobManager 上面。生成 JobGraph 的过程很消耗 CPU 资源，而且在多个 JAR 进行排队提交的时候，有可能会造成阻塞。在Aplication mode 下面，客户端只是负责命令和接收结果，从解析过程开始之后就是放在 JM 上面运行。可以自己去指定划分 application，每一个 application 之中都有很多 job。dependency jar 可以由 jobManager 上传到文件系统上如HDFS上，运行模式如下：