-主備切換機制剖析

前面幾章，我們講了spark通常有三種提交模式

1、獨立部署模式standalone，spark自身有一套完整的資源管理方式
2、架構(gòu)于hadoop之上的spark集群
3、架構(gòu)于mesos之上的spark集群

本節(jié)主要是講解在standalone上對Master主備切換原理進(jìn)行深入的剖析。
Master實際上可以配置兩個，那么在spark原生的standalone上也是支持Master主備切換的，也就是說，當(dāng)Active Master節(jié)點掛掉之后，我們可以將Standby Master切換為Active Master

Spark Master的主備切換可以基于兩種切換機制，一種是文件系統(tǒng)，一種是基于Zookeeper,基于文件系統(tǒng)的機制，是Active Master掛掉后，需要我們手動去切換到Standby Master上，基于Zookeeper機制，呆以實現(xiàn)自動切換。

所以這里說的主備切換機制，其實指的是在Active Master掛掉之后，切換到Standby Master時，Master會做哪些操作

1.使用持久化引摯(FileSystemPersistence或者是ZookeeperPersisitence)去讀取持久化的
storedApps,
storedDriver,
storedWorker,

2.判斷上面的三個持久化的
storedApps,
storedDriver,
storedWorker,
有任何一個不為空，就將持久化有Application,Driver,Worker
的信息重新注冊，注冊到Master內(nèi)部的緩存結(jié)構(gòu)中。

3.將Application和Worker的狀態(tài)都修改為UNKNOWN,
然后向Application對應(yīng)的Driver，Worker發(fā)送Standby Master的地址

4.Driver,Worker,理論上講，如果他們目前是正常工作的話，
那么在收到Master發(fā)送來的地址后，就會返回響應(yīng)給新的Master。

5.此時，Master在陸續(xù)接收到Driver,Worker發(fā)送來的響應(yīng)消息之后，
會使用completeRecovery()對沒有收到發(fā)送響應(yīng)消息的
Driver,Worker進(jìn)行處理，過濾掉他們的信息。如下：

// Kill off any workers and apps that didn't respond to us.
    workers.filter(_.state == WorkerState.UNKNOWN).foreach(removeWorker)
    apps.filter(_.state == ApplicationState.UNKNOWN).foreach(finishApplication)

    // Reschedule drivers which were not claimed by any workers
    drivers.filter(_.worker.isEmpty).foreach { d =>
      logWarning(s"Driver ${d.id} was not found after master recovery")
      if (d.desc.supervise) {
        logWarning(s"Re-launching ${d.id}")
        relaunchDriver(d)
      } else {
        removeDriver(d.id, DriverState.ERROR, None)
        logWarning(s"Did not re-launch ${d.id} because it was not supervised")
      }

6.調(diào)用Master的schedule()，對正在等待調(diào)度的Driver,Application
進(jìn)行調(diào)度，比如在某個Worker上啟動Driver,或者為Application在Worker上啟動Executor。

 state = RecoveryState.ALIVE
    schedule()