Storm启动流程分析

Storm启动流程分析

1、客户端运行storm nimbus时,会调用storm的python脚本,该脚本中为每个命令编写了一个方法,每个方法都可以生成一条相应的Java命令。

命令格式:java -server xxx.ClassName  -args

nimbus--->Running:/export/servers/jdk/bin/java  -server  backtype.storm.daemon.nimbus

supervisor--->Running:/export/servers/jdk/bin/java  -server  backtype.storm.daemon.supervisor

2、nimbus启动之后,接受客户端提交任务

命令格式:storm jar xxx.jar  xxx.驱动类  参数

Running:/export/servers/jdk/bin/java  -client  -Dstorm.jar=/export/servers/storm/examples/storm-master/storm-master-topologies-0.9.5.jar  org.apache.storm.starter.WordCountTopology  wordcount-2017-5-20

该命令会执行storm-starter-topologies-0.9.5.jar中的storm-starter-topologies-0.9.5.jar的main方法,main方法中会执行以下代码:

StormSubmitter.submitTopology("mywordcount",config,topologyBuilder.createTopology());

topologyBuilder.createTopology(),会将程序员编写的spout对象和bolt对象进行序列化。

会将用户的jar上传到nimbus物理节点的/export/data/storm/workdir/nimbus/inbox目录下。并且改名,改名的规则是添加了一个UUID字符串。

在nimbus物理节点的/export/data/storm/workdir/nimbus/stormdist目录下。有当前正在运行的topology的jar包和配置文件,序列化对象文件。

3、接收到任务之后,会将任务进行分配,分配会产生一个assignment对象,该对象会保存到Zookeeper中,目录是/storm/assignments,该目录只保存正在运行的topology任务。



Storm启动流程分析

时间: 2024-12-28 01:49:57

Storm启动流程分析的相关文章

u-boot启动流程分析(2)_板级(board)部分

转自:http://www.wowotech.net/u-boot/boot_flow_2.html 目录: 1. 前言 2. Generic Board 3. _main 4. global data介绍以及背后的思考 5. 前置的板级初始化操作 6. u-boot的relocation 7. 后置的板级初始化操作 1. 前言 书接上文(u-boot启动流程分析(1)_平台相关部分),本文介绍u-boot启动流程中和具体版型(board)有关的部分,也即board_init_f/board_i

Cocos2d-x3.3RC0的Android编译Activity启动流程分析

本文将从引擎源代码Jni分析Cocos2d-x3.3RC0的Android Activity的启动流程,以下是具体分析. 1.引擎源代码Jni.部分Java层和C++层代码分析 watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveXV4aWt1b18x/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" > watermark/2/text/aHR0cDov

u-boot启动流程分析(1)_平台相关部分

转自:http://www.wowotech.net/u-boot/boot_flow_1.html 1. 前言 本文将结合u-boot的“board—>machine—>arch—>cpu”框架,介绍u-boot中平台相关部分的启动流程.并通过对启动流程的简单分析,掌握u-boot移植的基本方法. 注1:本文所使用的u-boot版本,是2016/4/23从u-boot官网(git://git.denx.de/u-boot.git)导入的一个快照,具体可参考“https://github

ubuntu upstart启动流程分析

ubuntu自从6.10版本之后就使用了较新的upstart机制来进行系统的初始化. upstart是一种基于事件驱动的服务启动机制,可以使多个系统任务在保持依赖关系的前提下并发启动(据说这样这样启动会比较快,理论上应当如此).使用upstart机制时,我们通过/etc/init下的一系列 *.conf 配置文件来指定各种系统服务的依赖关系(启动时机).系统启动时,upstart主进程/sbin/init会解析这些配置文件,按照指定的依赖关系并发启动各种服务与应用. 主要程序 upstart有三

Android -- Audio Native服务之启动流程分析(一)

Android -- Audio Native服务之启动流程分析(一) Android中的Audio系统是比较庞大.繁杂的一部分内容, 其中会涉及较多的音频编解码.多媒体制式与Android Audio HAL设备管理的知识.随着Android的发展,其所支持的音频设备也变得越来丰富,如扬声器.耳机.听筒等等:这种变化也为Android管理如此丰富的音频设备以及如何正确.合理地切换音频输出提出了更高的要求.面对如此繁杂的管理要求,我们分析Android Audio服务的历程想必也不会轻松.接下来

YARN Container 启动流程分析

YARN Container 启动流程分析 本文档从代码出发,分析了 YARN 中 Container 启动的整个过程,希望给出这个过程的一个整体的概念. 文档分为两个部分:第一部分是全局,从头至尾地把 Container 启动的整个流程串联起来:第二部分是细节,简要分析了 Container 启动流程中涉及到的服务.接口和类. 注意: 基于 hadoop-2.6.0 的代码 只写了与 Container 启动相关的逻辑,并且还大量忽略了很多细节,目的是为了得到一个整体的概念. 为了让分析更具体

STB 参考Linux启动流程分析

STB启动流程 1. uboot启动(Fastboot启动) 硬件资源检测(如CPU,DDR Size,Nand  flash,mem size,flash size) print Version(如HW Version,Boot Version,Loader Version) boot设置模型的选择(autoboot or stop) 2. Starting kernel 各种接口驱动的启动() Creating 10 MTD partitions on “hinand” 网卡驱动,USB驱动

Android5 Zygote 与 SystemServer 启动流程分析

Android5 Zygote 与 SystemServer 启动流程分析 Android5 Zygote 与 SystemServer 启动流程分析 前言 zygote 进程 解析 zygoterc 启动 SystemServer 执行 ZygoteInitrunSelectLoop SystemServer 启动过程 Zygote 的 fork 本地方法分析 forkSystemServer ZygoteHookspreFork 创建 system_server 进程 ZygoteHooks

Floodlight 启动流程分析

1. 在Main中先是加载模块,启动REST服务,而后构建一个实现了IFloodlightProviderService接口的实例(即Controller)并运行: 2. 接下来进入Controller的run()方法,此时所有的环境初始化工作已经完成,构建一个基于netty的TCP server,最重要的是流水线factory OpenflowPipelineFactory 的设置,里面是controller上流,下流处理的handler(具体细节见===).当Channel建立,接收到来自O