【源码分析】storm拓扑运行全流程源码分析

@(STORM)[storm]

一、拓扑提交流程

拓扑提交的总体流程如下：
1、客户端通过thrift RPC提交topology的配置及jar包到nimbus。
2、nimbus针对该topology建立本地目录。
3、nimbus调度器根据topology的配置计算task，并把task分配到不同的worker上，调度的结果写入zookeeper。
4、zk上建立assignment节点，存储task和supervisor中的worker的对应关系。同时在zk上创建workerbeats节点来监控worker的心跳。
5、supervisor去zk上获取分配的task信息，启动一个或者多个worker来执行。
6、每个worker上运行一个或多个executor，每个executor对应一个线程，worker内部的executor之间通过DisrupterQueue进行通信，不同worker间默认采用netty来通信。
7、executor运行一个或者多个task（spout/bolt）
到此，topology就正式运行起来了。

具体流程图如下：（参考自《storm技术内幕与大数据实践》P96）

本文介绍了通过调用storm jar如何向nimbus提交拓扑的过程，即上述的第一步，主要的工作是加载配置信息，classpath，并将其与用户的jar包通过thrift协调上传至nimbus，等待nimbus的调用。

(一)storm.py

在这部分，请尤其注意classpath的设置。
依次将下列内容加入classpath中：

\$STORM_HOME \$STORM_HOME/lib \$STORM_HOME/extlib 用户代码的jar包  ~/.storm  \$STORM_HOME/bin

详见下面的分析。

1、storm jar

用户可以通过storm jar命令向storm集群提交一个拓扑，如：

/home/hadoop/storm/bin/storm jar storm-starter-topologies-0.9.4.jar storm.starter.WordCountTopology word-count

其实，storm执行的是bin/目录下的storm.py文件

2、def jar

jar函数只有一行，就是执行exec_storm_class函数。

def jar(jarfile, klass, *args):    exec_storm_class(    klass,    jvmtype="-client",    extrajars=[jarfile, USER_CONF_DIR, STORM_BIN_DIR],    args=args,    daemon=False,    jvmopts=JAR_JVM_OPTS + ["-Dstorm.jar=" + jarfile])

其中的几个变量为：

USER_CONF_DIR = os.path.expanduser("~" + os.sep + ".storm")STORM_BIN_DIR = os.path.join(STORM_DIR, "bin")

因此用户jar包，~/.storm及$STORM_HOME/bin目录下的jar包会被自动加载到classpath中。

3、exec_storm_class

def exec_storm_class(klass, jvmtype="-server", jvmopts=[], extrajars=[], args=[], fork=False, daemon=True, daemonName=""):    global CONFFILE    storm_log_dir = confvalue("storm.log.dir",[CLUSTER_CONF_DIR])    if(storm_log_dir == None or storm_log_dir == "nil"):        storm_log_dir = os.path.join(STORM_DIR, "logs")    all_args = [        JAVA_CMD, jvmtype,        "-Ddaemon.name=" + daemonName,        get_config_opts(),        "-Dstorm.home=" + STORM_DIR,        "-Dstorm.log.dir=" + storm_log_dir,        "-Djava.library.path=" + confvalue("java.library.path", extrajars, daemon),        "-Dstorm.conf.file=" + CONFFILE,        "-cp", get_classpath(extrajars, daemon),    ] + jvmopts + [klass] + list(args)    print("Running: " + " ".join(all_args))    if fork:        os.spawnvp(os.P_WAIT, JAVA_CMD, all_args)    elif is_windows():        # handling whitespaces in JAVA_CMD        sub.call(all_args)    else:        os.execvp(JAVA_CMD, all_args)

可以看出，最后就是运行一条java命令，主类是用户main函数的类。
看一下classpath的设置。

4、get_classpath

def get_classpath(extrajars, daemon=True):    ret = get_jars_full(STORM_DIR)    ret.extend(get_jars_full(STORM_DIR + "/lib"))    ret.extend(get_jars_full(STORM_DIR + "/extlib"))    if daemon:        ret.extend(get_jars_full(STORM_DIR + "/extlib-daemon"))    if STORM_EXT_CLASSPATH != None:        for path in STORM_EXT_CLASSPATH.split(os.pathsep):            ret.extend(get_jars_full(path))    if daemon and STORM_EXT_CLASSPATH_DAEMON != None:        for path in STORM_EXT_CLASSPATH_DAEMON.split(os.pathsep):            ret.extend(get_jars_full(path))    ret.extend(extrajars)    return normclasspath(os.pathsep.join(ret))

