流程
Leader选举模式包括ZOOKEEPER、基于文件系统的、默认空实现以及自定义实现的,选举模式和持久化引擎是对应的。
持久化引擎 | Leader选举模式 |
---|---|
基于文件系统 | MonarchyLeaderAgent |
基于ZooKeeper | ZooKeeperLeaderElectionAgent |
空实现 | MonarchyLeaderAgent |
MonarchyLeaderAgent是服务启动的时候,就直接成为Leader节点,而ZooKeeperLeaderElectionAgent是基于ZooKeeper的Leader来选举的。
拉取数据
当成为Leader节点的时候,Master就会去持久化引擎里拉取ApplicationInfo、DriverInfo、WorkerInfo等信息(拉取的过程在持久化引擎里说过了),如果这些数据都是空的,就直接变成ALIVE状态,对外提供服务。
如果不是空的,那就需要把数据进行还原,这样原ALIVE节点的数据就不会丢失。
恢复Application
Master拿到ApplicationInfo数据后,就开始对Application进行注册,把Application的状态改为UNKNOWN,然后发消息给对应的Application,告知他Master地址已经变更,此消息将携带被选举为领导的Master和此Master的masterWebUiUrl属性。
Application接收到新的Master的通知,就断开了和旧的Master的连接,并指向新的master,然后发信息给Master说我已经知道了。
Master收到消息后,把Application的状态改为WAITING。
恢复Driver
遍历从持久化引擎中读取的DriverInfo,将每个DriverInfo添加到drivers缓存。
恢复Worker
Master拿到WorkerInfo数据后,就开始对Worker进行注册,把WorkerInfo的状态改为UNKNOWN,然后发消息给对应的Application,告知他Master地址已经变更,此消息将携带被选举为领导的Master和此Master的masterWebUiUrl属性。
Worker接收到新的Master的通知,把Master的相关信息进行了变更,然后发消息给Master,这个消息携带了Worker的ID、这个Worker里的Executor的信息列表。
Master收到消息后,对Worker和Executor的信息进行了恢复,并把WorkerInfo的状态改为ALIVE。
调度
Application和Worker恢复的时候,都会先把状态改为UNKNOWN。
等Application响应的时候,再把状态改为WAITING或者ALIVE。
此时如果状态为UNKNOWN的WorkerInfo或ApplicationInfo说明还没发消息给Master,Master不确定他们是否存活,所以在调度之前就需要移除他们。
对Application、Driver、Worker等信息进行恢复后,就开启了资源调度。资源调度之前已经讲过,这里就不再累述。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。