Kafka Streams уравновешивает всплески задержки на высокопроизводительных сервисах kafka-streams

Question

мы начинаем работать с потоками Kafka, наш сервис очень простой пользователь без сохранения состояния.

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

Один из первых тестов, которые мы провели, - небольшая группа потребителей, в которой 4 потребителя обрабатывают небольшое количество сообщений (1 КБ / с) и убивают одно из них; менеджер кластера (в настоящее время AWS-ECS, вероятно, вскоре переходит на K8S) запускает новый. Таким образом, выполняется более одного ребалансирования.

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

Мы также провели тесты с некоторыми непрерывными обновлениями кода, и результаты хуже, поскольку наше развертывание не подготовлено для сервисов Kafka, и мы инициируем множество ребалансировок. Надо над этим поработать, но интересно, какие стратегии используют другие люди для развертывания / автоматического масштабирования кода с минимальными задержками.

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

Мы используем все конфигурации по умолчанию, без настройки.

Нам нужно улучшить этот всплеск задержки во время восстановления баланса. Может, кто-нибудь подскажет, как с этим работать? Достаточно ли трогательных конфигураций? Нужно ли использовать какой-то конкретный раздел Asignor? Реализовать наш собственный?

Каков рекомендуемый подход к развертыванию / автоматическому масштабированию кода с минимально возможными задержками?

Наша версия Kafka - 1.1.0, после просмотра библиотек, найденных, например, kafka / kafka_2.11-1.1.0-cp1.jar, мы установили платформу Confluent 4.1.0. В потребительской части мы используем Kafka-streams 2.1.0.

Спасибо, что прочитали мой вопрос и ваши ответы.

Answer 1

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

Для этого:

В Kafka 1.1, чтобы уменьшить ненужную перебалансировку, вы можете увеличить тайм-аут сеанса группы, чтобы координатор стал «менее чувствительным» к участникам, не отвечающим на тактовые импульсы - обратите внимание, что мы отключили запрос left.group с 0.11. 0 для потребителей потоков (https://issues.apache.org/jira/browse/KAFKA-4881), поэтому, если у нас более длительное время ожидания сеанса, член, покидающий группу, не будет инициировать перебалансировку, хотя повторное объединение участника все равно вызовет один. Тем не менее, на одно перебалансирование меньше, чем ничего.

Однако в грядущей Kafka 2.2 мы значительно улучшили сценарии оптимизации перебалансировки, в первую очередь зафиксированные в KIP-345 (https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances).. При этом гораздо меньшее количество перебалансировок будет вызвано скользящим отскоком, с В KIP-345 введены разумные настройки конфигурации, поэтому я настоятельно рекомендую вам обновить систему до версии 2.2 и посмотреть, поможет ли она вашему делу