我有一个拓扑运行了几天，它开始失败元组从过去几天。从日志看来，元组似乎没有达到螺栓，附上的是风暴用户界面截图。我在我的代码中确认了finally中的元组，因此没有未确认元组的情况，并且超时设置为10秒，这比ui上显示的时间要高。有什么提示吗？在这里输入图像描述
0kjbasz61#
你看到的日志只不过是Kafka喷口告诉你，它已经落后太多，它已经开始跳过元组。我相信只有acked元组才算完整的延迟度量https://github.com/apache/storm/blob/a4afacd9617d620f50cf026fc599821f7ac25c79/storm-client/src/jvm/org/apache/storm/stats/spoutexecutorstats.java#l54. 失败的元组没有（storm如何知道超时元组的实际延迟），因此您看到的完整延迟仅适用于最初的两个acked元组。我认为发生的情况是，元组到达螺栓，然后要么你没有确认它们（或多次确认它们），要么元组处理时间太长，所以它们在排队等待螺栓时超时。请记住，元组超时从喷口发出元组时开始，因此花费在bolt的输入队列中的时间是很重要的。由于最初的两个元组需要一段时间来处理，我认为bolt队列会备份已经超时的元组。bolt不会丢弃超时的元组，因此排队的超时元组会阻止及时处理新元组。我将提高tuple timeout，并通过将topology.max.spout.pending设置为您认为合理的值（类似于您认为可以在超时内处理的tuple数）来限制挂起的tuple数
1条答案
按热度按时间0kjbasz61#
你看到的日志只不过是Kafka喷口告诉你，它已经落后太多，它已经开始跳过元组。
我相信只有acked元组才算完整的延迟度量https://github.com/apache/storm/blob/a4afacd9617d620f50cf026fc599821f7ac25c79/storm-client/src/jvm/org/apache/storm/stats/spoutexecutorstats.java#l54. 失败的元组没有（storm如何知道超时元组的实际延迟），因此您看到的完整延迟仅适用于最初的两个acked元组。
我认为发生的情况是，元组到达螺栓，然后要么你没有确认它们（或多次确认它们），要么元组处理时间太长，所以它们在排队等待螺栓时超时。请记住，元组超时从喷口发出元组时开始，因此花费在bolt的输入队列中的时间是很重要的。由于最初的两个元组需要一段时间来处理，我认为bolt队列会备份已经超时的元组。bolt不会丢弃超时的元组，因此排队的超时元组会阻止及时处理新元组。
我将提高tuple timeout，并通过将topology.max.spout.pending设置为您认为合理的值（类似于您认为可以在超时内处理的tuple数）来限制挂起的tuple数