Как операции с состоянием работают в потоках Kafka, когда есть несколько экземпляров потокового приложения? - PullRequest
Новая
       15

Как операции с состоянием работают в потоках Kafka, когда есть несколько экземпляров потокового приложения?

0 голосов
/ 18 января 2019

Как работают полные операции состояния в приложении Kafka Stream с несколькими экземплярами? Скажем так, у нас есть 2 темы с 2 разделами А и В. У нас есть потоковое приложение, которое использует обе темы, и есть объединение двух потоков.

Сейчас мы запускаем 2 экземпляра этого потокового приложения. Насколько я понимаю, каждому экземпляру будет назначен один из 2 разделов каждой темы.

Теперь, как будет происходить объединение, если присоединяемые сообщения используются различными экземплярами приложения? Я не могу обдумать это.

Хотя я тестировал его для небольшого потокового приложения, которое, кажется, работает правильно. Могу ли я всегда увеличивать количество экземпляров любого типа приложения, даже не задумываясь о типе топологии, определенной в потоковом приложении?

Есть ли какой-нибудь документ, который я могу пройти, чтобы понять детали его работы?

1 Ответ

0 голосов
/ 18 января 2019

Максимальной единицей параллелизма является количество разделов. Если вы запустите больше экземпляров, чем количество разделов, избыточные экземпляры будут простаивать.

Операция соединения должна соответствовать следующим требованиям:

  1. Входные данные должны быть разделены при объединении. Это означает, что входные темы, которые нужно объединить, должны иметь одинаковое количество разделов.

  2. Обе темы должны иметь одинаковую стратегию разделения, чтобы записи с одинаковыми ключами могли доставляться в одни и те же разделы. Если это не так, есть вероятность потерять записи.

Пример: если topic1 имеет 2 раздела, а topic2 имеет 3 раздела, Join(topic1,topic2) завершится ошибкой из-за неравных разделов. Как только вы переделите тему, допустим, 3. Теперь Join(topic1, topic2) будет работать. Вы можете максимально использовать 3 задачи для этой операции. Каждый раздел будет поддерживать свое состояние в государственном хранилище в виде внутренних тем. По умолчанию KStream использует RocksDB для хранения состояний.

Здесь вы можете увидеть, как обычно процесс работает для преобразования с сохранением состояния: enter image description here

Пожалуйста, обратитесь к ним для более подробной информации:

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+Internal+Data+Management https://docs.confluent.io/current/streams/developer-guide/dsl-api.html#streams-developer-guide-dsl-joins

...