Архитектура потоковой обработки

Question

Я нахожусь в процессе разработки системы, в которой есть основной поток объектов, и есть несколько рабочих, которые производят некоторый результат из этого объекта.Наконец, есть некоторый специальный / уникальный работник (своего рода «сток», с точки зрения теории графов), который берет все результаты и обрабатывает их в некотором конечном объекте, который записывается в некоторую БД.

Itвозможно, что работник зависит от результатов других работников (следовательно, ждет их результатов)

Теперь я сталкиваюсь с несколькими проблемами:

1. Это может бытьтот один работник намного медленнее другого.Как ты с этим справляешься?Добавление большего количества рабочих (= масштабирование) более медленного типа?(возможно динамически)
2. Предположим, W_B зависит от W_A.Если W_B по какой-то причине не работает, поток останавливается, и система перестает работать.Поэтому я бы хотел, чтобы система как-то обошла этого работника.
3. Более того, как конечный работник решает, когда работать с набором результатов?Предположим, что у него есть результаты A и B, но нет результата C. Может быть, C не работает или просто очень медленно в данный момент.Как это может принять решение?

Стоит отметить, что это не приложение реального времени, а автономная система обработки (т. Е. Вы можете получить доступ к БД и изменить запись), но в то же время она имеет дело с относительнобольшое количество объектов в «быстром темпе».

Что касается технологий,
Я занимаюсь разработкой системы с использованием Java, но не привязан к конкретной технологии.

I 'Буду рад, если вы поможете мне с общим дизайном системы.

Большое спасибо!

Answer 1

Некоторые дополнительные мысли:

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

2. Возможно, вы захотите разделить вашу архитектуру с помощью какой-то длительной очереди между рабочими.

3. Обычно пульс используется с таймаутами и перезапусками.

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

Answer 2

Как сказал Питер, это действительно зависит от варианта использования.Некоторые общие замечания:

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

2. Если B зависит от A и A не работает, B можетне работает и все тут.Может перезапустить А?Может быть, вы можете сделать регулярную проверку здоровья на нем.

3. Если конечный работник нуждается в результатах A, B и C, как он будет обрабатываться, если C не доступен?Если это возможно, он может сохранить результаты A и B, установить таймер, и, если это произойдет без прибытия C, продолжить.