TestiquaQA Academy OS
…
Архитектура Kafka: брокеры, топики, партиции и логи · 12 мин
🎯 Цель урока

Освоить фундаментальные концепции архитектуры Apache Kafka, необходимые для грамотного тестирования event-driven систем. Вы поймёте роль брокеров, структуру топиков и партиций, а также принципы хранения данных в виде append-only логов. Понимание этих основ позволит вам правильно настраивать тестовую среду, формулировать проверки и интерпретировать результаты тестов.

Контекст

Apache Kafka — это распределённая платформа потоковой передачи данных, построенная на принципе append-only журнала. В отличие от традиционных очередей сообщений, Kafka сохраняет все события на диске и позволяет потребителям читать их в любой момент в пределах периода хранения. Для QA-инженера понимание физического устройства кластера — обязательное условие грамотного тестирования: вы должны знать, где хранится сообщение, кто отвечает за его репликацию и что произойдёт при сбое брокера.

  • Кластер Kafka состоит из одного или нескольких брокеров — серверов, которые принимают, хранят и отдают сообщения
  • Топик — это именованный канал для сообщений; он разбивается на партиции для параллельной обработки
  • Каждая партиция — это упорядоченный append-only лог; сообщения получают монотонно возрастающий offset
  • ZooKeeper (до Kafka 3.x) или KRaft управляет метаданными кластера: конфигурацией топиков, членством брокеров и выборами лидеров
  • Репликация обеспечивает отказоустойчивость: каждая партиция имеет одного лидера и несколько фолловеров (ISR — In-Sync Replicas)

Рабочий алгоритм

Чтобы эффективно тестировать Kafka-системы, начните с изучения топологии кластера и убедитесь, что тестовая среда корректно отражает продакшн-конфигурацию. Следующие шаги помогут вам систематически проверить корректность архитектуры.

  • Проверьте количество брокеров командой `kafka-broker-api-versions.sh --bootstrap-server localhost:9092`
  • Выведите список топиков и их конфигурацию: `kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic <name>`
  • Убедитесь, что фактор репликации и количество партиций соответствуют требованиям SLA
  • Проверьте состояние ISR: все партиции должны иметь In-Sync Replicas, равные replication factor
  • Визуально проверьте распределение лидеров по брокерам — оно должно быть равномерным
  • Задокументируйте конфигурацию топиков как часть тест-плана для воспроизводимости результатов

Пример из практики

Команда тестировала микросервис обработки платёжных событий. После деплоя в staging-среде QA-инженер обнаружил, что топик `payments` создан с одной партицией и replication factor=1, тогда как продакшн использует 12 партиций и RF=3. Это привело к ложно положительным результатам нагрузочных тестов и пропущенным дефектам, связанным с параллельной обработкой.

  • Несоответствие количества партиций скрыло состояния гонки при параллельной обработке сообщений одного ключа
  • RF=1 означал отсутствие репликации и невозможность протестировать failover-сценарии
  • После исправления конфигурации тесты выявили дефект в логике partition key — сообщения одного пользователя попадали в разные партиции
  • Введено правило: конфигурация топиков в staging должна совпадать с prod минимум по количеству партиций и RF

Частые ошибки

Многие QA-инженеры допускают одни и те же архитектурные ошибки при настройке тестовой среды Kafka. Знание этих ловушек позволит вам избежать ложных результатов и потраченного времени.

  • Тестирование с single-broker кластером при prod-конфигурации из трёх и более брокеров — скрывает проблемы репликации и выборов лидера
  • Использование auto.create.topics.enable=true в тестах — топики создаются с дефолтными параметрами, не соответствующими реальным
  • Игнорирование retention.ms при тестировании — сообщения могут удалиться раньше, чем consumer их прочтёт
  • Смешивание данных разных тестов в одном топике без изоляции — приводит к непредсказуемым результатам
  • Не проверять распределение по партициям после тестов — неравномерность может указывать на проблемы с partition key

✅ Самопроверка

1Что такое offset в Kafka и почему он важен для тестирования?
Offset — это монотонно возрастающий числовой идентификатор сообщения внутри партиции. Он важен для тестирования, потому что позволяет точно воспроизвести состояние consumer, проверить, что все сообщения были обработаны, и диагностировать потерю или дублирование сообщений.
2Почему тестирование с replication factor=1 может дать ложно положительные результаты?
При RF=1 не существует репликации, поэтому тесты не смогут выявить проблемы с failover, потерей данных при падении брокера и задержками, связанными с синхронизацией ISR. Продакшн-поведение при сбоях будет принципиально отличаться от наблюдаемого в тестах.
3Как проверить, что лидеры партиций равномерно распределены по брокерам кластера?
Выполните `kafka-topics.sh --bootstrap-server <host> --describe --topic <name>` и проверьте поле Leader для каждой партиции. Каждый брокер должен быть лидером примерно одинакового числа партиций. Для автоматической балансировки используйте `kafka-leader-election.sh --election-type PREFERRED`.