任务在 JStorm 中是如何工作的？
How do tasks work in JStorm?
JStorm中好像没有executors的概念，setTasksNumber()这个方法好像没用，因为tasks的个数跟parallelism_hint有关。
我的问题：JStorm 中的任务是静态的吗？如果不是，当一个任务死了，它会重新启动吗？如果任务不是静态的，fields-grouping 是如何工作的？
在 JStorm 中，worker 的行为类似于 Storm 中的执行者。一个worker可以有多个task，但是和Storm不同的是，一个worker中的task可能属于不同的组件，举个例子：
一个topology包含一个spout（S），2个bolts（B1，B2），每个组件的任务号在调用TopologyBuilder.buildTopology方法时设置，具体在TopologyBuilder.setBolt方法中
假设您将 S 的并行度设置为 2，B1 的并行度设置为 3，B2 的并行度设置为 4。我们总共有 2+3+4 = 9 个任务。
然后你可以通过调用Config.setNumWorkers()方法设置total worker num为3
安排工作人员和任务后，我们有这样的任务 ID 和组件：
B1: taskId: 1,2,3
S: taskId: 4,5
B2: taskId: 6,7,8,9
请注意，同一组件中的任务 ID 是连续的，但不一定从 spouts 到 bolts。
然后我们有以下计划的工作人员和任务：
Worker1: 1 4 6
Worker2: 2 5 7
Worker3: 3 8 9
可以看到，每个worker有3个task，task可能是不同的组件。
注意JStorm的调度算法和Storm默认的调度算法有点相似（但是更强大），请参考这个对比：
https://issues.apache.org/jira/browse/STORM-1320
在你的拓扑运行期间，如果你不执行rebalance操作，调度结果将始终相同，即无论分配哪个主机+端口（worker），这个工人的任务总是一样的。即使重新启动拓扑，如果您不更改组件的并行度，预定的结果将是相同的。但是如果你执行再平衡操作，任务可能会改变。
当一个worker中的某个task挂掉时（通过抛出一个unchecked/unhandled异常），整个worker将被杀死并且错误会被报告给ZK。 worker 立即重新调度，注意 reschedule 在这里可能不准确，nimbus 知道这个 worker 已经死了，它只会尝试在其他地方重新启动 worker，但是这个 worker 中的任务是完全一样的。
更多JStorm文档请参考：https://github.com/alibaba/jstorm
JStorm中好像没有executors的概念，setTasksNumber()这个方法好像没用，因为tasks的个数跟parallelism_hint有关。
我的问题：JStorm 中的任务是静态的吗？如果不是，当一个任务死了，它会重新启动吗？如果任务不是静态的，fields-grouping 是如何工作的？
在 JStorm 中，worker 的行为类似于 Storm 中的执行者。一个worker可以有多个task，但是和Storm不同的是，一个worker中的task可能属于不同的组件，举个例子：
一个topology包含一个spout（S），2个bolts（B1，B2），每个组件的任务号在调用TopologyBuilder.buildTopology方法时设置，具体在TopologyBuilder.setBolt方法中
假设您将 S 的并行度设置为 2，B1 的并行度设置为 3，B2 的并行度设置为 4。我们总共有 2+3+4 = 9 个任务。
然后你可以通过调用Config.setNumWorkers()方法设置total worker num为3
安排工作人员和任务后，我们有这样的任务 ID 和组件：
B1: taskId: 1,2,3
S: taskId: 4,5
B2: taskId: 6,7,8,9
请注意，同一组件中的任务 ID 是连续的，但不一定从 spouts 到 bolts。
然后我们有以下计划的工作人员和任务：
Worker1: 1 4 6
Worker2: 2 5 7
Worker3: 3 8 9
可以看到，每个worker有3个task，task可能是不同的组件。
注意JStorm的调度算法和Storm默认的调度算法有点相似（但是更强大），请参考这个对比： https://issues.apache.org/jira/browse/STORM-1320
在你的拓扑运行期间，如果你不执行rebalance操作，调度结果将始终相同，即无论分配哪个主机+端口（worker），这个工人的任务总是一样的。即使重新启动拓扑，如果您不更改组件的并行度，预定的结果将是相同的。但是如果你执行再平衡操作，任务可能会改变。
当一个worker中的某个task挂掉时（通过抛出一个unchecked/unhandled异常），整个worker将被杀死并且错误会被报告给ZK。 worker 立即重新调度，注意 reschedule 在这里可能不准确，nimbus 知道这个 worker 已经死了，它只会尝试在其他地方重新启动 worker，但是这个 worker 中的任务是完全一样的。
更多JStorm文档请参考：https://github.com/alibaba/jstorm