> Где и как применялась Kafka (Go)

Уровень: senior · Роль: backend · Категория: Технические вопросы

Компании: Автомакон

Стек: Go

> Пример ответа

Короткий ответ

Kafka применяется как распределённая платформа потоковой передачи событий. Основные сценарии: построение event-driven архитектур, обмен данными между микросервисами, стриминговая обработка (Kafka Streams, ksqlDB), логирование и метрики, CDC (change data capture), интеграция разнородных систем. В Go чаще всего используется через клиентские библиотеки (segmentio/kafka-go, confluent-kafka-go) для продюсирования и консьюминга сообщений, а также для реализации паттернов outbox, CQRS и event sourcing.

Подробное объяснение

Kafka - это распределённый commit log, который хранит упорядоченные последовательности сообщений в топиках. Ключевые абстракции: topic, partition, offset, consumer group. Partition - единица параллелизма: внутри партиции гарантирован порядок, между партициями - нет. Consumer group позволяет горизонтально масштабировать потребление: каждая партиция назначается ровно одному консьюмеру из группы.

Применение по областям:

Event-driven архитектура: сервисы публикуют события (order.created, payment.succeeded) и реагируют на события других сервисов. Это даёт слабую связанность и асинхронность.
Интеграция систем: Kafka выступает шиной данных между legacy-системами, базами данных и новыми сервисами. Например, CDC через Debezium читает изменения из PostgreSQL и пишет их в Kafka.
Стриминговая обработка: Kafka Streams позволяет выполнять windowed-агрегации, joins, фильтрацию прямо в Kafka, без отдельного стримингового движка.
Логирование и метрики: Kafka используется как высокопроизводительный буфер для сбора логов (аналог Flume, но надёжнее) и метрик с последующей выгрузкой в ClickHouse, Elasticsearch, Prometheus.
Outbox pattern: в транзакции с бизнес-данными пишется запись в outbox-таблицу, отдельный процесс читает её и публикует в Kafka. Это гарантирует атомарность между БД и событием.
Event sourcing: Kafka хранит полную историю изменений агрегатов, что позволяет восстанавливать состояние и строить read-модели.

В Go Kafka применяется в микросервисах для асинхронной коммуникации, обработки фоновых задач (например, отправка email, генерация отчётов), синхронизации данных между сервисами. Важно понимать модель доставки: at-least-once по умолчанию, exactly-once возможен с идемпотентным продюсером и транзакциями, но это дороже.

На практике

При проектировании с Kafka нужно учитывать:

Партиционирование: ключ сообщения определяет партицию. Если нужен глобальный порядок - одна партиция, но это убивает параллелизм. Компромисс: партиционировать по бизнес-ключу (user_id, order_id).
Retention и compaction: по умолчанию Kafka хранит сообщения по времени или размеру. Для event sourcing нужен compacted topic, где хранится последнее значение по ключу.
Consumer offset management: в Go при ручном управлении оффсетами нужно коммитить после успешной обработки, иначе при рестарте будут дубли. Автокоммит удобен, но опасен.
Backpressure: если консьюмер медленный, партиции накапливаются. Нужно следить за consumer lag и масштабировать консьюмеров или увеличивать число партиций.
Идемпотентность обработки: из-за at-least-once доставки обработчик должен быть идемпотентным (например, по ключу события).
Схемы сообщений: использовать Avro или Protobuf с Schema Registry, чтобы эволюционировать схемы без поломки консьюмеров.

В Go типичная архитектура: сервис-продюсер публикует события в Kafka, сервис-консьюмер читает их в фоновых горутинах, обрабатывает и коммитит оффсеты. Для балансировки нагрузки между инстансами используется consumer group - Kafka сам перераспределяет партиции при добавлении/удалении консьюмера.

Пример кода

Пример продюсера и консьюмера на Go с библиотекой segmentio/kafka-go:

GO
// Продюсер
package main

import (
    "context"
    "fmt"
    "time"

    "github.com/segmentio/kafka-go"
)

func main() {
    writer := kafka.NewWriter(kafka.WriterConfig{
        Brokers:  []string{"localhost:9092"},
        Topic:    "orders",
        Balancer: &kafka.Hash{},
    })
    defer writer.Close()

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    err := writer.WriteMessages(ctx, kafka.Message{
        Key:   []byte("user-123"),
        Value: []byte(`{"order_id": "o-1", "amount": 100}`),
    })
    if err != nil {
        fmt.Println("failed to write:", err)
    }
}

GO
// Консьюмер
package main

import (
    "context"
    "fmt"
    "time"

    "github.com/segmentio/kafka-go"
)

func main() {
    reader := kafka.NewReader(kafka.ReaderConfig{
        Brokers:  []string{"localhost:9092"},
        Topic:    "orders",
        GroupID:  "order-processor",
        MinBytes: 10e3,
        MaxBytes: 10e6,
    })
    defer reader.Close()

    for {
        msg, err := reader.ReadMessage(context.Background())
        if err != nil {
            fmt.Println("read error:", err)
            continue
        }
        // Обработка сообщения
        fmt.Printf("received: key=%s value=%s\n", msg.Key, msg.Value)

        // Коммит оффсета происходит автоматически после ReadMessage,
        // но для надёжности лучше коммитить вручную после обработки
    }
}

Важно: в production не использовать автокоммит без понимания рисков, лучше коммитить вручную через reader.CommitMessages(ctx, msg) после успешной обработки.

Как отвечать на собеседовании

Начни с краткого определения: Kafka - распределённый commit log для потоковых событий. Затем перечисли основные сценарии применения: event-driven архитектура, интеграция систем, стриминговая обработка, CDC, outbox. Для каждого сценария приведи конкретный пример из практики.

Упомяни ключевые концепции: partition, offset, consumer group, at-least-once. Покажи понимание trade-off: партиционирование vs порядок, надёжность vs производительность.

Если спрашивают про Go - расскажи про библиотеки, ручное управление оффсетами, идемпотентность обработчиков. Приведи пример из реального проекта: как вы использовали Kafka для асинхронной обработки заказов или синхронизации данных.

Заверши рассуждением о том, когда Kafka не подходит: для простой очереди задач лучше RabbitMQ, для высоконагруженного RPC - gRPC.

Что проверяет интервьюер

Интервьюер оценивает:

Понимание модели Kafka: топики, партиции, оффсеты, consumer group.
Умение обосновать выбор Kafka под конкретную задачу.
Знание гарантий доставки и их последствий.
Практический опыт: как вы решали проблемы с lag, дубликатами, порядком сообщений.
Понимание интеграции Kafka с Go: библиотеки, паттерны обработки.
Умение видеть ограничения Kafka и альтернативы.

Типичные ошибки

Путаница между Kafka и классической очередью: Kafka не удаляет сообщения после чтения, retention настраивается отдельно.
Утверждение, что Kafka гарантирует глобальный порядок - порядок только в пределах партиции.
Игнорирование at-least-once: обработчик должен быть идемпотентным, иначе будут дубли.
Автокоммит оффсетов без обработки ошибок - потеря сообщений при падении.
Непонимание партиционирования: выбор ключа влияет на распределение нагрузки.
Использование Kafka для простых задач, где достаточно RabbitMQ - избыточная сложность.
Отсутствие схемы сообщений - ломка консьюмеров при изменении формата.