Я использую storm для решения онлайн-проблем, но не могу понять, почему storm воспроизводит кортеж из spout . Повторная попытка с тем, что разбилось, может быть более эффективной, чем повтор от root, верно? Кто-нибудь может мне помочь? Спасибо
Почему storm воспроизводит кортеж из носика, а не повторяет попытку при сбое компонента?
Ответы (2)
Типичная реализация spout будет воспроизводить только кортежи FAILED
. Как объясняется здесь, кортеж, отправленный из источника, может вызвать запуск тысяч других кортежей, а storm создает дерево. кортежа на основе этого. Теперь кортеж называется «полностью обработанным», если обработано каждое сообщение в дереве. При испускании носика добавьте message id
, который используется для идентификации кортежа на более позднем этапе. Это называется привязкой и может быть сделано следующим образом.
_collector.emit(new Values("field1", "field2", 3) , msgId);
Теперь по ссылке, размещенной выше, это говорит
Кортеж считается неудавшимся, если его дерево сообщений не может быть полностью обработано в течение заданного времени ожидания. Это время ожидания может быть настроено для конкретной топологии с помощью конфигурации Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS и по умолчанию равно 30 секундам.
Если время ожидания кортежа истечет, Storm вызовет метод FAIL
на spout, а также в случае успеха будет вызван метод ACK
.
Итак, в этот момент storm сообщит вам, какой кортеж не удалось обработать, но если вы посмотрите на исходный код, вы увидите, что реализация метода fail
пуста в классе BaseRichSpout
, поэтому вам нужно переопределить Метод fail BaseRichSpout, чтобы иметь возможность воспроизведения в вашем приложении.
Такие повторы неудачных кортежей должны составлять лишь небольшую часть общего трафика кортежей, поэтому эффективность этой простой политики воспроизведения с начала обычно не вызывает беспокойства.
Поддержка шага «повторить из-ошибки» повлечет за собой много сложностей, поскольку местоположение ошибок иногда трудно определить, и потребуется поддержка «воспроизведения в другом месте» в случае, если узел кластера, на котором произошла ошибка, в настоящее время (или постоянно) вниз. Это также замедлит выполнение всего трафика, что, вероятно, не будет компенсировано эффективностью обработки ошибок (которая, опять же, предполагается, что она срабатывает редко).
Если вы считаете, что эта стратегия воспроизведения с самого начала негативно повлияет на вашу топологию, попробуйте разбить ее на несколько более мелких, разделенных какой-нибудь постоянной системой очередей, такой как Kafka.