Master的注册机制和状态改变管理解密

本课主题

Master 接收 Worker, Driver, Application 注册
Master 处理 Driver 狀态变换
Master 处理 Executor 狀态变换

Master 接受 Driver, Worker, Application 注册內幕

可以把 Master 想像成公司里的总经理，Driver 就是客户，Worker 是每个项目的技术领导，Executor 是实际干活的工程师，在实际情况下，他们三个会相互沟通，总经理一般都不会直接跟工程师沟通。但客户、技术领导和工程师一般都会进行沟通。

用这个例子，你就可以理解在 Spark 的世界中Master、Driver、Worker 三者会进行沟通，Executor、Driver、Worker 三者也会进行沟通，而 Master 不会直接向 Excecutor 进行沟通。

[下图是 Master 接收 Worker, Driver, Application 的流程图]

Master 對其他组件注册的处理

Master 接受注册的对象主要是 Driver, Application 和 Worker, 需要补充说明的是 Executor 不会注册给 Master，Executor 是注册给 Driver 中的 SchedulerBackend 的；
Worker 是在启动之后主动向Master 注册的，这样设计有一个很大的好处，就是在生产环境下如果想把新的Worker 加入到已经运行的Spark 集群上，此时不需要重新启动Spark 集群就能够使用新加入的Worker 以提升处理能力；Worker 启动后会调用onStart( ) 方法，然后调用 registerWithMaster( ) 来注册给Master。
[下图是 Worker.scala 中的 onStart 方法]

这里 registerWithMaster( ) 首先会调用 tryRegisterAllMasters( )
[下图是 Worker.scala 中的 registerWithMaster 方法]

[下图是 Worker.scala 中的 tryRegisterAllMasters 方法]

这里发送一个 RegisterWorker 的 case class 去 masterEndpoint
[下图是 Worker.scala 中的 registerWithMaster 有一个参数的重载方法]

在 RegisterWorker 这个数据结构中具体会有 id、host、port、workerEndPoint、cores、memory、webUiPort、publicAddress 等信息。它会首先判断一下 host 是不是空值和 port 必须是大于 0
[下图是 DeployMessage.scala 中 RegisterWorker 的 case class]
Master 接到 Worker 注册的请求后，首先会判断一下当前的 Master 是否是 Standby 的模式，如果是的话就不处理，然后会判断当前 Master 内存的数据结构 idToWorker 中是否已经有该 Worker 的注册信息，如果有的话此时并不会重覆注册；
通过持久化引擎例如 ZooKeeper 把注册信息持久化起来
Master 如果决定接收注册的Worker，首先会创建 WorkerInfo 对象来保存注册的 Worker 的信息：然后调用 registerWorker 来执行具体的注册的过程，如果 Worker 状态是 DEAD 的状态则直接过滤掉，对于 UNKNOWN 状态的内容会调用 removeWorker 方法来进行清理（包括清理该工人下的 Executors 和驱动程序。
注册的时候会先注册 Driver 然后再注册 Application