В Kafka тема может содержать множество разделов, между которыми распределяются записи.
Разделы — это единицы параллелизма.
В общем, чем больше разделов, тем выше пропускная способность.
Однако при наличии большого количества разделов в кластере Kafka следует учитывать некоторые факторы.
Я рад сообщить, что в Apache Kafka, начиная с версии 1.1.0, количество разделов, которые может поддерживать один кластер Kafka, было значительно увеличено с точки зрения развертывания и доступности.
Чтобы понять это улучшение, будет полезно просмотреть некоторую базовую информацию о лидерах разделов и контроллере.
Во-первых, каждый раздел может иметь несколько реплик для большей доступности и отказоустойчивости.
Одна из реплик назначается ведущей, и все клиентские запросы обслуживаются этой ведущей репликой.
Во-вторых, один из брокеров в кластере выступает в роли контроллера, управляющего всем кластером.
В случае сбоя брокера контроллер несет ответственность за выбор новых лидеров разделов на вышедшем из строя брокере.
Брокер Kafka по умолчанию выполняет контролируемое завершение работы, чтобы свести к минимуму перебои в обслуживании клиентов.
Управляемое отключение проходит следующие этапы.
(1) Сигнал SIG_TERM отправляется брокеру для завершения операции.
(2) Брокер отправляет запрос контроллеру, уведомляя его о готовности отключиться.
(3) Затем контроллер меняет лидеров разделов этого брокера на других брокеров и сохраняет эту информацию в ZooKeeper. (4) Контроллер отправляет информацию о новых лидерах другим брокерам в кластере.
(5) Контроллер отправляет положительный ответ на запрос брокеру завершения, и брокер наконец завершает свой процесс.
Таким образом, это никак не влияет на клиентов, поскольку их трафик уже перенаправлен на других брокеров.
Этот процесс изображен на рисунке 1. Обратите внимание, что этапы (4) и (5) могут выполняться параллельно.
Рис.
1. (1) Инициировать отключение брокера 1; (2) брокер 1 отправляет запрос на управляемое завершение работы контроллеру брокера 0; (3) контролер записывает новых лидеров в ZooKeeper; (4) контроллер отправляет информацию о новых лидерах брокеру 2; (5) контроллер отправляет положительный ответ брокеру 1. До Kafka 1.1.0 во время контролируемого завершения работы контроллер перемещал лидеров по одному разделу за раз.
Для каждого раздела контроллер выбирает нового лидера, параллельно записывает его в ZooKeeper и отправляет нового лидера другим брокерам посредством удаленного запроса.
У этого процесса есть несколько недостатков.
Во-первых, синхронная запись в ZooKeeper имеет более высокую задержку, что замедляет процесс контролируемого завершения работы.
Во-вторых, отправка нового лидера по одному разделу за раз добавляет множество небольших удаленных запросов к каждому брокеру, что может вызвать задержку в обработке новых лидеров.
Начиная с Kafka 1.1.0, контролируемое завершение работы происходит значительно быстрее.
Во-первых, запись в ZooKeeper использует асинхронный API. Вместо того, чтобы писать лидер для одного раздела, ждать завершения этого процесса, а затем писать следующий, контроллер асинхронно размещает лидеры для многих разделов в ZooKeeper, а затем ждет завершения процесса.
Это позволяет обрабатывать запросы в конвейере между брокером Kafka и сервером ZooKeeper и снижает общую задержку.
Во-вторых, информация о новых лидерах рассылается пакетами.
Вместо одного удаленного запроса для каждого раздела контроллер отправляет один удаленный запрос с лидером от всех затронутых разделов.
Время обработки сбоев контроллера также было значительно улучшено.
Если происходит сбой контроллера, кластер Kafka автоматически выбирает в качестве контроллера другого брокера.
Прежде чем иметь возможность выбирать лидеров разделов, вновь назначенный контроллер должен загрузить состояние всех разделов в кластере из ZooKeeper. В случае серьезного сбоя контроллера окно недоступности раздела может длиться до тех пор, пока истечет срок сеанса ZooKeeper, а также время перезагрузки состояния контроллера.
Таким образом, сокращение времени перезагрузки состояния повышает доступность в этом редком случае.
До версии 1.1.0 Kafka использовал синхронный API ZooKeeper для перезагрузки.
Начиная с версии 1.1.0, он также заменен на асинхронный API для уменьшения задержки.
Мы провели тесты, чтобы оценить улучшение времени контролируемого выключения и перезагрузки контроллера.
Для обоих тестов мы загрузили набор из пяти узлов ZooKeeper на выделенные серверы.
Для первого теста мы подготовили кластер Kafka с пятью брокерами на отдельных серверах.
В этом кластере мы создали 25 000 тем, каждая тема имела один раздел и две реплики, в результате всего получилось 50 000 разделов.
Таким образом, на каждом брокере было по 10 000 разделов.
Затем мы измерили время, необходимое для контролируемого отключения.
Результаты представлены в таблице ниже.
| Версия | Кафка 1.0.0 | Кафка 1.1.0 |
|---|---|---|
| Контролируемое время отключения | 6,5 минут | 3 секунды |
Просто устранив накладные расходы на ведение журнала, мы сократили время контролируемого отключения с 6,5 минут до 30 секунд. Переход на асинхронный API ZooKeeper сократил это время до 3 секунд. Эти улучшения значительно сократили время, необходимое для перезагрузки кластера Kafka. Для второго теста мы подготовили еще один кластер Kafka, состоящий из пяти брокеров, создали 2000 топиков, каждый по 50 разделов и одну реплику.
Всего во всем кластере было 100 000 разделов.
Затем мы измерили время перезагрузки состояния контроллера и увидели 100% улучшение (время перезагрузки сократилось с 28 секунд в Kafka 1.0.0 до 14 секунд в Kafka 1.1.0).
Учитывая эти изменения, сколько разделов вы можете ожидать от Kafka? Точное количество зависит от таких факторов, как допустимое окно недоступности, задержка ZooKeeper, тип хранилища на брокере и т. д. Как правило, мы рекомендуем иметь до 4000 разделов на каждом брокере и до 200 000 разделов на кластер.
Основная причина ограничения на кластер — это необходимость подстраховаться на тот редкий случай серьезного сбоя контроллера, о котором мы писали выше.
Обратите внимание, что применимы и другие соображения, связанные с разделами, и вам может потребоваться дополнительная настройка конфигурации с использованием большего количества разделов.
Более подробную информацию вы найдете в КАФКА-5642 И КАФКА-5027 .
От редактора: Команда Слерма готовит подробный видеокурс по Apache Kafka. Спикеры: Анатолий Солдатов из Авито и Александр Миронов из Stripe. Вводные уроки уже доступно на Ютубе .
Полная версия курса выйдет 7 апреля 2021 года.
Теги: #программирование #ИТ-инфраструктура #Системное администрирование #kafka #Apache #apache kafka #topic #partition
-
Опыт Спасения Кластера Кассандра
19 Oct, 24 -
Старые Компоненты
19 Oct, 24 -
Физика Высоких Температур
19 Oct, 24 -
Мтт Меня Немного Удивил
19 Oct, 24
