欢迎转载，转载请注明出版，徽沪一郎。
本文重点分析storm的worker进程在正常启动之后有哪些类型的线程，针对每种类型的线程，剖析其用途及消息的接收与发送流程。
概述
worker进程启动过程中最重要的两个函数是mk-worker和worker-data，代码就不一一列出了。worker顺利启动之后会拥有如下图所示的各类线程。
接收和发送线程
worker在启动的时候会生成进程级别的消息接收和消息发送线程，它们视具体配置而定，可以是基于zmq，也可以基于netty,这个没有太多好说的。socket connection的建立过程可以在tuple消息传递一文中找到说明。
zk client
worker需要定期的向zk server发送心跳消息，与zk server之间的连接处理就落到zk client这个线程身上了。具体代码见函数do-heartbeat及do-executor-heartbeats。
定时器线程
worker进程需要定期的做些事情，比如发送心跳消息，刷新socket连接，这些定时器归为如下几类，每类定时器运行在各自的线程。
- :heartbeat-timer worker
- :refresh-connections-timer worker
- :refresh-active-timer worker
- :executor-heartbeat-timer worker
- :user-timer worker
上述定时器分类见于worker的shutdown函数,有时候在分析代码的时候，如果从入口看不清楚的话，不妨试试从退出的处理逻辑哪里找找答案。
SystemBolt
在topology提交的时候曾经见过函数system-topology!，这个函数会创建SystemBolt，每个worker内有且只有一个SystemBolt,可以见SystemBolt.java中注释的说明或参考github上storm对该改变的说明，。
SystemBolt主要进行进程相关的统计功能，比如内存使用情况，网络包的吞吐量，具体可见SystemBolt.java。SystemBolt是不接收tuple，只有出度，没有入度。
Metrics Bolt线程
MetricsBolt主要也是处理统计工作，与systembolt不同的是，metricsbolt主要处理executor级别的，如果用户在配置文件中定义了相关的MetricsConsumer类，那么这些类会在此被执行。
与之相关的配置内容，
## Metrics Consumers# topology.metrics.consumer.register:# - class: "backtype.storm.metrics.LoggingMetricsConsumer"# parallelism.hint: 1# - class: "org.mycompany.MyMetricsConsumer"# parallelism.hint: 1# argument:# - endpoint: "metrics-collector.mycompany.org"
Shared Executor
这个是在storm 0.8中引入的，其用途可在0.8的release notes中找到，创建共享线程池，具体用途没太搞清楚，:).
Metrics的执行流程
metrics所做的计量工作是在什么时候被唤醒的呢，也就是说如何一步步的触发直到MetricsConsumeBolt的execute函数被调用。
下图勾勒出与metrics相关的线程间的消息传递过程。
简要说明如下
- worker在启动的时候，会往:user-timer中注册metrics timer（见setup-metrics!函数).
- 一旦metrics timer超时，会发送一个stream-id为metrics-tick-stream-id的tuple到非metrics类型的bolt,如user/acker/system bolt.
- 接收到tuple之后，会调用metrics-tick函数发送task-data给MetricsConsumerBolt, stream-id为metrics-stream-id
- MetricsConsumerBolt接收到stream-id为metrics-stream-id的tuple后，会执行execute
注：在worker内部还有另一套计量api,定义于builtin-metrics.clj中，与MetricsConsumerBolt的区别在于，builtin-metrics是在处理外部进程发送过来的tuple时进行计量统计，而MetricsConsumerBolt是定时触发。