Kafka cluster #

• broker
  • отвечает за хранение данных (в бинарном виде)
  • не знаком со внутренней структурой хранимых данных
  • топик - сущность для логического разделения хранимых данных:
    • на уровне топика можно задать ограничения на:
      • объём и/или возраст хранимых данных (retention.bytes, retention.ms)
      • количество реплик данных (replication factor)
      • максимальный размер одного сообщения (max.message.bytes)
      • минимальное число согласованных реплик, при котором можно будет записать данные (min.insync.replicas)
      • и многое другое
    • разбивается на партиции - сущность, непосредственно содержащая сообщения
      • распределяются по брокерам равномерно (насколько это возможно), что позволяет масштабировать нагрузку на RW в один топик
      • на диске хранится в виде файлов-сегментов с дефолтным размером в 1GB (log.segment.bytes)
      • данные из партиции можно удалить только целым сегментом (не активным)
      • распределение событий (сообщений) по партициям:
        • нет ключа - round robin (с потерей упорядоченности)
        • есть ключ - murmurHash(key) (с сохранением упорядоченности)
      • в рамках одной партиции может быть гарантирован порядок событий
• zookeeper
  • роли:
    • хранилище метаданных
    • координатор кластера
  • в том числе хранит информацию о:
    • состоянии брокеров
    • том, какой брокер является контроллером
    • синхронизированы ли партиции с репликами
    • распределении топиков и партиций по брокерам
    • если replication factor > 1:
      • какая партиция лидер (именно в нее будет идти RW)
  • в старых версиях также хранил оффсеты (сейчас перенесены в топик __consumer_offsets)
  • при потере, данные с большой долей вероятности превратятся в фарш
• producer
  • сервис, который непосредственно пишет данные в Kafka
  • отправляет KV-сообщения в выбранный топик
• consumer
  • получает данные из Kafka
  • offset - номер последнего сообщения, полученного конкретным подписчиком
  • consumer group - логическое объединение подписчиков, в котором читаемые данные распределяются между участниками группы; позволяет масштабировать скорость чтения

Примеры использования очередей: #

• буфер перед БД (для стабилизации нагрузки и сохранения сообщений в случае недоступности бакенда)
• асинхронная передача сообщений между двумя сервисами (убирает необходимость долго поддерживать открытым синхронное соединение, например HTTP-сессию)
• общая шина для множества сервисов (к примеру, можно реализовать валидацию данных при передаче их из одного сервиса в другой)

Kafka #

Пишет и читает последовательно, следовательно можно безболезненно использовать с HDD, вместо SSD (требуется перепроверка).

Однако требовательна к CPU.

topic - непосредственно, очередь; может быть разделен на партиции (до 50 штук), каждая из которых лежит на отдельной ноде.

При записи в топик, данные распределяются по партициям равномерно (round robin).

Kafka vs RabbitMQ