Giraph源码分析(四)—— Master 如何检查Worker启动成功
本文的目的
说明Giraph如何借助ZooKeeper来实现Master与Workers间的同步(不太确定)。
环境
在单机上(机器名:giraphx)启动了2个workers。
Giraph遵从单Master多Workers结构,BSPServiceMaster使用MasterThread线程来进行全局的同步。每个Worker启动成功后,会向Master汇报自身的健康状况,那么Master是如何检测Workers是否都成功启动了?
Master在ZooKeeper上创两个目录,_workerHealthyDir和 _workerUnhealthyDir,分别用来记录Healthy Workers和UnHealthy Workers。
主要在BspServiceMaster类中的getAllWorkerInfos()方法来完成,其调用关系如下,注意下getAllWorkerInfos()到MasterThread.run()方法调用关系,比较难找。
创建的两个目录如下:
/_hadoopBsp/job_201404102333_0002/_applicationAttemptsDir/0/_superstepDir/-1/_workerHealthyDir /_hadoopBsp/job_201404102333_0002/_applicationAttemptsDir/0/_superstepDir/-1/_workerUnhealthyDir
每个Worker在setup()中,调用registerHealth()方法来注册自身的状态。
若自身是Healthy的,则在_workerHealthyDir目录下添加子节点 /wokerInfo.getHostNameId(),否则在_workerUnhealthyDir目录下添加。wokerInfo.getHostNameId()为:Hostname+“_”+TaskId。 Task1和Task2 (Task 0是master) 创建的子节点如下:
/_hadoopBsp/job_201404102333_0002/_applicationAttemptsDir/0/_superstepDir/-1/_workerHealthyDir/giraphx_1 /_hadoopBsp/job_201404102333_0002/_applicationAttemptsDir/0/_superstepDir/-1/_workerHealthyDir/giraphx_2
Master 在checkWorkers()方法中,在While死循环中(实际有超时限制),通过调用getAllWorkerInfos()方法来获取_workerHealthyDir目录下的子节点,然后比较子节点数目是否达到maxWorkers(启动job时定义的,-w参数)。
若小于maxWorkers,则继续调用getAllWorkerInfos()方法进行下一轮检测;若等于maxWorker,退出While循环,然后返回healthyWorkersInfoList:[Worker(hostname=giraphx, MRtaskID=1, port=30001), Worker(hostname=giraphx, MRtaskID=2, port=30002)] 。
问题:由于在分布式环境中,每个Worker和Maste都是并行运行,彼此不知道对方的运行情况。上述第3步骤中,若还有子节点还没有创建,就一直在while死循环中调用来检测getAllWorkerInfos()方法检测,效率比较低下,当然也比较笨!
Giraph借用ZooKeeper来高效的进行检测。设计理念如下:
master在获取子节点时,注册Watcher(为注册器,用于触发相应事件)。
若某个task创建了子节点后,就会触发Watcher事件。
若子节点数目小于maxWorkers,就调用 workerHealthRegistrationChanged的await()方法释放当前线程的锁,陷入等待状态。不会进行无用的检测。
说明:workerHealthRegistrationChanged为PredicateLock类型(implements BspEvent接口),PredicateLock里面使用可重入锁 ReentrantLock和Condition进行线程的控制。
当某个task创建了子节点后,触发Watcher事件。
调用BspService中的public final void Process(WatchedEvent event)事件,该方法根据事件的路径来激活相应的BspEvent事件。此处对应的是:
实验运行如下:
s(926)) - process: Got a new event, path = /_hadoopBsp/job_201404102333_0002/_applicationAttemptsDir/0/_superstepDir/-1/_workerHealthyDir, type = NodeChildrenChanged, state = SyncConnected INFO bsp.BspService (BspService.java:process(960)) - process: workerHealthRegistrationChanged (worker health reported - healthy/unhealthy )
这样就会激活master线程,开始下一轮检测。
子节点数目等于maxWorkers时,就停止。
总结:每创建一个子节点时,才会进行一次检测,效率较高!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
LinkedHashMap代码详解(一)
HashMap 在遍历map时,数据是无序的,在某些需要按照put顺序遍历时,就用到了LinkedHashMap,LinkedHashMap是HashMap的子类,并且用一条双向链表来存储数据插入的顺序 transient LinkedHashMap.Entry<K,V> head; //链表的头节点 transient LinkedHashMap.Entry<K,V> tail; //链表的尾节点 final boolean accessOrder; //是否开启lru算法(最活跃的点放在链表头部) put(): 由于LinkedHashMap没有put方法,put操作用的还是HashMap的方法,但是重写了newNode(int hash, K key, V value, Node e) ,afterNodeAccess(Node e),afterNodeInsertion(boolean evict)方法1 table中不存在相同的key if ((p = tab[i = (n - 1) & hash]) == null) tab[i] = new...
- 下一篇
2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题
背景 业务上一个新业务上线,发现CPU使用率较高,我们的业务特点一般是IO密集型,所以一般呈现CPU使用率较低,但是QPS较高的特点,所以对这个特殊的服务进行性能分析,以下是分析过程。 网络性能分析 新应用上线,发现CPU较高,如图所示 从cpu使用率的细节发现%si中断使用率集中在cpu0上,查看中断类型 发现硬中断的处理集中在CPU0上,推断网卡不支持多队列特性 果然推断正确,然后决定找两台网卡支持多队列的机器对比性能 从监控中可以看到,两种机型在P999的接口响应延迟上相差一倍 CPU使用率还没分析 跑题了,前面分析CPU的过程中无意间发现了中断不平均的问题,但并不是我们CPU使用率高的原因,CPU主要还是%us高,回来分析CPU使用率,由于代码不是本人所写,不会直接去分析代码,那样无异于大海捞针,拿出珍藏的perf大法,生成火焰图分析。 CPU火焰图的生成方法参考前面的文章: 使用FlameGraph分析JAVA应用性能 Docker中使用FlameGraph分析JVM应用性能 生成的火焰图如下: http://oss.zrbcool.top/picgo/ad-data-web...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- CentOS7设置SWAP分区,小内存服务器的救世主
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Hadoop3单机部署,实现最简伪集群
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7安装Docker,走上虚拟化容器引擎之路