flink.4 Deployment Modes (调度模式)

这几天查了很多调度模式,大多说的不全面,趁着学习,正好记录一下.
.这篇文章着重讲解flink 程序的调度模式,关于jobmanager,taskmanager扽分其他知识,请读者自行查询,也许我后面的文章会讲解,但是这里只讲解flink的三种部署(调度)模式.

clent的概念

下图显示了Flink集群的构建块。flink程序的运行始于clien也就是你提交程序的代码。client获取Flink应用程序的代码，将其转换为JobGraph并提交给JobManager。
JobManager将工作分发到taskmanager，实际操作符(如源、转换和接收)在taskmanager中运行。
client的功能是一个很重要的概念.
程序始于client,客户端是提交程序的应用程序,负责一些资源的前期准备.

1:Application Mode

先说下另外零中模式的特点,另外两种模式，应用程序的main()方法都在客户端执行。这个过程包括在本地下载应用程序的依赖项，执行main()来提取Flink的运行时可以理解的应用程序的表示(即JobGraph)，并将依赖项和JobGraph发送到集群。这使得客户端成为一个沉重的资源消耗者，因为它可能需要大量的网络带宽来下载依赖项并将二进制文件发送到集群，并需要CPU周期来执行main()。当多个用户共用同一个client 机器的时候这个问题会更加明显.
鉴于此,Application Mode应运而生,Application Mode模式为每个提交的应用程序创建一个集群，但这一次，应用程序的main()方法在JobManager(不再是client客户端执行)上执行。为每个应用程序创建一个集群可以看作是创建一个仅在特定应用程序的作业之间共享的cluster，并在应用程序完成时将cluster拆除。在这种体系结构中，Application Mode模式提供了与Per-Job mode模式相同的资源隔离和负载平衡保证，但以整个应用程序的粒度为单位,意思是隔离的粒度没有Per-Job mode模式细腻.
在JobManager上执行main()可以节省所需的CPU周期，还可以节省本地下载依赖项所需的带宽。此外，为了下载集群中应用程序的依赖关系，它允许更均匀地分散网络负载，因为每个应用程序有一个JobManager,不同应用的JonManager可能在集群中的不同机器上,不像另外两种模式main都在提交任务的客户机上.
上面说的有点多,精简一下. flink的运行我简单分为三个阶段.
A:任务的提交,在这里提交任务的机器称为client,简单理 解为连接flink集群
B:main的运行,main运行会准备依赖资源
C:任务到jobMnager上,由于jobmanager负责分配执行.

Application Mode的好处就是,任务的提交,和main的运行不是一台机器,提交任务的机器不参与main任务执行,只是提交而已,真正的任main执行是在jobManager所在的机器上. 这种模式需要注意的点是,main运行需要的一些额外的配置文件不能放在客户机,因为main不在客户机运行,要放在jobManager所在的机器

与Per-Job模式相比，Application mode模式允许提交由多个作业(意思是在一个jar中多次调用execute提交任务)组成的应用程序。作业执行的顺序不受部署模式的影响，而是受用于启动作业的调用的影响。使用execute()是阻塞的，它会建立一个顺序，并导致“下一个”作业的执行被推迟到“这个”作业完成。使用executeAsync()，它是非阻塞的，将导致“下一个”任务在“这个”任务完成之前开始。
(注意:Application mode模式允许多执行()应用程序，但在这些情况下不支持高可用性。应用程序模式下的高可用性仅支持单执行()应用程序。
此外，当在应用程序模式(Application Mode)中运行的多个作业(例如使用executeAsync()提交)中的任何一个被取消时，所有作业将停止，JobManager将关闭。支持常规作业完成(通过关闭源)。 这里可以总结为,任务之间是阻塞或者非阻塞执行的,且不受影响,但是如果你取消其中一个另外的都会受影响. )

2:Per-Job Mode(单任务模式)

顾名思义,Per-Job Mode 是为了更细粒度的资源隔离,也就是说没调用一次executor,都会建立一个新的用于执行任务的集群,该集群仅对该作业可用。当作业完成时，集群被拆除，任何滞留的资源(文件等)都被清除.这提供了更好的资源隔离，因为一个行为不当的作业只能关闭它自己的taskmanager。此外，它将负载分散到多个jobmanager，因为每个作业有一个jobmanager。由于这些原因，Per-Job资源分配模型是许多生产环境的首选模式。 Per-Job Mode main运行在客户机上.

3:Session Mode

会话模式假设一个已经在运行的集群,并使用该集群的资源来执行任何提交的应用程序。在同一（会话）集群中执行的应用程序使用并因此竞争相同的资源。这样做的好处是您无需为每个提交的作业支付启动完整集群的资源开销。但是，如果其中一个作业行为不当或关闭了 TaskManager，那么在该 TaskManager 上运行的所有作业都将受到故障的影响。除了对导致失败的作业的负面影响之外，这还意味着潜在的大规模恢复过程，所有重新启动的作业同时访问文件系统并使其对其他服务不可用。此外，让单个集群运行多个作业意味着 JobManager 的负载更大. 也就是事先建立一个cluster,然后这个这个集群可以接受多个任务的提交,这些任务公用同样的资源.
另外,main的运行在客户机.

总结

在Session Mode中，集群的生命周期独立于集群上运行的任何作业的生命周期，并且资源在所有作业之间共享,任务结束flink集群也不会结束.
Per-Job Mode模式的代价是为每个提交的作业启动集群，但这带来了更好的隔离保证，因为资源不会跨作业共享。在这种情况下，集群的生命周期与作业的生命周期绑定在一起.作业结束,集群结束.
Application Mode模式为每个应用程序创建一个会话集群，并在集群上执行应用程序的main()方法。和Per-Job Mode 相比,Application Mode支持阻塞/非阻塞运行多个任务,并且任务之间相互隔离,但是不能随意取消一个任务,取消会影响别的任务. 另外,所有的任务都结束集群才会结束.