ack 引起的风暴延迟答案

【问题标题】：Storm latency caused by ackack 引起的风暴延迟
【发布时间】：2016-07-11 14:55:42
【问题描述】：

我正在使用 kafka-storm 连接 kafka 和storm。我有 3 台服务器运行 zookeeper、kafka 和storm。 kafka 中有一个主题“测试”，它有 9 个分区。

在storm topology中，KafkaSpout executor的数量是9，默认情况下，task的数量也应该是9。 'extract' bolt 是唯一连接到 KafkaSpout 的 bolt，即 'log' spout。

从 UI 来看，spout 的失败率很高。但是，bolt中执行的消息数=发出的消息数-bolt中失败的消息数。当失败消息一开始为空时，这个等式几乎匹配。

根据我的理解，这意味着螺栓确实收到了来自 spout 的消息，但 ack 信号在飞行中被暂停。这就是 spout 中的 ack 数量如此之少的原因。

这个问题可以通过增加超时秒数和 spout 待处理消息数来解决。但这会导致更多的内存使用，我不能将它增加到无限。

如果有一种方法可以强制风暴忽略某些 spout/bolt 中的 ack，我正在徘徊，这样它就不会等待该信号直到超时。这应该会显着增加吞吐量，但不能保证消息处理。

【问题讨论】：

标签： apache-storm

【解决方案1】：

如果你将 ackers 的数量设置为 0，storm 会自动确认每个样本。

config.setNumAckers(0);

请注意，UI 仅测量和显示 5% 的数据流。除非你设置

config.setStatsSampleRate(1.0d);

尝试增加bolt的超时时间并减少topology.max.spout.pending的数量。

另外，确保 spout 的 nextTuple() 方法是非阻塞和优化的。

我还建议对代码进行分析，也许您的风暴队列正在被填充，您需要增加它们的大小。

    config.put(Config.TOPOLOGY_TRANSFER_BUFFER_SIZE,32);
    config.put(Config.TOPOLOGY_EXECUTOR_RECEIVE_BUFFER_SIZE,16384);
    config.put(Config.TOPOLOGY_EXECUTOR_SEND_BUFFER_SIZE,16384);

【讨论】：

感谢您的建议。我通过将topology.max.spout.pending 限制为 2000 解决了这个问题。

【解决方案2】：

您的容量数字有点高，让我相信您确实在最大限度地利用系统资源（CPU、内存）。换句话说，系统似乎有点卡住了，这可能就是元组超时的原因。您可以尝试使用 topology.max.spout.pending 配置属性来限制来自 spout 的飞行元组的数量。如果您可以将数量减少到足够多，那么拓扑应该能够有效地处理负载而不会出现元组超时。

【讨论】：