根据this和this链接，Storm *(会在出现背压时节流喷口。更准确地说，会发生以下情况：
1.如果执行器的接收队列已满，则通知反压线程
1.此反压线程与ZooKeeper通信，说明给定拓扑上发生了反压

1. ZooKeeper通知所有工作人员必须关闭喷口
   1.喷口调节其发送速度/事件速率。

显然，拓扑不会像您的情况那样崩溃。

我在这里要推荐一些东西：

• 如果你发现任何错误，请仔细检查所有主管、工人和光轮的日志。我经常在 Storm 日志中检查日志和错误。
• 根据上述参考文献和Storm文档，有几个参数会影响背压行为。也许你可以试试这些参数，看看是否有任何影响：
• topology.max.spout.pending：根据第二个链接，它是在给定时间在拓扑中可以等待确认的元组的数量。
• 背压系统依赖于接收缓冲区大小对于一个螺栓的满度。这就是为什么有水位线的概念。高水位线和低水位线定义了缓冲区必须有多满或多空才能调节喷口或重新启动喷口：disruptor.highwatermark（默认值为0.9）。这意味着，对于0.9，发送满信号，并在螺栓的接收缓冲区90%满时调节喷口。
• disruptor.lowwatermark（默认值为0.4）表示对于0.4，发送 not full 信号，并在螺栓的接收缓冲区低于容量的40%时再次启动spout
• 使用**Storm Metrics**可以更精确地分析进程。要观察的一些潜在度量包括：
• __skipped-backpressure-ms：此度量记录由于背压指示拓扑中的下游队列太满而使spout空闲的时间。
• arrival_rate_secs：估计一秒钟内插入队列的元组数，尽管它实际上是出队率。
• sojourn_time_ms是根据到达速率计算的，并且是每个元组在被处理之前在队列中停留多少毫秒的估计。

然而，Storm Metrics是一个麻烦，因为这些文件会定期记录到磁盘。设置监控工具可能会有帮助。不幸的是，唯一提到的监控工具是storm-graphite，它似乎没有被维护。我也读过一次有人使用Grafana或其他工具。
总而言之，我很想知道你希望如何解决这个问题。