Apache Kafka
Тема дорожной карты · DevOps Engineer
Apache Kafka — распределённая платформа стриминга событий, изначально разработанная в LinkedIn. По сути это отказоустойчивый append-only лог, разбитый на партиции и реплицируемый между узлами кластера. Producer'ы пишут события в topic, consumer'ы читают их по своему offset'у, при этом сохранённые события могут быть перечитаны позже — это не классическая очередь, а полноценный event log. Kafka — индустриальный стандарт для event-driven архитектур с большой нагрузкой: миллионы событий/сек, петабайты истории, тысячи consumer'ов.
Как это работает
Topic делится на N partitions, каждая партиция — упорядоченный лог. Producer пишет в партицию по ключу (hash(key) % N) или round-robin без ключа. Каждая партиция реплицируется на M узлов: один — leader (принимает запись), остальные — followers (читают). При падении leader'а один из followers становится новым leader'ом — kafka гарантирует, что подтверждённые записи не теряются (при acks=all). Consumer'ы объединяются в consumer groups: партиции разделяются между членами группы, каждое сообщение обрабатывается одним consumer'ом из группы. Сохранение события — по retention-policy (например, 7 дней или 1 ТБ на partition), после чего старое удаляется или компактируется по ключу (log compaction).
Когда применять
Используйте Kafka когда: пишете event-driven систему с десятком+ сервисов; нужна replay-возможность (новый сервис подключается и читает историю); объём событий измеряется в миллионах/сек (real-time analytics, IoT, метрики); нужно audit-логирование всех бизнес-событий (event sourcing). Не нужен Kafka когда: всего пара сервисов и тысячи событий/день (RabbitMQ проще); нужна сложная маршрутизация на стороне брокера (Kafka не делает routing — это работа consumer'а); нет команды с опытом эксплуатации distributed-логов (Kafka — серьёзный operational overhead, особенно ZooKeeper-зависимости в старых версиях).
Типичные ошибки
Грабли: писать с acks=0 или acks=1 (потеря при падении leader'а — всегда используйте acks=all в продакшене); один topic на всё (потеря изоляции, hot partition); ключ партиционирования = user-id с очень неравномерным распределением (90% событий идут в одну партицию — hot-spotting); consumer не коммитит offset вовремя (после падения переобрабатывает 10 минут истории); забыли мониторить consumer lag (отставание копится, alert'ы не настроены); ZooKeeper в проде без HA-cluster (в 3.x+ переходите на KRaft mode без ZooKeeper).