ack引起的风暴延迟

Question

我正在使用kafka-storm来连接kafka和storm。我有3台运行zookeeper，kafka和storm的服务器。有一个主题＆＃39;测试＆＃39;在kafka有9个分区。

在风暴拓扑中，KafkaSpout执行程序的数量为9，默认情况下，任务数也应为9。并且＆＃39;提取物＆＃39; bolt是唯一连接到KafkaSpout的螺栓，＆＃39; log＆＃39;喷口。

从用户界面来看，鲸鱼喷水失败率很高。但是，他在bolt中执行的消息数=发出的消息数 - bolt中的失败消息数。当失败的消息在开始时为空时，该等式几乎匹配。

根据我的理解，这意味着螺栓确实从喷口接收到消息，但是ack信号在飞行中被暂停。这就是为什么喷口中的ack数量如此之小的原因。

可以通过增加超时秒数和spout挂起消息号来解决此问题。但这会导致更多的内存使用，我无法将其增加到无限。

如果有办法强迫风暴忽略某些喷口/螺栓中的确认，我就会徘徊，这样它就不会等到那个信号直到超时。这应该会显着增加整个过程，但不能保证消息处理。

Answer 1

如果你将ackers的数量设置为0，那么storm会自动响应每个样本。

config.setNumAckers(0);

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

config.setStatsSampleRate(1.0d);

尝试增加螺栓超时并减少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);

Answer 2

您的容量数字有点高，让我相信您真正最大限度地利用系统资源（CPU，内存）。换句话说，系统似乎陷入了困境，这可能是元组超时的原因。您可以尝试使用topology.max.spout.pending config属性来限制spout中的飞行元组数。如果你可以减少数量，拓扑结构应该能够有效地处理负载，而不会出现元组超时。