问用ExecuteStreamCommand并行并行执行

EN

在这种情况下，您可以得到并发性和并行性，正如Apache NiFi用户指南中所指出的(强调是另加的)：

接下来，调度选项卡提供一个名为并发任务的配置选项。控制处理器将使用多少个线程。另一种说法是，这控制了这个处理器同时处理多少FlowFiles的。增加这个值通常会使处理器在相同的时间内处理更多的数据。但是，它是通过使用其他处理器无法使用的系统资源来做到这一点的。这实际上提供了处理器的相对权重( - )，它控制系统的多少资源应该分配给这个处理器，而不是其他处理器。此字段可供大多数处理器使用。但是，有些类型的处理器只能通过单个并发任务进行调度。

如果要调用的命令存在锁定问题或争用条件，这可能会有问题，但如果它们是独立的，则只受JVM调度和硬件性能的限制。

对评论中的问题的答复太长以至于无法发表评论：

问题：

谢谢安迪。当有4个内核时，我是否可以假设将有4个并行执行，其中它们将运行多个线程来处理10个并发任务？在我提到的场景中，这20个流文件是如何以最好的方式执行的。-约翰30分钟前

响应：

John，JVM线程处理是一个相当复杂的主题，但是是的，通常会有n+C JVM线程，其中C是常量(主线程、VM线程、GC线程)，n是由流控制器创建以执行处理器任务的“单个”线程数。JVM线程将1:1映射到本地OS线程，因此，在运行10个处理器线程的4个核心系统上，将有“4个并行执行”。我相信，在较高的级别上，您的操作系统将使用时间切片一次遍历10个线程4个，每个线程将处理~2个流文件。

同样，非常粗略的想法(假设一个流程文件=一个工作单位=1秒)：

Cores | Threads | Flowfiles/thread | Relative time
  1   |    1    |         20       |      20 s      (normal)
  4   |    1    |         20       |      20 s      (wasting 3 cores)
  1   |    4    |          5       |      20 s      (time slicing 1 core for 4 threads)
  4   |    4    |          5       |       5 s      (1:1 thread to core ratio)
  4   |   10    |          2       |       5+x s    (see execution table below)

如果假设每个核心可以处理一个线程，每个线程可以每秒处理一个流文件，并且每个线程获得1秒的不间断操作(显然不是真实的)，那么执行顺序可能如下所示：

Flowfiles A

岩心α，β，γ，δ

螺纹1- 10

时间/线程1

Time | Core α | Core β | Core γ | Core δ
  0  |   1/A  |   2/B  |   3/C  |   4/D
  1  |   5/E  |   6/F  |   7/G  |   8/H
  2  |   9/I  |  10/J  |   1/K  |   2/L
  3  |   3/M  |   4/N  |   5/O  |   6/P
  4  |   7/Q  |   8/R  |   9/S  |  10/T

在5秒内，所有10个线程都执行了两次，每个线程都完成了两个流文件。

但是，假设线程调度程序只为每个线程分配一个.5秒的循环，每次迭代(同样，不是一个实际的数字，只是为了演示)。然后执行模式将是：

Flowfiles A

岩心α，β，γ，δ

螺纹1- 10

时间/线程.5

Time | Core α | Core β | Core γ | Core δ
  0  |   1/A  |   2/B  |   3/C  |   4/D
 .5  |   5/E  |   6/F  |   7/G  |   8/H
  1  |   9/I  |  10/J  |   1/A  |   2/B
1.5  |   3/C  |   4/D  |   5/E  |   6/F
  2  |   7/G  |   8/H  |   9/I  |  10/J
2.5  |   1/K  |   2/L  |   3/M  |   4/N
  3  |   5/O  |   6/P  |   7/Q  |   8/R
3.5  |   9/S  |  10/T  |   1/K  |   2/L
  4  |   3/M  |   4/N  |   5/O  |   6/P
4.5  |   7/Q  |   8/R  |   9/S  |  10/T

在这种情况下，总执行时间是相同的(*线程切换有一些开销)，但是特定的流文件需要“更长”(从0开始的总时间，而不是活动执行时间)。例如，在第二个场景中，流文件C和D直到time=2才能完成，但是在第一个场景中在time=1完成。

老实说，OS和JVM有比我聪明得多的人在这方面工作，我们的项目(幸运的)也是如此，所以这里存在严重的过度简化，总的来说，我建议您让系统担心线程的超优化。在这种情况下，我不认为将并发任务设置为10会比将其设置为4有很大的改进。您可以阅读更多有关JVM线程、这里和这里的内容。

我刚刚在我的本地1.5.0开发分支中做了一个快速测试--我把一个简单的GenerateFlowFile连接到一个LogAttribute处理器上，这个简单的运行着0 sec计划的程序。GenerateFlowFile立即生成如此多的流文件，以至于队列启用了背压特性(暂停输入处理器直到队列可以耗尽10,000个等待的流文件)。我停止了这两个操作，并重新运行它，给LogAttribute处理器带来了更多并发任务。通过将LogAttribute并发任务设置为GenerateFlowFile的2:1，队列从未建立过大约50个排队流文件。

​

​

博士将你的并发任务设置为你拥有的核心数量应该足够了。

更新2:

与我们的一位常驻JVM专家进行了检查，他提到了两件需要注意的事情：

1. 该命令不只是CPU限制；如果I/O很重，则可能会有更多并发任务。
2. 默认情况下，整个流控制器的最大并发任务数设置为10。