Полный отказ от ZooKeeper, изменение протокола перебалансировки потребителей, защита транзакций на стороне сервера, ELR-реплики и другие важные новинки Apache Kafka 4.0.
Главные изменения в брокерах, продюсерах и потребителях Apache Kafka 4.0
Несколько дней назад, 18 марта 2025 года вышел мажорный релиз Apache Kafka 4.0 – первый крупный выпуск, работающий полностью без Apache ZooKeeper. Работая в режиме KRaft по умолчанию, Kafka упрощает развертывание и управление, устраняя сложность поддержки внешнего компонента. Это изменение значительно снижает эксплуатационные расходы, повышает масштабируемость и оптимизирует административные задачи. Поскольку режим ZooKeeper полностью удален в выпуске 4.0, необходимо обновить версии программного обеспечения и метаданных хотя бы до версии 3.3.x, где впервые режим KRaft считается готовым к производству. Для кластеров в режиме KRaft с версиями старше 3.3.x рекомендуется обновление до 3.9.x перед 4.0.x. Кластеры в режиме ZooKeeper должны быть переведены в режим KRaft , прежде чем их можно будет обновить до 4.0.x.
Для постепенного обновления следует делать это по одному брокеру за раз, сперва выключив его, а потом перезапустив. После проверки поведения и производительности всего кластера надо завершить обновление, запустив
bin/kafka-features.sh --bootstrap-server localhost:9092 upgrade --release-version 4.0
Понижение метаданных кластера не поддерживается в этой версии, поскольку в ней есть изменения метаданных. Каждая MetadataVersion имеет логический параметр, который указывает, есть ли изменения метаданных. Кроме этого, еще существенными обновлениями в релизе 4.0 по брокерам, контроллерам, продюсерам и потребителям являются следующие:
- изменение протокола перебалансировки потребителей, который повышает стабильность и производительность групп потребителей, одновременно упрощая клиентов. Новый протокол включен по умолчанию на стороне сервера. Потребители должны включить его, установив protocol=consumer.
- защита транзакций на стороне сервера, которая снижает вероятность зомби-транзакций во время сбоев продюсера. О транзакциях в Kafka мы уже рассказывали здесь. Исключения TransactionAbortableException и TimeoutException улучшают обработку ошибок в транзакционных операциях, четко указывая сценарии, когда транзакции должны быть прерваны из-за ошибок. TimeoutException указывает на то, что транзакционная операция истекла по времени. Учитывая риск дублирования сообщений при повторных попытках операций после тайм-аута, что нарушает семантику exactly once, приложения-продюсеры могут рассматривать тайм-ауты как причины для прерывания текущей транзакции. TransactionAbortableException введено для сигнализации об ошибках, которые должны привести к прерыванию транзакции, чтобы обеспечить ее целостность.
- очереди – группы общего доступа как способ обеспечения совместного потребления с использованием топиков Kafka. Можно представить группу общего доступа как эквивалент долговременной общей подписки. Впервые об этой новой функции мы писали здесь. Это обновление отражено и в API администрирования: в Kafka Admin Client добавлены новые типы групп – consumer (для обычных потребителей) и share (для групп общего доступа). Соответственно, обновлены CLI-инструменты kafka-consumer-groups.sh и kafka-share-groups.sh, которые позволяют просматривать все группы в кластере, а также их типы и протоколы, предоставляя точную информацию даже в случае сбоя API Admin Client.
- реплики приемлемого лидера (ELR, Eligible Leader Replicas) – подмножество реплик ISR, гарантированно имеющих полные данные вплоть до верхней отметки. ELR безопасны для выборов лидера, предотвращая потерю данных. Также добавлено предварительное голосование для сокращения ненужных выборов лидера KRaft. Это снижает вероятность сбоя из-за потери доступности одного из узлов кластера или временных сетевых проблем. Подробнее о том, зачем это нужно, мы разбирали в этом материале про дилемму CAP-теоремы в Kafka.
- новый параметр сброса смещения потребителей на основе длительности, чтобы потреблять данные с определенного момента, если конфигурация offset.reset установлена в значение none или текущее смещение больше не существует на сервере. Это позволяет избежать повторной обработки огромных объемов данных из ранних смещений.
Другие важные обновления мажорного релиза
Еще в новом релизе улучшены возможности администрирования платформы потоковой передачи событий. В частности, теперь операторы кластера с помощью плагина могут собирать напрямую от брокеров метрики клиентов, т.е. приложений-продюсеров и потребителей, включая метрики уровня приложения для встроенных клиентов, таких как Kafka Streams, а также метрики, специфичные для приложения. Этот KIP представляет способ для приложений, использующих клиенты Kafka, включать свои собственные метрики вместе с существующими метриками клиента.
Кроме того, теперь приложения-клиенты могут перезагружать данные на основе тайм-аута или кода ошибки. Это повышает устойчивость клиента Kafka, проактивно запуская перезагрузку метаданных, когда в течение периода тайм-аута не происходит никаких обновлений, и позволяя серверам явно сигнализировать клиентам о перезагрузке. Такое изменение устраняет риск устаревания метаданных у клиентов в случае недоступности всех брокеров.
Вместо библиотеки логирования Log4j теперь используется Log4j2. Поддержка Log4j пока продолжается, но с ограничениями. Для автоматического преобразования файлов конфигурации Log4j в формат Log4j2 можно использовать инструмент log4j-transform-cli. Пользователи также могут продолжать использовать свои конфигурации Log4j, но с определенными ограничениями.
В Kafka Streams теперь можно извлекать внешние ключи напрямую из ключей и значений записей KTable, устраняя необходимость дублировать ключи в значениях для соединений с внешним ключом. Это улучшение упрощает соединения, снижает накладные расходы на хранение и упрощает разработку. Также разработчик теперь может настраивать обертку процессора в Kafka Streams, используя интерфейс ProcessorWrapper, чтобы реализовать настраиваемую логику вокруг API и DSL процессора. Это устраняет предыдущую избыточность и снижает накладные расходы на обслуживание, вызванные ручной интеграцией логики в каждый процессор по отдельности.
Кроме того, теперь можно управлять обработкой ошибок, указав параметры выполнения повторных попыток благодаря добавлению новой опции RETRY в ProductionExceptionHandler. Наконец, как уже было отмечено ранее, мониторинг метрик Kafka Streams стал проще: теперь есть метрика состояния для каждого StreamThread и самого экземпляра клиента, что обеспечивает подробную наблюдаемость приложения.
В Kafka Connect удалены избыточные конечные точки конфигураций задач Connect. Например, для получения данных о задачах коннектора вместо GET-запроса к /connectors/{connector}/tasks-config в релизе 4.0 используется GET-запрос к /connectors/{connector}/tasks.
Разрешена репликация внутренних топиков пользователя. Ранее MirrorMaker 2 автоматически исключал топики, имена которых заканчивались на .internal или -internal, неправильно классифицируя их как внутренние. Из-за этого было невозможно было автоматическими средствами реплицировать топики, названия которых соответствовали этому шаблону. Теперь есть настраиваемая опция, которая позволяет пользователям реплицировать такие топики без необходимости реализации собственного кода. Также теперь можно отключить репликацию топиков heartbeat в MirrorSourceConnector, что вызывало проблемы, когда несколько коннекторов с разными конфигурациями реплицировали топики между одними и теми же кластерами, излишне дублируя данные.
Наконец, обновлено API Jakarta EE и JavaEE 10, а также Java 17 теперь стала минимальной версией, поддерживаемой в Kafka 4.0.
Подробный разбор этих и других интересных новинок свежего релиза читайте в наших новых статьях.
Научитесь администрированию и эксплуатации Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники