java - 元组的动态重定向的Apache Storm问题(对端到端延迟的影响令人困惑)

Question

在下面，我包含解释我在Storm中面临的问题的文本。无论如何，我知道这是一篇很长的文章（请多加注意），任何评论/指示都值得欢迎。描述如下：

我已经在一台服务器上安装了Storm 0.9.4和ZooKeeper 3.4.6（2个插槽，装有Intel Xeon 8核芯片，运行CentOS的96 GB内存），并且已经设置了一个伪分布式的单节点Storm运行时。我的配置包括1个Zookeeper服务器，1个nimbus进程，1个主管进程和1个工作进程（提交拓扑时），它们都在同一台计算机上运行。我的实验的目的是查看输入负载在执行程序线程之间动态分配时，Storm在单节点设置上的行为。

出于实验目的，我输入了由1个long和1个整数组成的元组。输入数据来自两个从磁盘文件读取元组的喷嘴，我控制输入速率以遵循该模式：
前24秒（时间0-24秒）为200元组/秒
接下来的12秒（24-36秒）为800元组/秒
200元组/秒，持续6秒（时间36-42秒）
转到我的拓扑，我有两种类型的螺栓：a）一个Dispatcher螺栓，它接收来自两个喷嘴的输入；以及（b）一个Consumer螺栓，它对元组执行操作并保持一些元组为状态。 Dispatcher的并行性提示是一个（1个执行程序/线程），因为我已经检查过它永远不会达到其容量的10％。对于Consumer螺栓，我有两个并行提示（该螺栓有2个执行程序/线程）。选择了我前面提到的输入速率，以便我可以使用Consumer螺栓上的适当数量的执行器来监视不到10毫秒的端到端延迟。详细地说，我使用一个Consumer执行程序运行了相同的拓扑，它可以处理200个元组/秒的输入速率，端到端延迟<10毫秒。同样，如果我再添加一个消费者执行器（总共2个执行器），则拓扑可以消耗800个元组/秒，端到端延迟小于10毫秒。在这一点上，我不得不说，如果我使用1个消费者执行器以800个元组/秒的速度运行，则端到端延迟将达到2秒。顺便说一句，我不得不提到，我使用螺栓的ack（）函数来测量端到端的延迟，并查看从发送拓扑中的元组到完全确认其元组树之间需要花费多少时间。

到现在为止，您的目标是通过模拟另一个Consumer执行器的添加来查看我是否可以将输入尖峰的端到端延迟保持在<10毫秒以内，以便模拟为输入添加处理资源峰值，我使用直接分组，在峰值之前，我仅将元组发送给两个消费者执行器之一。当在Dispatcher上检测到峰值时，它也开始将元组发送到另一个Consumer，以便在两个线程之间平衡输入负载。因此，我希望当我开始将元组发送到附加的Consumer线程时，端到端的延迟将降至其可接受的值。但是，以前没有发生。

为了验证我的假设，即两个Consumer执行器能够在峰值期间保持小于10毫秒的延迟，我执行了相同的实验，但是这次，我在整个实验过程中将元组发送给两个执行器（线程）。在这种情况下，端到端延迟保持稳定并处于可接受的水平。因此，我不知道模拟中真正发生了什么。在将输入负载重定向到附加的Consumer执行程序的情况下，我无法真正找出导致端到端延迟恶化的原因。

为了进一步了解Storm的机制，我在较小的计算机上进行了相同的设置并进行了性能分析。我看到大部分时间都花在了lmax干扰器的BlockingWaitStrategy中，它支配着CPU。我的实际处理功能（在Consumer螺栓中）仅占lmax BlockingWaitStrategy的一小部分。因此，我认为这是队列之间的I / O问题，而不是与Consumer中元组的处理有关。

关于出什么问题的任何想法，我都会得到这种激进/令人困惑的行为？

谢谢。

Answer 1

首先，感谢您提出的详细而有条理的问题！我这边有很多评论（不确定是否已经是答案...）：


您的实验相当短（时间范围小于1分钟），我认为这可能无法显示可靠的数字。
您如何检测峰值？
您对Storm中的内部缓冲机制感到敬畏吗（请看这里：http://www.michael-noll.com/blog/2013/06/21/understanding-storm-internal-message-buffers/）
您配置了多少个acker？
我假设在您的峰值期间，在检测到峰值之前，缓冲区已被填满，清空它们需要一些时间。因此，延迟不会立即下降（也许延长您的上一个周期即可解决）。
许多人都使用ack机制，但这是不精确的。首先，它显示一个平均值（使用平均值，分位数或最大值会更好。此外，量度值根本不应该视为等待时间。例如，如果您将一个元组保持在内部状态在一段时间内，直到元组从状态中删除之前，不要确认它，Storm的“等待时间”值会增加对延迟测量没有意义的值。延迟的通常定义是获取结果元组的输出时间戳并减去源元组的发射时间戳（如果有多个源元组，则在所有源元组上使用最小的时间戳，即最大时间戳）。棘手的部分是找出每个输出对应的源元组元组...作为替代方案，有些人将带有其发射时间戳记的伪元组作为数据注入，每个操作员都会立即转发此伪元组，而接收器操作员可以轻松访问延迟值，因为它可以访问发射时间戳记。提起nd。如前所述，这是实际延迟的一个很好的近似值。


希望这可以帮助。如果您还有其他问题和/或信息，我稍后可以完善答案。