Parallel processing 风暴平行理解

我已经阅读了有关风暴平行线的相关资料，但仍有一些不清楚的地方。假设我们以tweet处理为例。通常我们所做的是检索推文流，计算每条推文的字数，并将数字写入本地文件

我的问题是如何理解喷嘴和螺栓平行度的价值。在builder.setSpout和builder.setBolt函数中，我们可以分配并行值。但在推特的字数计算中，只设置一个喷口是否正确？多个喷口被视为第一个相同喷口的副本，相同的推特通过该喷口流入多个喷口。如果是这种情况，设置多个喷口的值是多少

另一个不清楚的问题是如何为螺栓分配工作？平行机构是否以Storm将找到当前可用螺栓的方式实现，以处理下一个排放喷口？我修改了基本的tweets计数代码，这样最终的计数结果将被写入一个特定的目录中，然而，所有结果实际上都合并到nimbus上的一个文件中。因此，在处理主管的数据后，所有结果都将发送回nimbus。如果这是真的，那么nimbus和主管之间的沟通机制是什么

我真的很想解决这些问题！！！谢谢你的帮助

在某些情况下，如“卡夫卡消费者组”，您具有队列行为，这意味着如果一个消费者从队列中读取消息，另一个消费者将从队列中读取不同的消息。 这将把队列中的读取负载分配给所有工作人员。

---

在这些情况下，您可以从队列中读取多个喷口

设置大于一个喷口的并行度，这要求用户代码对不同实例执行不同的操作。否则（正如您已经提到的），数据只会通过拓扑发送两次。例如，您可以有一个要侦听的端口列表（或一个不同卡夫卡主题的列表）。因此，您需要确保不同的实例侦听不同的端口或主题。。。这可以通过查看拓扑元数据（如自己的任务ID和dop）在

open（…）

方法中实现。由于每个实例都有一个唯一的ID，因此可以对端口/主题进行分区，以便每个实例从整个列表中选择不同的端口/主题

关于并行性：这取决于将拓扑插入到一起时使用的连接模式。例如，使用

shufflegroup

会将发出的元组循环分布到使用的bolt实例。对于这种情况，Storm不会“查看”是否有任何螺栓实例可供处理。如有必要，元组只需在接收方进行传输和缓冲

---

此外，Nimbus和Supervisor只交换元数据。它们之间没有数据流（即元组流）。

我不明白你的最后一个问题：“我修改了基本的tweets计数代码，这样最终的计数结果将被写入一个特定的目录，然而，所有结果实际上都被合并到nimbus上的一个文件中。因此，在处理主管的数据后，所有结果都将发送回nimbus。如果这是真的，那么nimbus和主管之间的沟通机制是什么？“因此，我们可以将其视为一个生动的场景，像实时推文一样源源不断的推文扮演着一池水的角色，而喷口扮演着管道的角色。这里的平行机制是我们想要在单位时间内泵出更多的水，所以需要多个喷嘴来处理它们。我想我理解设置喷嘴平行的第一点。感谢您提到随机分组方法，我没有意识到在这种情况下storm不会为处理寻找可用的螺栓。我将检查其他分组方法。关于我的第二个问题，我所做的是，它将把处理结果写入一个特定的目录，如/home/storm/results.txt。昨天，我认为supervisor machines中的处理结果也会发送回nimbus machine上的results.txt文件。我不确定nimbus machine如何从supervisor machines中的螺栓获得最终处理结果。Storm没有提供您喜欢的负载平衡连接模式。为什么你认为洗牌组合不适合你？Nibmus不会从bolts接收任何数据。你需要在你的水槽螺栓中自己处理你的最终结果…是的。执行下沉螺栓的主管将在本地进行。