风暴，螺栓延迟和总延迟之间存在巨大差异？

Question

下面是我拓扑的Storm UI的屏幕截图。这是在拓扑完成处理10k消息后进行的。

（拓扑配置有4个工作人员并使用KafkaSpout）。

我的螺栓的“过程延迟”总和约为8100ms，拓扑的完整延迟时间长得多115881ms。

我知道这些差异可能是由于资源争用或与Storm内部相关的事情而发生的。我认为资源争夺不是问题;在此测试期间，GC根本没有运行，并且分析显示我有足够的可用CPU资源。

所以我认为问题在于我以某种方式滥用Storm内部。有什么建议去哪儿看？

元组必须在某个地方等待，可能在鲸鱼嘴里;是等待发送到拓扑还是在处理消息时等待被激活？

可能我应该调整ackers的数量（我将ackers设置为4，与工人数相同）？

关于我应该如何解决这个问题的其他一般性建议？

*请注意，在其进程和执行延迟之间存在较大差异的一个螺栓实现了滴答螺栓，批处理模式。因此预计会出现差异。

*编辑。 我怀疑这种差异可能涉及Spout在完全处理后被消息激活的消息。如果我在处理时刷新Storm UI，那么与Spouts的ack-ed数字相比，我最终Bolt的确认数字会迅速增加。虽然这可能是因为Spout比最终Bolt的消息要少得多;由最终螺栓确认的几百条消息可能代表Spout中的单个消息。但是，我认为我应该提到这种怀疑，以获得关于它是否可能的意见，Spout的acker任务正在溢出。

Answer 1

可能有多种原因。首先，您需要了解如何衡量数字。

1. Spout Complete Latency：在调用Spout.ack()之前发出元组的时间。
2. Bolt Execution Latency：运行Bolt.execute()。
所需的时间
3. 螺栓加工延迟：调用时间Bolt.execute()，直到螺栓响应给定的输入元组。

如果您没有立即确认Bolt.execute中的每个传入输入元组（这绝对没问题），处理延迟可能远高于执行延迟。

此外，处理延迟不得累加完整延迟，因为元组可以保留在内部输入/输出缓冲区中。这会增加额外的时间，直到最后一次确认完成，从而增加完整延迟。此外，ackers需要处理所有传入的ack并通知Spout关于完全处理的元组。这也会增加完整延迟。

问题可能是运营商之间的大型内部缓冲区。这可以通过增加dop（并行度）或通过设置参数TOPOLOGY_MAX_SPOUT_PEDING来解决 - 这限制了拓扑中元组的数量。因此，如果在飞行中有太多元组，则喷口会停止发出元组，直到它收到响应。因此，元组不会在内部缓冲区中排队，并且完整延迟会降低。如果这没有帮助，您可能需要增加ackers的数量。如果没有足够快地处理ack，那么ack可以缓冲，增加完整延迟。