下面是0.8.0之前的表述，之后的已经基于Disruptor改造过了
这个文章演示了发射和转移tuple是怎么在storm中工作的
- Worker为消息传递负责
- 当zk中的任务出现了变化或者每个task.refresh.poll.secs都会调用refresh-connections。这个东西管理和其他的worker的连接，并且维护一个映射：task->worker
- 提供一个transfer函数，被tasks用来发送tuples给其他的tasks。这个转移函数传入参数是task id和一个tuple，它会序列化一个tuple并且把它放入一个transfer queue。每一个worker只有一个队列。
- 序列化是线程安全的。
- worker使用单线程从队列中取出消息发送给其他的worker。
- 消息发送遵循一定的协议
- 分布式的实现是使用ZeroMQ
- 本地模式的实现是使用内存的java queues
- tasks接收消息的实现在本地模式和分布式模式是不一样的
- 在本地模式，tuple直接被发送到内存队列中
- 在分布式模式中，每一个worker监听一个唯一的tcp端口，等待传入信息，然后路由这些信息从内存到tasks，这些tcp端口称为virtual port,因为它接收[task id,message]，然后路由它到真实的task中。
- tasks监听内存ZeroMQ端口等待从虚拟端口来的消息
- tasks为消息路由负责。一个tuple要么被发送到一个direct stream(这个task id被声明了)，要么去一个regular流。在direct流中，只有bolt订阅了direct stream的时候消息才发送。在regular stream中，流分组函数被使用来决定tuple发送给哪个task id。
- tasks有一个路由对应：{stream id}->{commponent id}->{stream grouping function}
- 无论是direct还是regular，task-fn都返回要发送tuple的task id
- 获取输出的task id之后，bolts和spouts使用worker提供的transfer-fn完成实际的传递tuple的工作
Storm Metrics
测量storm
Storm暴露了一个测量接口来报告整个拓扑的统计信息，它在内部使用去追踪在Nimbus UI中看到的数据：excutes和acks的数量，每个bolt的平均处理延时，worker堆的使用，等等
Metrics Types
Metrics只实现一个方法，getValueAndRest:做所有的剩余的工作去找到统计信息，并且重置到一个初始状态。例如MapReducer用running total除以running count得到了mean，然后初始化两者的值到0.
Storm提供给你下面的Metrics方法
- AssignableMetric:设置metric为你提供的精确的数值。如果是个外面的值就很方便了，或者在你自己计算出统计信息的情况下。
- CombinedMetric:是测量的通用接口可以同步升级。
- CountMetric:给定值的running total。调用inrc()函数加1，incrBy(n)增加到指定的数值
- MultiCountMetric:CountMetric的hashmap
- ReducedMetric
- MeanReducer:跟踪运行时平均值交给自己的reduce()方法
- MultiMeanReducer:MeanReducer的hashmap