依次将下列内容加入classpath中：

"-Dstorm.jar=" + jarfile    \$STORM_HOME \$STORM_HOME/lib \$STORM_HOME/extlib 用户代码的jar包  ~/.storm  \$STORM_HOME/bin

（二）拓扑提交之一

1、用户代码调用submitTopology

用户一般通过StormSubmitter.submitTopology提交拓扑

if (args != null && args.length > 0) {      conf.setNumWorkers(3);      StormSubmitter.submitTopologyWithProgressBar(args[0], conf, builder.createTopology());    }

这里使用了submitTopologyWithProgressBar，只是在submitTopology的基础上增加了一些进度信息，见下面代码。

2、StormSubmitter.submitTopologyWithProgressBar

public static void submitTopologyWithProgressBar(String name, Map stormConf, StormTopology topology, SubmitOptions opts) throws AlreadyAliveException, InvalidTopologyException, AuthorizationException {        // show a progress bar so we know we're not stuck (especially on slow connections)        submitTopology(name, stormConf, topology, opts, new StormSubmitter.ProgressListener() {            @Override            public void onStart(String srcFile, String targetFile, long totalBytes) {                System.out.printf("Start uploading file '%s' to '%s' (%d bytes)\n", srcFile, targetFile, totalBytes);            }            @Override            public void onProgress(String srcFile, String targetFile, long bytesUploaded, long totalBytes) {                int length = 50;                int p = (int)((length * bytesUploaded) / totalBytes);                String progress = StringUtils.repeat("=", p);                String todo = StringUtils.repeat(" ", length - p);                System.out.printf("\r[%s%s] %d / %d", progress, todo, bytesUploaded, totalBytes);            }            @Override            public void onCompleted(String srcFile, String targetFile, long totalBytes) {                System.out.printf("\nFile '%s' uploaded to '%s' (%d bytes)\n", srcFile, targetFile, totalBytes);            }        });    }

本质上就是调用submitTopology方法，同时在start, progress和complete阶段输出一些信息。

3、StormSubmitter.submitTopology

@SuppressWarnings("unchecked")public static void submitTopology(String name, Map stormConf, StormTopology topology, SubmitOptions opts,         ProgressListener progressListener) throws AlreadyAliveException, InvalidTopologyException, AuthorizationException {    submitTopologyAs(name, stormConf, topology, opts, progressListener, null);}

StormSubmitter.submitTopology其实就是调用StormSubmitter.submitTopologyAs。下面我们详细分析一下StormSubmitter.submitTopologyAs

（二）提交拓扑之二：StormSubmitter.submitTopologyAs

1、加载配置

在submitTopologyAs中，第一件事就是将拓扑的配置加载到一个HashMap中

   if(!Utils.isValidConf(stormConf)) {        throw new IllegalArgumentException("Storm conf is not valid. Must be json-serializable");    }    stormConf = new HashMap(stormConf);    stormConf.putAll(Utils.readCommandLineOpts());    Map conf = Utils.readStormConfig();    conf.putAll(stormConf);    stormConf.putAll(prepareZookeeperAuthentication(conf));

上述代码完成了以下功能：
（1）检查拓扑传进来的conf是否有效，是否能json化，然后将其转换为HashMap。这里的conf是用户在建立拓扑时通过以下类似代码传进来的：

    Config config = new Config();    config.put(Config.TOPOLOGY_TRIDENT_BATCH_EMIT_INTERVAL_MILLIS, 200);    config.setNumWorkers(topoNumWorker);    config.setMaxTaskParallelism(20);    config.put(Config.NIMBUS_HOST, nimbusHost);    config.put(Config.NIMBUS_THRIFT_PORT, 6627);    config.put(Config.STORM_ZOOKEEPER_PORT, 2181);    config.put(Config.STORM_ZOOKEEPER_SERVERS, Arrays.asList(zk));    config.put(Config.TOPOLOGY_NAME, topologyName);

（2）将命令行中的参数加载进stormConf中
（3）调用readStormConfig，加载配置文件中的内容：

public static Map readStormConfig() {    Map ret = readDefaultConfig();    String confFile = System.getProperty("storm.conf.file");    Map storm;    if (confFile==null || confFile.equals("")) {        storm = findAndReadConfigFile("storm.yaml", false);    } else {        storm = findAndReadConfigFile(confFile, true);    }    ret.putAll(storm);    ret.putAll(readCommandLineOpts());    return ret;}

先加载defaults.yaml, 然后再加载storm.yaml

（4）最后，加载zk认证相关信息。
（5）除此之外，还可以组件中覆盖getComponentConfiguration方法以修改其组件的配置。
（6）最后，还可以使用spoutDeclare与boltDeclare设置外部组件。

注意，这里有conf和stormConf2个变量，conf才是全部的配置，stormConf不包括defaults.yaml和storm.yaml。先将用户配置加载到stormConf，然后将defaults.yaml和storm.yaml回到conf，最后将stormConf加载到conf.

2、使用NimbusClient提交拓扑

当配置准备好以后，就开始向nimbus提交拓扑。在storm中，nimbus是一个thrift服务器，它接受客户端通过json文件提交RPC调用，即NimbusClient向nimbus提供一份json格式的字符串，用于提交拓扑信息。

            String serConf = JSONValue.toJSONString(stormConf);            NimbusClient client = NimbusClient.getConfiguredClientAs(conf, asUser);            if(topologyNameExists(conf, name, asUser)) {                throw new RuntimeException("Topology with name `" + name + "` already exists on cluster");            }            String jar = submitJarAs(conf, System.getProperty("storm.jar"), progressListener, asUser);            try {                LOG.info("Submitting topology " +  name + " in distributed mode with conf " + serConf);                if(opts!=null) {                    client.getClient().submitTopologyWithOpts(name, jar, serConf, topology, opts);                } else {                    // this is for backwards compatibility                    client.getClient().submitTopology(name, jar, serConf, topology);                }            } catch(InvalidTopologyException e) {                LOG.warn("Topology submission exception: "+e.get_msg());                throw e;            } catch(AlreadyAliveException e) {                LOG.warn("Topology already alive exception", e);                throw e;            } finally {                client.close();            }

核心步骤包括：
（1）将配置文件改为json格式的string

String serConf = JSONValue.toJSONString(stormConf);

（2）获取Nimbus client对象

NimbusClient client = NimbusClient.getConfiguredClientAs(conf, asUser);

getConfiguredClientAs的代码中的其中一行是指定nimbus的地址：

String nimbusHost = (String) conf.get(Config.NIMBUS_HOST);

（3）检查拓扑名称是否已经存在

    if(topologyNameExists(conf, name, asUser)) {                        throw new RuntimeException("Topology with name `" + name + "` already exists on cluster");                    }

（4）将jar包上传至nimbus

String jar = submitJarAs(conf, System.getProperty("storm.jar"), progressListener, asUser);

（5）最后调用submitTopologyWithOpts正式向nimbus提交拓扑，参数包括：

client.getClient().submitTopologyWithOpts(name, jar, serConf, topology, opts);

submitTopologyWithOpts方法就只有2行：

  send_submitTopologyWithOpts(name, uploadedJarLocation, jsonConf, topology, options);  recv_submitTopologyWithOpts();

即将信息发送至thrift server及接收返回信息。发送的信息包括：

  args.set_name(name);  args.set_uploadedJarLocation(uploadedJarLocation);  args.set_jsonConf(jsonConf);  args.set_topology(topology);  args.set_options(options);

其中set_uploadedJarLocation指定了jar包的上传路径。

综上所述，其实所谓的提交拓扑，就是将拓扑的配置信息通过thrift发送到thrift server，并把jar包上传到nimbus，等待nimbus的后续处理，此时拓扑并未真正起来，直至recv_submitTopologyWithOpts获得成功的返回信息为止。

二、 拓扑运行流程

（一）概述

拓扑数据流如下：
1、Spout读取或者产生数据
2、通过netty/ZMQ将数据从所在的worker发送到下一个Executor所在的worker（如果下一个Executor与spout的executor在同一个worker，则直接发送到自身worker内部的Disruptor Queue）
3、worker根据TaskId将消息放入Executor的输入Disruptor Queue中
4、Executor处理完数据后，将其放到自身的输出Disruptor Queue中
5、然后Executor还会启动一个线程将输出Disruptor Queue中的内容通过netty发送到其它worker中，或者直接发送至其它Executor相对应的输入Disruptor Queue（源executor与目标executor在同一个worker的情况）。
6、如此循环3～5步骤，直至所有executor都处理完成数据。

executor的执行方式是一个典型的生产者消费者模式