Номер потока запроса KSQL

Да, вы можете указать свойство ksql-streams-num-streams-threads. Подробнее об этом можно прочитать здесь.

Теперь это количество потоков KSQL Streams, в которых выполняется потоковая обработка для этого конкретного экземпляра KSQL. Это важно для вертикального масштабирования, потому что у вас может быть достаточно вычислительных ресурсов на вашем компьютере для обработки большего количества потоков, и, следовательно, вы можете выполнять больше работы, обрабатывая свои потоки на этой конкретной машине.

Если у вас есть емкость (например, ядра ЦП), тогда у вас должно быть больше потоков, чтобы на этом экземпляре можно было запланировать больше задач Stream и, следовательно, иметь дополнительные возможности распараллеливания на вашем экземпляре или кластере KSQL (если у вас более одного экземпляра).

Что вы должны понимать с Kafka, Kafka Streams и KSQL, так это то, что горизонтальное масштабирование происходит с двумя основными концепциями:

1. Приложения Kafka Streams (такие как KSQL) могут распараллеливать работу в зависимости от количества тематических разделов kafka. Если у вас есть 3 раздела и вы запускаете 4 экземпляра KSQL (то есть на разных серверах), то один из них не будет работать с потоком, который вы создаете поверх этой темы. Если у вас одна и та же тема с 3 разделами и у вас только 1 сервер KSQL, он будет делать всю работу для 3 разделов.
2. Когда вы добавляете новый экземпляр своего приложения Kafka Stream Application (в вашем случае KSQL), и он присоединяется к вашему кластеру, обрабатывающему ваши потоки и таблицы KSQL, этот конкретный экземпляр присоединится к группам потребителей, потребляющим эти темы, и немедленно начнет разделять нагрузку с другие экземпляры при наличии доступных разделов, которые другие экземпляры могут разгрузить (запуск перебалансировки группы потребителей). То же самое произойдет, если вы отключите экземпляр ... другие экземпляры воспользуются слабиной и начнут обрабатывать разделы, которые обрабатывал удаленный экземпляр.

При сравнении с вертикальным масштабированием (т. Е. Добавлением дополнительной емкости и потоков в экземпляр KSQL) горизонтальное масштабирование делает то же самое, добавляя те же вычислительные ресурсы к другому экземпляру приложения на другом компьютере. Вы можете понять модель потокового приложения Kafka Stream (с одним или несколькими экземплярами приложения на одной или нескольких машинах) здесь:

Я попытался упростить его, но вы можете прочитать об этом больше на KSQL Страница планирования емкости и сообщение в блоге Confluent Kafka Streams Elastic Scale

Важные аспекты масштабирования / масштабирования жизненного цикла приложений Kafka Streams (и KSQL) можно лучше понять следующим образом:

1. Один экземпляр работает с 4 разными разделами

2. Три экземпляра работают с 4 разными разделами (один из них работает с 2 разными разделами)

3. Экземпляр только что покинул группу, теперь два экземпляра работают в 4 разных разделах, идеально сбалансированных (по 2 раздела в каждом)

(Изображения из единого блога)