似乎JStorm中没有 executors 的概念，方法setTasksNumber()似乎没用，因为任务数量与parallelism_hint有关。
我的问题：JStorm中的任务是静态的吗？如果没有，当任务失效时，它会重启吗？如果任务不是静态的，fields-grouping如何工作？
答案 0 :(得分：1)
在JStorm中，一名工人表现得像Storm中的执行者。一个worker可以有多个任务，但与Storm不同，worker中的任务可能属于不同的组件，让我们举个例子：
拓扑包含一个spout（S），2个bolt（B1，B2），在调用TopologyBuilder.buildTopology方法时设置每个组件的任务编号，特别是在TopologyBuilder.setBolt方法中。
因此，假设您将S的并行度设置为2，将B1的并行度设置为3，将B2设置为4.我们将总共有2 + 3 + 4 = 9个任务。
然后，您可以通过调用Config.setNumWorkers()方法将总工作数设置为3。
安排工人和工作人员任务，我们有任务ID和这样的组件：
B1: taskId: 1,2,3
S: taskId: 4,5
B2: taskId: 6,7,8,9
请注意，同一组件中的任务ID是连续的，但它不一定从spouts到bolt开始。
然后我们有以下预定的工人和任务：
Worker1: 1 4 6
Worker2: 2 5 7
Worker3: 3 8 9
我们可以看到，每个工作者有3个任务，任务可能是不同的组件。
请注意，JStorm的调度算法与Storm的默认调度算法（但更强大）有点相似，请参考此比较： https://issues.apache.org/jira/browse/STORM-1320
在拓扑运行期间，如果不执行重新平衡操作，则计划结果将始终相同，即，无论分配哪个主机+端口（工作程序），此工作程序中的任务是总是一样。即使重新启动拓扑，如果不更改组件的并行度，计划结果也将相同。但是，如果执行重新平衡操作，任务可能会发生变化。
当一个工人的某个任务死亡时（通过抛出一个未经检查/未处理的异常），整个工人将被杀死并且错误将被报告给ZK。工作人员立即重新安排，注意reschedule可能不适合这里，nimbus知道这个工人已经死了，它只会尝试重新启动其他工作人员，但这个工人的任务完全一样。
有关更多JStorm文档，请参阅：https://github.com/alibaba/jstorm