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

Question

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

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

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

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

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

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

Я был бы рад, если бы вы могли помочь мне с общим дизайном системы.

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

Answer 1

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

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

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

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

Answer 2

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

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

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

3. Распространено использовать сердцебиение с таймаутами и перезапусками.

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