在jstorm中，工作者的行为就像风暴中的执行者。一个worker可以有多个任务，但与storm不同的是，worker中的任务可能属于不同的组件，举个例子：
一个拓扑包含一个喷口（s）、两个螺栓（b1、b2），调用时设置每个组件的任务号 TopologyBuilder.buildTopology 方法，特别是 TopologyBuilder.setBolt 方法。
假设你把s的平行度设为2，b1的平行度设为3，b2的平行度设为4。我们总共有2+3+4=9个任务。
然后您可以通过调用 Config.setNumWorkers() 方法。
在安排工人和任务之后，我们有如下任务id和组件： B1: taskId: 1,2,3 S: taskId: 4,5 B2: taskId: 6,7,8,9 请注意，同一组件中的任务id是连续的，但它不一定从喷口到螺栓开始。
然后我们有以下计划的工作人员和任务： Worker1: 1 4 6 Worker2: 2 5 7 Worker3: 3 8 9 我们可以看到，每个worker有3个任务，任务可能由不同的组件组成。
请注意，jstorm的调度算法与storm的默认调度算法有点相似（但功能更强大），请参阅以下比较：https://issues.apache.org/jira/browse/storm-1320
在拓扑的运行期间，如果不执行重新平衡操作，则计划的结果将始终相同，即，无论分配了哪个主机+端口（worker），此worker中的任务始终相同。即使重新启动拓扑，如果不更改组件的并行性，计划的结果也会相同。但如果执行重新平衡操作，任务可能会更改。
当worker中的某个任务死亡（通过抛出未检查/未处理的异常）时，整个worker将被杀死，错误将报告给zk。工人立即重新安排时间，注意 reschedule 这里可能不太合适，nimbus知道这个worker已经死了，它只会尝试在其他地方重新启动这个worker，但是这个worker中的任务是完全相同的。
更多jstorm文档请参考：https://github.com/alibaba/jstorm