安装部署方式Local 模式1.1 架构图1.2 原理图Standalone 模式1. 架构图2. 原理图Standalone HA 模式1. 架构图Yarn 模式原理图为什么使用Flink on yarn？Yarn 三种模式1. Application Mode 模式（推荐）2. Session Mode 任务模式3. Per-job Cluster Mode 单任务模式（推荐）
安装部署方式
- Local：不单独部署运行环境,在代码中直接调试。后续一些简单的代码样例就会以Local方式调试。
- Standalone：独立运行环境。这种模式下,Flink将自己完全管理运行资源。这种方式,其实资源利用率是比较低的。
- Standalone HA：独立集群高可用模式，Flink自带集群，开发测试及生产环境使用。
注意：此处有个坑，Standalone模式的HA必须依赖于共享存储文件系统，因为要保证JobManager的元数据信息对所有节点共享，由high-availability.storageDir参数指定JobManager存储位置。如果指定本地目录，即使启动2个JobManager也不会实现高可用，因为元数据信息不能共享。可选代替方案，使用NFS挂载远程机器JobManager信息存储目录。也可以使用HDFS。
- Yarn：以Hadoop提供的Yarn作为资源管理服务。计算资源统一由hadoop yarn管理，生产环境使用。这样可以更高效的使用集群的机器资源。
Local 模式
所有进程process运行在一台机器上，针对Flink框架来说，进程分为jobManager（主节点，管理者）和TaskManager(从节点，干活)
1.1 架构图
1.2 原理图
- Flink程序有JobClient进行提交
- jobClinet将作业提交给JobManager
- jobManager负责协调资源分配和作业执行。资源分配完成后，任务将提交给响应的TaskManager
- TaskManager启动一个线程以开始执行。TaskManager会向jobManager报告状态更改，如何开始执行，正在进行或者已完成。
- 作业执行完成后结果将发送回客户端（jobClient）
Standalone 模式
管理集群资源和分配资源给Flink 应用运行任务Task
1. 架构图
- JobManager是单节点的
2. 原理图
- client客户端提交任务给jobmanager
- jobmanager 负责申请任务运行所需要资源并管理任务和资源
- jobmanager分发任务给TaskManager执行
- TaskManager定期向jobManager汇报状态
Standalone HA 模式
1. 架构图
- JobManager是多节点的
- Standalone 模式，会有单节点故障问题的产生，所以我们也可以在standAlone模式下，借助于Zookeeper，将我们的JobManager实现成为高可用的模式。
Yarn 模式
原理图
为什么使用Flink on yarn？
- yarn的资源可以按照需使用，提高集群的资源利用率
- yarn的任务有优先级，根据优先级运行作业
- 基于yarn调度系统，能自动化的处理各个角色的failover（容错）
当flink on yarn运行时，特点：
- jobmanager进程和TaskManager进程都由yarn nodemanager监控
- 如果jobmanager进程异常退出，则yarn resurcemanager会从新调用jobmanager到其他机器；
- 如果taskmanager进程异常退出，jobmanager会收到消息并重新向yarn resourcemanager申请资源，重新启动taskmanager
Yarn 三种模式
1. Application Mode 模式（推荐）
应用模式将在任务的启动时l临时在yarn上申请一个flink集群。任务从main方法启动开始就会提交到yarn上的flink集群执行。执行完成后,集群就会立即注销。
- 应用场景：短期任务
2. Session Mode 任务模式
特点：需要事先申请资源，启动jobmanager和taskmanager
优点：不需要每次申请资源，而是使用已经申请好的资源，从而提高执行效率
缺点：作业执行完成以后，资源不会被释放，一直会占用系统资源
应用场景：适合作业提交比较频繁的场景，小作业比较多的场景
这种模式跟应用模式很类似,也会给每个应用在yarn上申请一个单独的flink集群。只不过这种模式下,任务是先在本地执行,构建数据处理链。构建完成后再将任务提交到flink集群上执行。
3. Per-job Cluster Mode 单任务模式（推荐）
特点：每次提交作业都需要申请一次资源
优点：作业运行完成，资源会立刻被释放，不会一直占用系统资源
缺点：每次提交作业都需要申请资源，会影响执行效率，因为申请资源需要耗费时间
应该场景：适合作业比较少的场景、大作业的场景
- 应用场景：长期任务
只有在这些都完成之后，才会通过env.execute()方法触发Flink运行时真正地开始执行作业。如果所有用户都在Deployer上提交作业，较大的依赖会消耗更多的带宽，而较复杂的作业逻辑翻译成JobGraph也需要吃掉更多的CPU和内存，客户端的资源反而会成为瓶颈。不管Session还是Per-Job模式都存在此问题。为了解决，社区在传统部署模式的基础上实现了Application模式。
可见，原本需要客户端做的三件事被转移到了JobManager里，也就是说main()方法在集群中执行（入口点位于ApplicationClusterEntryPoint），Deployer只需要负责发起部署请求了。另外如果一个main()方法中有多个env.execute/executeAsync()调用，在Application模式下，这些作业会被视为同一个应用，在同一个集群中执行（如果在Per-Job模式下，就会启动多个集群）。可见，Application模式本质上是Session和Per-Job模式的折衷。