Apache Storm存在元组动态重定向问题（对端到端延迟的影响令人费解）

Question

我已经在一台服务器上安装了Storm 0.9.4和ZooKeeper 3.4.6（2个套接字，带有Intel Xeon 8核芯片，96 GB ram运行CentOS)，我还设置了一个伪分布式的单节点Storm运行时。我的配置由1个zookeeper服务器、1个nimbus进程、1个supervisor进程和1个worker进程（提交拓扑时）组成，它们都运行在同一台机器上。我的实验的目的是看到Storm在单个节点设置上的行为，当输入负载在执行器线程之间动态分配时。

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

现在您已经意识到，目标是通过模拟添加另一个使用者执行器，看看是否可以为输入尖峰保持端到端的延迟<10毫秒。为了模拟为输入尖峰添加处理资源，我使用直接分组，并且在尖峰之前，我只向两个使用者执行器中的一个发送元组。当在Dispatcher上检测到尖峰时，它也开始向另一个使用者发送元组，以便在两个线程之间平衡输入负载。因此，我希望当我开始向额外的使用者线程发送元组时，端到端延迟将下降到其可接受的值。然而，前一种情况并不发生。

为了验证我的假设，即两个使用者执行器能够在一个尖峰期间保持<10毫秒的延迟，我执行了相同的实验，但这一次，我在实验的整个生存期内向两个执行器（线程）发送元组。在这种情况下，端到端延迟保持稳定并处于可接受的水平。所以，我不知道在我的模拟中发生了什么。在输入负载被重定向到额外的消费者执行器的情况下，我无法真正弄清楚是什么导致端到端延迟恶化。

为了弄清楚更多关于Storm的机制，我在一台较小的机器上做了同样的设置，并做了一些分析。我看到大部分时间都花在了lmax干扰器的BlockingWaitStrategy上，它支配着CPU。我的实际处理函数（在Consumer bolt中）只需要lmax BlockingWaitStrategy的一小部分。因此，我认为这是队列之间的I/O问题，而不是与消费者中元组的处理有关的问题。

你知道是什么出了问题，我才会有这种激进的/令人费解的行为吗？

谢谢你。

Answer 1

首先，感谢您提出的详细和完善的问题！我这边有多重评论（不确定这是不是已经是答案了……)：

1. 您的实验相当短（时间范围在1分钟以下），我认为这可能不能提供可靠的数字。
2. 如何检测尖峰？
3. 您对Storm中的内部缓冲区机制感到敬畏吗（请查看:http://www.michael-noll.com/blog/2013/06/21/commanding-storm-internal-message-buffers/)
4. 您html" target="_blank">配置了多少个ACLER？
5. 我假设在尖峰期间，在检测到尖峰之前，缓冲区已被填满，清空它们需要一些时间。因此，延迟不会立即下降（可能会延长您的上一个周期来解决这个问题）。
6. 使用ack机制是很多人做的，但是它是相当不精确的。首先，它显示一个平均值（使用均值、分位数或最大值会更好。此外，测量值毕竟不是应该考虑的延迟。例如，如果您将一个元组保持在内部状态一段时间，并且直到该元组从该状态中移除才对其进行ack，那么Storm的“latency”值将增加对延迟度量没有意义的值。延迟的通常定义是使用结果元组的输出时间戳，然后减去源元组的发射时间戳（如果有多个源元组，则在所有源元组上使用最年轻的时间戳，即最大时间戳）。棘手的部分是找出每个输出元组对应的源元组...作为另一种选择，有些人将携带发射时间戳虚拟元组作为数据注入。每个操作符立即转发这个伪元组，并且接收器操作符可以轻松地竞争一个延迟值，因为它可以访问四处携带的发射时间戳。这是前面描述的实际延迟的一个相当好的近似值。

希望这有帮助。如果你有更多的问题和/或信息，我可以在稍后完善我的回答。