美文网首页
[第五章]Master注册机制尝试剖析

[第五章]Master注册机制尝试剖析

作者: hoose | 来源:发表于2016-02-15 17:32 被阅读208次

    前面三章我们已经尝试剖析讲过SparkContext的基本的原理,其实涉及到了Driver对Master的注册,本节就关于Master注册机制进行更详细的剖析。

    我们知道Spark Standalone模式是一个主从架构,主节点就是Master,从节点是Worker(Salver),所以主节点是管理节点,类似Hadoop的Namenode,存在单点问题,这个在上一节已经详细分析了主备切换原理。 本节对Master注册包括Driver, Applicaiton,Worker

    一:Driver向 Master注册信息
    

    前几节讲过用spark-submit提交Application时,SparkContext初使化,首先Driver程序会向Master注册信息。

    1:把Driver信息加入Master节点的内存缓存区,其实这就是一个集合(HashMap)
    2:把Driver信息加入等待调度队列中(关于调度算法我们后面会深入分析),其实就是一个ArrayList,
    当然在Scala中是一个ArrayBuffer
    3:用持久化引挚(关于持久化引挚的具体类型我们在第四节介绍过)将Driver信息持久化
    4:调用scheduler()方法(这个一个Spark核心中的核心资源调度方法,
    后面我们会大量结合源代码一行一行分析)
    
    二:Application向 Master注册信息
    

    SparkContext初使化后会成生非常重要的两个TaskScheduler,DAGSchdeuler,其实TaskScheduler中的SparkDeplaySchedulerBackend对象对封装我们Application向Master注册

    1:把Application信息加入Master节点的内存缓存区,其实这就是一个集合(HashMap)
    2:把Application信息加入等待调度队列中(关于调度算法我们后面会深入分析),其实就是一个ArrayList,
    当然在Scala中是一个ArrayBuffer
    3:用持久化引挚将Application信息持久化
    4:调用scheduler()方法(这个一个Spark核心中的核心资源调度方法,
    后面我们会大量结合源代码一行一行分析)
    
    二:Worker向 Master信息,Worker在启动后主动向Master汇报注册
    
    1:将Workerk中的状态是DEAD的Worker过滤掉(什么情况下会是DEAD状态,
    前面我们已经详细剖析过,这里就不多介绍了),
    对于状态是UNKNOW的Worker,清除掉旧的Worker信息,替换新的Worker信息
    2:把Worker信息加入Master节点的内存缓存区,其实这就是一个集合(HashMap)
    3:用持久化引挚将Application信息持久化
    4:调用scheduler()方法(这个一个Spark核心中的核心资源调度方法,
    后面我们会大量结合源代码一行一行分析)
    

    相关文章

      网友评论

          本文标题:[第五章]Master注册机制尝试剖析

          本文链接:https://www.haomeiwen.com/subject/auspkttx.html