Ожидаемый штормовой шток
Это вопрос о том, как работает штормовой шток. У меня в настоящее время есть носик, который читает файл и испускает кортеж для каждой строки в файле (я знаю, что шторм - не лучшее решение для работы с файлами, но у меня нет выбора для этой проблемы). Я установил максимальный носик до 50 тыс., Чтобы уменьшить количество кортежей в обрабатываемой топологии. Тем не менее, я вижу, что это число не оказывает никакого влияния на топологию. Я вижу, что все записи в файле испускаются каждый раз. Я предполагаю, что это может быть связано с циклом, который у меня есть в методе nextTuple, который испускает все записи в файле. Таким образом, мой вопрос заключается в том, что шторм просто перестает вызывать следующий кортеж для задания носика при достижении макс. Означает ли это, что я должен испускать только один кортеж каждый раз, когда вызывается следующий вызов?
Ответы
Ответ 1
Точно! Шторм может ограничивать ваш носик следующей командой, поэтому, если вы передаете все, когда получите первый следующий, у Storm не будет возможности дросселировать ваш носик.
Разработчики Storm рекомендуют испускать один кортеж с помощью одной следующей команды. Затем система Storm будет дросселировать ваш носик по мере необходимости, чтобы соответствовать требованию "максимальное потребление носика". Если вы испускаете большое количество кортежей, вы можете исправить свои выбросы не более, чем на десятую часть вашего максимального ожидания, чтобы дать Storm возможность дросселировать.
Ответ 2
Топология шторма имеет параметр ожидания макс. Макс.
ожидающее значение носика для топологии может быть сконфигурировано с помощью
Установка "topology.max.spout.pending" в топологии
конфигурационный файл yaml. Это значение ограничивает количество
кортежи могут находиться в полете, т.е. еще не были выявлены или потерпели неудачу, в
Штормовая топология в любой момент времени. Необходимость этого параметра
происходит из-за того, что Storm использует ZeroMQ [25] для отправки
кортежи от одной задачи к другой задаче. Если потребительская сторона
ZeroMQ не может идти в ногу со скоростью кортежа, тогда
Очередь ZeroMQ начинает накапливаться. В конечном итоге тайм-аут кортежа
носик и переигрывать с топологией, тем самым добавляя большее давление
в очередях. Чтобы избежать этого случая патологической неудачи, Storm
позволяет пользователю установить ограничение на количество кортежей, которые находятся в
полет в топологии. Этот предел вступает в силу при выполнении одной задачи
а не на уровне топологии. В случаях, когда носики
ненадежны, то есть они не выдают идентификатор сообщения в своих кортежах, это
значение не влияет.
Одна из проблем, с которой постоянно сталкиваются пользователи Storm, - это
подходящее значение для этого максимального ожидания
параметр. Очень небольшое значение может легко голодать от топологии и
достаточно большое значение может перегрузить топологию огромным
количество кортежей в степени возникновения сбоев и повторов.
Пользователям необходимо пройти несколько итераций топологии
развертывания с различными ожидающими значениями максимального расхода, чтобы найти
которое лучше всего подходит для них.
Ответ 3
Одним из решений является создание входной очереди вне метода nextTuple, и единственное, что нужно сделать в nextTuple, - это опросить очередь и испустить. Если вы обрабатываете несколько файлов, ваш следующий метод Tuple должен также проверять, является ли результат опроса очереди нулевым, и если да, то атомически reset исходный файл, который заполняет вашу очередь.
