Штормовая латентность, вызванная ack

Question

Я использовал kafka-storm для подключения кафки и шторма. У меня есть 3 сервера, на которых работают zookeeper, kafka и storm. В кафке есть тема «тест» с 9 разделами.

В топологии шторма количество исполнителей KafkaSpout равно 9, и по умолчанию количество задач должно быть равно 9. И «вытяжной» болт - единственный болт, соединенный с KafkaSpout, носителем «log».

Из пользовательского интерфейса в истоке есть огромная ошибка. Тем не менее, количество выполненных сообщений в болтах = количество испущенных сообщений - количество неудачных сообщений в болте. Это уравнение почти соответствует, когда неудавшееся сообщение в начале пусто.

Основываясь на моем понимании, это означает, что болт действительно получил сообщение от носика, но сигналы ack приостановлены в полете. Именно по этой причине количество хвостов в носике настолько невелико.

Эта проблема может быть решена путем увеличения количества секунд ожидания и ожидания ожидающего сообщения. Но это вызовет больший объем использования памяти, и я не могу увеличить его до бесконечности.

Я блуждал, если есть способ заставить шторм игнорировать акр в каком-то носике/болте, чтобы он не дождался этого сигнала до истечения времени. Это должно значительно увеличиться, но не гарантировать обработку сообщений.

Answer 1

если вы установили число аккеров в 0, то шторм автоматически будет вызывать каждый образец.

config.setNumAckers(0); 

Обратите внимание, что пользовательский интерфейс измеряет и показывает 5% потока данных. , если вы установите

config.setStatsSampleRate(1.0d); 

попробуйте увеличить таймаут болта и уменьшая количество topology.max.spout.pending.

также, убедитесь, что следующий метод spout() не блокируется и оптимизирован.

Я бы также рекомендовал профилировать код, возможно, ваш шторм Очереди заполняются, и вам нужно увеличить их размеры.

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

Ваших номера емкость немного высоки, что приводит меня к мысли, что вы на самом деле максимальным использование системных ресурсов (процессор, память). Другими словами, система, похоже, немного погрязла, и, вероятно, почему кортежи выходят из строя. Вы можете попробовать использовать свойство конфигурации topology.max.spout.pending, чтобы ограничить количество кортежей для полетов из носа. Если вы можете уменьшить число достаточно, топология должна иметь возможность эффективно обрабатывать нагрузку без тайм-аута кортежей.