1 Standalone Cluster
Master-Slave架构，JobManager运行在Master节点，TaskManager运行在Slave节点，与HDFS/Hadoop无关
Active JobManager挂掉时，通过Zookeeper选举多个Standby JobManager成为Active JobManager来保证高可用
2 Yarn Cluster
2.1 Yarn Session模式:在YARN之上部署了Flink Session集群（可屏蔽底层不同的运行环境），向Yarn Session集群提交作业（不与YARN交互），多个作业共用集群资源（一个JobManager管理多个作业，作业越多则JobManager的负载越大），JobManager挂掉时会通过重启来保证高可用
2.2 Single Job模式:作业直接提交到YARN上（与YARN交互），一个作业对应一个JobManager，资源隔离，
3 Kubernetes Cluster :
----
Session模式
Session模式是预分配资源的，也就是提前根据指定的资源参数初始化一个Flink集群，并常驻在YARN系统中，拥有固定数量的JobManager和TaskManager（注意JobManager只有一个）。提交到这个集群的作业可以直接运行，免去每次分配资源的overhead。但是Session的资源总量有限，多个作业之间又不是隔离的，故可能会造成资源的争用；如果有一个TaskManager宕机，它上面承载着的所有作业也都会失败。另外，启动的作业越多，JobManager的负载也就越大。所以，Session模式一般用来部署那些对延迟非常敏感但运行时长较短的作业。
Per-Job模式
顾名思义，在Per-Job模式下，每个提交到YARN上的作业会各自形成单独的Flink集群，拥有专属的JobManager和TaskManager。可见，以Per-Job模式提交作业的启动延迟可能会较高，但是作业之间的资源完全隔离，一个作业的TaskManager失败不会影响其他作业的运行，JobManager的负载也是分散开来的，不存在单点问题。当作业运行完成，与它关联的集群也就被销毁，资源被释放。所以，Per-Job模式一般用来部署那些长时间运行的作业。
存在的问题
上文所述Session模式和Per-Job模式可以用如下的简图表示，其中红色、蓝色和绿色的图形代表不同的作业。
----
Session-Cluster模式
Session-Cluster模式需要先启动集群，然后再提交作业，接着会向yarn申请一块空间后，资源永远保持不变。如果资源满了，下一个作业就无法提交，只能等到yarn中的其中一个作业执行完成后，释放了资源，下个作业才会正常提交。所有作业共享Dispatcher和ResourceManager；共享资源；适合规模小执行时间短的作业。
Per-Job-Cluster模式
一个任务会对应一个Job，每提交一个作业会根据自身的情况，都会单独向yarn申请资源，直到作业执行完成，一个作业的失败与否并不会影响下一个作业的正常提交和运行。独享Dispatcher和ResourceManager，按需接受资源申请；适合规模大长时间运行的作业。
end