Apache Storm вопросы тайм-аута кортежа - PullRequest
Новая
       6

Apache Storm вопросы тайм-аута кортежа

0 голосов
/ 17 апреля 2019

Я пытаюсь понять состояние топологии в случае тайм-аута обработки кортежа (не в режиме Trident). Предположим, что во время обработки кортежа в каком-либо болте был достигнут порог тайм-аута.В этом случае носик испускает исходный кортеж снова (с тем же идентификатором сообщения, как я понимаю).Теперь допустим, что Bolt заканчивает обработку кортежа, а также выдает и подтверждает кортеж.В этом сценарии:

  1. Будет ли сбойный кортеж по-прежнему обрабатываться топологией, несмотря на то, что носик выдал новый начальный кортеж?будет выглядеть (поскольку существует новая группа обеспечения доступности баз данных, созданная с тем же начальным идентификатором кортежа), что произойдет с предыдущей исходной группой обеспечения доступности баз данных?
  2. что произойдет, когда программа-получатель получит подтверждение и отправит идентификаторы привязки предыдущего группы обеспечения доступности баз данных?

1 Ответ

0 голосов
/ 17 апреля 2019

1: Да, сбойный кортеж продолжается.Причина этого в том, что было бы слишком дорого пытаться остановить продолжение неудачного кортежа, так как носик должен был бы рассказать всем болтам о сбое.

2: Я думаю, что здесь есть небольшое недоразумение,Когда носик испускает кортеж, идентификатор сообщения не является тем, что Storm использует для внутреннего отслеживания этой группы DAG / дерева.Вместо этого исполнитель носика генерирует случайный идентификатор (назовите его rootId) и локально сохраняет отображение rootId -> messageId.Идентификатор сообщения никогда не покидает исполнитель носика и не распространяется на болты.

Когда исполнитель носика отправляет кортеж вперед, он включает rootId.rootId - это то, что используется средством идентификации и болтами для идентификации дерева кортежей.

Наконец, когда дерево полностью взломано или происходит сбой кортежа, исполнителю spout сообщают, что соответствующий rootId успешно выполненили не удалось, и он ищет исходный messageId в своем локальном отображении.

Поскольку новый эмитт с тем же messageId получает новый rootId, между неудачным и новым кортежами нет никакой связи,По мнению Storm, они считаются совершенно отдельными.

Я немного упростил вышеприведенное для ясности, чтобы обработать носик, испускающий несколько болтов, есть еще один набор случайных идентификаторов (anchorId).Концептуально вы можете представить себе ситуацию, когда 

spout -> bolt1
      -> bolt2

обрабатывается так, как если бы топология была 

spout -> splitterBolt -> bolt1
                      -> bolt2

3: допустим, ваш кортеж истек.Исполнителю носика сообщили, что rootId не удалось.Когда это происходит, исполнитель spout вызывает spout.fail(msgId), а затем удаляет сопоставление на карте rootId -> messageId.

Когда аккер получает подтверждение, он может отправить подтверждение на носик, если дерево полностью взломано.Когда носик получает ack, он не имеет ничего, соответствующего rootId, поэтому ack игнорируется.

Если вам интересно взглянуть на код, его можно найти по адресу https://github.com/apache/storm/blob/b48e10559b65e834884d59887b30fc86d2988c20/storm-client/src/jvm/org/apache/storm/executor/spout/SpoutOutputCollectorImpl.java#L109. Отображение rootId -> messageId называется pending.

...