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，按需接受資源申請；適合規模大長時間執行的作業。
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，按需接受資源申請；適合規模大長時間執行的作業。