三种部署模式

Session Mode

会话模式是先启动一个集群，然后再向这个集群提交应用，所有应用在同一个集群中，共享资源。这样的好处是节省了为每个应用启动完整集群的资源开销，提交到这个集群的应用可以直接运行。但是，当某个Job由于某些 bug 对某个TaksManager 有不良影响或 导致 TaskManager 宕机 ,那么在这个TaskManager 上的所有应用都会受到影响。这种情况下除了导致作业失败外还意味着另外有大规模的恢复过程，期间所有重启的服务都会不可用。另外同时运行的应用越多则 JobManager 的负载越大。

Per-Job Mode

我猜可能是 Personal JobManager ，因为它为每个提交的应用都单独启动一个独立的集群，拥有专属的JobManager 和 TaskManager。应用之间资源是完全隔离的。一个应用完成作业后，与这个应用关联的集群也就会被销毁，释放资源。由于良好的资源隔离，所以一个应用的失败，不会影响其他应用的运行.另外JobManager的负载也是分散的，没有集中到一个上。所以 Per-Job 是许多生产环境首选。

Application Mode

在上面的两种模式中，应用程序的 main()方法是在客户端执行。处理包括

• 获取应用的依赖
• 提取出 flink 运行时可以理解的表现形式(即 JobGraph)
• 将依赖和 JobGraph(s)传到集群中

这些工作完成后才会真正的运行程序。较大的依赖会消耗更多的带宽，而较复杂的作业逻辑转换成JobGraph也需要消耗更多的CPU和内存 。如果所有用户都共享这个客户端时问题尤为突出。

为了解决上述问题，社区实现了 Application Mode模式。

在 Application Mode模式中，还是为每个提交的应用创建一个独立的集群，但是这次，应用程序的main()方法是在JobManager上执行了。在这个模式下，具备了与 Per-Job模式相同的资源隔离和负载均衡，还节省了CPU 和 网络带宽。