Да, вы можете указать ksql-streams-num-streams-threads свойство. Вы можете прочитать больше об этом здесь .
Теперь это количество потоков KSQL, в которых происходит обработка потока для этого конкретного экземпляра KSQL. Это важно для вертикального масштабирования, потому что у вас может быть достаточно вычислительных ресурсов на вашем компьютере для обработки большего количества потоков и, следовательно, вы можете выполнять больше работы по обработке ваших потоков на этом конкретном компьютере.
Если у вас есть емкость (т. Е. Ядра ЦП), то у вас должно быть больше потоков, чтобы можно было запланировать больше потоковых задач для этого экземпляра и, следовательно, иметь дополнительную емкость параллелизации в вашем экземпляре или кластере KSQL (если у вас более одного экземпляр).
Что вы должны понять с Kafka, Kafka Streams и KSQL, так это то, что горизонтальное масштабирование имеет две основные концепции:
- Приложения Kafka Streams (такие как KSQL) могут парализовать работу на основе
по количеству разделов темы кафки. Если у вас есть 3 раздела
и вы запускаете 4 экземпляра KSQL (т. е. на разных серверах), тогда один из них не будет выполнять работу над потоком, который вы создаете поверх этой темы. Если у вас есть
та же тема с 3 разделами, и у вас есть только 1 сервер KSQL, он будет
делать всю работу для 3 разделов.
- Когда вы добавляете новый экземпляр вашего приложения Kafka Stream Application (в вашем случае KSQL) и он присоединяется к вашему кластеру, обрабатывающему ваши потоки и таблицы KSQL, этот конкретный экземпляр присоединится к группам потребителей, потребляющим для
эти темы и сразу же начать делиться нагрузкой с другими
экземпляры, пока есть доступные разделы, которые другие экземпляры могут разгрузить (вызывая перебалансировку группы потребителей). То же самое происходит, если вы выключаете экземпляр ... другие экземпляры обнаружат слабину и начнут обрабатывать разделы, которые обрабатывал удаленный экземпляр.
При сравнении с вертикальным масштабированием (т. Е. Добавлением большей емкости и потоков к экземпляру KSQL) горизонтальное масштабирование делает то же самое, добавляя одни и те же вычислительные ресурсы в другой экземпляр приложения на другом компьютере. Вы можете понять модель потоков приложений Kafka Stream (с одним или несколькими экземплярами приложения на одной или нескольких машинах) здесь:
Я попытался упростить его, но вы можете прочитать больше об этом на странице Планирование емкости KSQL и Сообщение в блоге о гибкой шкале упругих потоков Kafka
Важные аспекты жизненного цикла масштабирования / масштабирования приложений Kafka Streams (и KSQL) можно лучше понять следующим образом:
1. Один экземпляр работает на 4 разных разделах
2. Три экземпляра работают на 4 разных разделах (один из них
работает на 2 разных разделах)
3. Экземпляры только что покинули группу, теперь два экземпляра работают над 4
различные разделы, идеально сбалансированные (2 раздела для каждого)
( Изображения из слияния блога)