這篇主要是組件的職責和功能
- 每個JobManager負責一個Job，在提交JobGraph時創(chuàng)建，在job完成后銷毀
- JobManager同樣可以通過savepoint創(chuàng)建
ResourceManager
根據(jù)不同的集群調度框架提供不同實現(xiàn)（YARN，Mesos）
主要任務
- 處理資源請求（申請新的TaskManager）：在請求到來的時候可以啟動新的container或者直接分配給job
- 異常檢測：如果JobManager或者TaskManager掛了，需要做相應處理，通知相關組件
- 緩存TaskManager，以便重用。在TaskManager（container）一段時間未使用時自動釋放
根據(jù)不同實現(xiàn)方式可以選擇讓ResourceManager感知到 task slot。（增加一個map變量即可實現(xiàn)）
ResourceManager 是在多個Job運行期間一直存活的
RecourceManager如果掛了不能影響當前執(zhí)行的job，運行的job可以繼續(xù)使用已經(jīng)分配的資源執(zhí)行，但是在RM掛了期間不能申請新的資源。
-
RM的不應該依靠保存運行時狀態(tài)來實現(xiàn)容錯
RM可以通過詢問JM，TM來重新獲取信息。（RM自身重新獲取container,JM,TM的重新注冊）
特殊情況下可能仍然需要保存一些與cluster-manager相關的狀態(tài)。
JM向RM注冊自己，這樣便可以獲得TM的信息。如果JM被分配的資源所在的TM掛了，會收到相關信息。
如果slot足夠的話2,3步驟省略
TaskManager
同時和RM，JM進行信息交互。同時需要心跳信息來檢測異常
與RM的交互
- TM啟動的時候會在RM注冊自己。RM斷開連接時會重連，并重新注冊自己，上報自身的slot資源信息
- 每次心跳時，TM也會發(fā)送自己的slot資源的可用狀態(tài)。而且TM和JM直接鏈接并發(fā)送資源信息，這樣RM就會及時的感知到資源的變化。
- TM這邊看到的資源使用狀態(tài)是最正確的信息（自己的哪個slot被分配給了哪個JM）。通過這個信息RM可以得到資源的使用狀態(tài)
- RM會告訴TM，TM的哪個slot被分配給了哪個JM。之后TM會把slot分配給JM。如果分配失敗會告訴RM對應的slot實際是不可用的（注：RM那邊的信息可能是錯誤的，所以才會發(fā)送這個信息給TM，TM這邊的信息才是資源使用的真是情況，參考上一條）
- RM會向TM發(fā)送shutdown信息
與JM的交互
- TM會根據(jù)JM的要求來分配slot給JM，在JM的Job完成之前這個slot都是屬于JM的，完成后JM會釋放slot
- TM會保存自己的slot分配信息（分配給了哪個JM），JM失連則會觸發(fā)TM自身的master掛了的恢復邏輯
- JM可以部署任務到JM被分配的slot中
- JM失連，TM會嘗試分配給slot給JM（如果JM有HA，則新的JM還是負責這個Job）。如果一段時間之內都注冊失敗，則所有分配給這個JM的slot都變?yōu)榭煞峙錉顟B(tài)。當之前Job的JM恢復后，他需要重新從RM申請slot
JM的slot pool
JM有一個資源池記錄TM提供的slot資源
JM的調度器從slot pool中獲取slot來調度任務，這樣即使RM掛了JM也可以不失去分配的資源
InstanceManager是當前slot pool的一個實現(xiàn)
SlotPool在無法滿足[資源申請]的時候會嘗試從RM中獲取資源，如果RM掛了或者RM不能提供資源或者請求超時，則[資源申請]失敗
SlotPool可以返還資源給RM，如果應用已經(jīng)使用了最大資源后slotpool還有剩余
Dispatcher
Dispatcher 接受client的job提交，并在cluster manager上創(chuàng)建啟動job
[圖片上傳失敗...(image-fc02df-1552733550212)]這個設計是因為
- 有的cluster manager需要一個集中式（觸發(fā) job 啟動）和（監(jiān)控job）的模塊
- 可以作為一個常駐實例來等待任務提交
容錯
核心容錯機制是任務重啟，并從checkpoint中恢復狀態(tài)
YARN
with dispatcher
容錯方面：
RM和JM運行在AM進程中，異常檢測和進程重啟由YARN執(zhí)行
JobGraph和庫，會保存在AM的工作目錄中，YARN會將他們保存在私有的HDFS目錄中
