как инфраструктура Storm постоянно вызывает метод nextTuple().
Я считаю, что на самом деле это включает в себя очень подробное обсуждение всего жизненного цикла топологии шторма, а также четкие концепции различных сущностей, таких как рабочие, исполнители, задачи и т. д. Фактическая обработка топологии выполняется классом StormSubmitter с его submitTopology метод.
Самое первое, что он делает, это начинает загружать банку с помощью интерфейса Nimbus Thrift и затем вызывает submitTopology, которая в итоге отправляет топологию в Nimbus.
Затем Nimbus начинает с нормализации топологии (из документа: Основная цель нормализации — убедиться, что каждая отдельная задача будет иметь одинаковые регистрации сериализации, что очень важно для правильной работы сериализации. ), за которыми следует сериализация, рукопожатие Zookeeper , запуск процессов supervisor и worker и так далее. Это слишком широко для обсуждения, но если вы действительно хотите узнать больше, вы можете пройти через жизненный цикл storm. топология, где хорошо объясняются пошаговые действия, выполняемые в течение всего времени.
( небольшое примечание из документации)
Сначала пара важных замечаний о топологиях:
Фактическая топология, которая работает, отличается от топологии, указанной пользователем. Фактическая топология имеет неявные потоки и неявный болт «acker», добавленный для управления структурой подтверждения (используется для гарантии обработки данных).
Неявная топология создается через системную топологию! функция. системная топология! используется в двух местах:
- - когда Nimbus создает задачи для кода топологии
- - в рабочем потоке, чтобы он знал, куда ему нужно направить сообщения в код
Теперь вот несколько подсказок, которыми я мог бы поделиться...
Носики или болты на самом деле являются компонентами, которые выполняют реальную обработку (логику). В терминологии штормов они выполняют столько же задач по всей структуре.
На странице документа: Каждая задача соответствует одному потоку выполнения
Теперь, среди многих других, одна типичная обязанность worker process (прочитайте здесь) в storm предназначен для отслеживания того, активна топология или нет, и сохраняется это конкретное состояние в переменной с именем storm-active-atom. Эта переменная используется задачами, чтобы определить, следует ли вызывать метод nextTuple. Итак, пока ваша топология жива (вы не поместили свой код носика, но предполагаете) до того времени, когда ваш таймер активен (как вы сказали определенное время) он будет продолжать вызывать метод nextTuple. Вы можете копнуть еще глубже, чтобы понять реализацию среды подтверждения шторма, чтобы понять, как он понимает и признает один раз кортеж успешно обработан и Гарантия обработки сообщений
Я уверен, что в моем понимании здесь чего-то не хватает, и из-за этого пробела я не могу подключиться к внутренней логике этого фреймворка.
Сказав это, я думаю, что более важно получить четкое представление о том, как работать со штормом, а не как понимать шторм на ранней стадии. например, вместо того, чтобы изучать внутренний механизм шторма, важно понимать, что если мы настроим носик для чтения файла построчно, он будет продолжать испускать каждую строку, используя метод _collector.emit, пока не достигнет EOF. И болт, связанный с ним, получает то же самое в своем execute(tuple input) методе
Надеюсь, это поможет вам поделиться с нами больше в будущем
person
user2720864
schedule
05.12.2013
