- 集群级别：cluster
- 节点级别：supervisor
- 进程级别：worker
- conf.setNumWorkers(3);设置topology有3个Worker。
线程级别：executor
- 在TopologyBuilder.setBolt(String id, IRichBolt bolt, Number parallelism_hint), 中的parallelism_hint决定启动多少个executor。
- @param parallelism_hint the number of tasks that should be assigned to execute this bolt. Each task will run on a thread in a process somewhere around the cluster.
对象级别：task, 最低级别的object,就是线程操作的一个个对象。
- 通过setNumTasks(3）设置task的个数，一般都是一个线程中一个task.
# 10秒之后开始调整
# Reconfigure the topology "mytopology" to use 5 worker processes,
# the spout "blue-spout" to use 3 executors and
# the bolt "yellow-bolt" to use 10 executors.
storm rebalance mytopology -w 10 -n 5 -e blue-spout=3 -e yellow-bolt=10
- 默认一个从节点上面可以启动4个worker进程，参数是supervisor.slots.port。在storm配置文件中已经配置过了，默认是在strom-core.jar包中的defaults.yaml中配置的有。
- 默认一个strom项目只使用一个worker进程，可以通过代码来设置使用多个worker进程。
- 通过config.setNumWorkers(workers)设置
- 通过conf.setNumAckers(0);可以取消acker任务
- 最好一台机器上的一个topology只使用一个worker,主要原因是减少了worker之间的数据传输
- 如果worker使用完的话再提交topology就不会执行，会处于等待状态
- 默认情况下一个executor运行一个task，可以通过在代码中设置
- builder.setSpout(id, spout, parallelism_hint);
- builder.setBolt(id, bolt, parallelism_hint);
- 通过boltDeclarer.setNumTasks(num);来设置实例的个数
- executor的数量会小于等于task的数量(为了rebalance)
worker之间通信是通过Netty进行通信的 • 1.executor执行spout.nextTuple()/bolt.execute(),emit tuple放入 executor transfer queue • 2.executor transfer thread把自己transfer queue里面的tuple放到 worker transfer queue • 3.worker transfer thread把transfer queue里面的tuple**序列化**发送到远程的worker • 4.worker receiver thread分别从网络收数据，反序列化成tuple放到对应的executor的receive queue • 5.executor receive thread从 自己的receive queue取出tuple ，调用bolt.execute()
- 无状态的，
- nimbus/supervisor/worker状态都存在ZK里面，少数worker信息 存在本地文件系统里面，还有nimbus把程序的JAR包也存在本地系统里面，它的好处是甚至nimbus挂掉之后呢，都可以快速的恢复，恢复呢就是知道重新 起一个然后去ZK里面读取相应的数据，因为这样所以storm非常的稳定，非常 的健壮，其实通过zk做了一个很好的解耦，任何模块挂了之后呢都还可以进行 很好的工作，也就是譬如说supervisor挂了，worker一样可以照常工作，因为 supervisor和worker之间没有直接的关系，都是通过zookeeper或本地文件进 行状态的传输的 。
- storm也是master/slave的架构，master是nimbus，slave是supervisor，单 中心的好处是，使得整个topology的调度变得非常的简单，因为只有一个中心的话，就是决定都有一个人来决定，不会出现仲裁的情况
- master这种也会有单中心的问题，就是单点失效的问题，当然这个问题也不是 很大，当没有新的topology发送上来的时候，运行在集群里面的topology不会有什么影响，当然极端的情况就是，这时候某个supervisor机器挂掉了，没 有nimbus了就不会做重新的调度，这样还是会有一定的影响。
- 另外一个单点的问题，就是单点性能的问题，因为现在topology的jar包呢还是通过nimbus来分发的，客户端提交还是先提交到nimbus，然后各个 supervisor去nimbus上面去下载，当文件比较大的时候，supervisor机器比 较多的时候呢，nimbus还是会成为瓶颈，网卡很快会被打满，当然为了解决 这个问题呢，storm也有一些办法，比如说把文件的分发变成P2P的。
因为真正干活的是executor和worker，nimbus/supervisor就起到一个控制 topology流程的作用，数据流程呢都在executor和worker里面来做，所有的 数据传输都是在worker之间完成的，不需要借助于nimbus和supervisor，特别是不需要借助于supervisor，这点设计上就是非常成功的，在hadoop中呢，TaskTracker存在，所有的shuffle都经过TaskTracker，所以呢，所有的 TaskTracker进程一旦挂了，它上面的map是要重新去执行的，因为没有人做 数据传输的服务，Storm就不一样，所有的数据传输都在worker间，即使 supervisor挂了呢，数据传输在worker之间，supervisor挂了之后呢，一点不会受影响，更不可思议的是，nimbus/supervisor全部挂掉了话，worker还能 正常工作，这个在hadoop中是不可想象的，所有的master/slave都挂了， task还能正常运行吗？？
Storm UIdeactive：未激活(暂停)
emitted: emitted tuple数
transferred: transferred tuple数, 与emitted的区别：
如果一个task，emitted一个tuple到2个task中，
则 transferred tuple数是emitted tuple数的两倍
complete latency: spout emitting 一个tuple到spout ack这个tuple的平均时间
process latency: bolt收到一个tuple到bolt ack这个tuple的平均时间
execute latency：bolt处理一个tuple的平均时间，不包含ack操作。
