Storm-源码分析-Topology Submit-Task

mk-task, 比较简单, 因为task只是概念上的结构, 不象其他worker, executor都需要创建进程或线程 

所以其核心其实就是mk-task-data, 

1. 创建topologycontext对象, 其实就是把之前的topology对象和worker-data混合到一起, 便于task在执行时可以取到需要的topology信息. 

2. 创建task-object, spout-object或bolt-object, 封装相应的逻辑, 如nexttuple, execute 

3. 生成tasks-fn, 名字起的不好,让人误解执行了task的功能, 其实就是做些emit之间的准备工作, 其中最重要的就是调用grouper去产生targets task, 当然还包含些metrics, hooks的调用.

说白了其实mk-tasks, 没做啥事

<a href="http://www.cnblogs.com/fxjwind/p/3217352.html">storm-源码分析-topology submit-task-topologycontext</a>

:system-context, :user-context, 只是context中的topology对象不同, system为system-topology!

这里的builtin-metrics用来记录spout或bolt的执行状况的metrics

<a href="http://www.cnblogs.com/fxjwind/p/3225057.html">storm-源码分析- metric</a>

返回tasks-fn, 这个函数主要用于做emit之前的准备工作, 返回target tasks list 

1. 调用grouper, 产生target tasks 

2. 执行emit hook 

3. 满足sampler条件时, 更新stats和buildin-metrics

task-fn, 两种不同参数版本

[^string stream ^list values], 这个版本好理解些, 就是将stream对应的component的target tasks都算上(一个stream可能有多个out component, 一份数据需要发到多个bolt处理)

[^integer out-task-id ^string stream ^list values], 指定out-task-id, 即direct grouping 

这里对out-task-id做了验证 

out-task-id (if grouping out-task-id), 即out-task-id-&gt;component-&gt;grouper不为nil(为:direct?), 即验证这个stream确实有到该out-task-id对应component 

如果验证失败, 将out-task-id置nil

取出component的对象, 

比如对于spout, 取出spoutspec中的componentobject spout_object, 包含了spout的逻辑, 比如nexttuple()