Опишите ваш опыт работы с Kafka или другими брокерами сообщений. Какие были объемы данных и с какими задачами вы сталкивались?

Ответ

Я использовал Apache Kafka в системе для обработки потока событий в реальном времени.

Основные показатели нагрузки:

Пропускная способность: В среднем 50-100 тысяч сообщений в секунду (RPS), с пиками до 200k.
Размер сообщений: Небольшие, в среднем 1-2 КБ (сериализованные в Protobuf).
Скорость потока данных: ~100-200 МБ/с.
Задержка (End-to-end latency): Старались удерживать в пределах 50-100 мс.

Ключевые аспекты и решения:

Конфигурация топиков: Основные топики имели 32 партиции для распараллеливания обработки и replication-factor=3 для обеспечения отказоустойчивости.
Мониторинг: Ключевым элементом был мониторинг. Мы использовали Prometheus и Grafana для отслеживания:
- Consumer Lag — главный показатель того, что консьюмеры справляются с нагрузкой.
- MessagesInPerSec — скорость поступления сообщений.
- Состояние брокеров (CPU, disk I/O).
```
// Пример метрики для отслеживания лага консьюмера
prometheus.NewGaugeVec(prometheus.GaugeOpts{
    Name: "kafka_consumer_group_lag",
    Help: "Kafka consumer group lag for a topic/partition",
}, []string{"topic", "partition"})
```
Гарантии доставки: Для критически важных данных мы настраивали продюсеров на acks=all и использовали идемпотентные продюсеры (enable.idempotence=true) для обеспечения гарантии доставки at-least-once и избежания дублей при повторных отправках.
Масштабирование консьюмеров: Количество инстансов сервиса-консьюмера в Consumer Group масштабировалось в соответствии с количеством партиций в топике для максимальной утилизации.