Потоковая обработка
Apache Kafka: Архитектура
2010 год. LinkedIn обрабатывает 1 миллиард событий в день. Их система на Oracle и традиционных message queues (ActiveMQ) не справляется. Каждый сервис напрямую интегрирован с каждым другим - спагетти интеграций. Jay Kreps, Neha Narkhede и Jun Rao начинают разработку Kafka внутри LinkedIn. Название в честь Франца Кафки - 'система, оптимизированная для записи'. В 2011 году открытый исходный код. Сегодня Kafka обрабатывает более 7 триллионов сообщений в день только в LinkedIn. Uber, Netflix, Airbnb, Spotify - всё это работает на Kafka.
- **Uber**: GPS события от водителей (billions/day) -> Kafka -> real-time surge pricing
- **Netflix**: activity events (play, pause, seek) -> Kafka -> recommendation engine
- **Банки**: транзакции -> Kafka -> fraud detection в реальном времени (< 100ms)
- **LinkedIn**: change data capture (CDC) из PostgreSQL -> Kafka -> все зависимые сервисы
Kafka: distributed commit log как парадигма
В 2011 году Jay Kreps опубликовал пост 'The Log: What every software engineer should know about real-time data's unifying abstraction'. Ключевой инсайт: append-only log - универсальная абстракция для распределённых систем. Kafka реализует этот принцип: сообщения записываются только в конец лога, никогда не изменяются. Это позволяет горизонтальное масштабирование через партиционирование и репликацию. В 2014 году Kreps, Narkhede и другие основали Confluent для коммерциализации Kafka. В 2019 году Confluent валюировался в $4.5 млрд. Kafka изменил архитектуру enterprise систем так же, как MapReduce изменил batch processing.
Topics и Partitions
**Topic** - именованный поток сообщений. **Partition** - физическая единица хранения, append-only immutable log. Каждое сообщение в партиции имеет уникальный **offset** - позицию в логе.
**Выбор количества партиций:** Больше партиций = больше параллелизма = выше throughput. Но: больше файловых дескрипторов на брокере, дольше leader election при failover, больше overhead metadata. Правило: начать с throughput/100MB и умножить на safety factor. Для большинства топиков: 12-48 партиций.
Kafka топик 'payments' имеет 4 партиции. Транзакции одного пользователя должны обрабатываться в порядке. Как правильно настроить producer?
Replication и ISR
Каждая партиция реплицируется на несколько брокеров. **Leader** принимает все записи и чтения. **Followers** синхронно реплицируют данные. **ISR** (In-Sync Replicas) - подмножество реплик, которые не отстают от Leader.
**Leader Election при failover:** Если Leader падает, Kafka выбирает нового из ISR. Только реплики в ISR могут стать новым Leader (при unclean.leader.election.enable=false). Это гарантирует, что новый Leader имеет все подтверждённые сообщения. Failover занимает секунды, не минуты.
Kafka топик с replication.factor=3 и min.insync.replicas=2. Два из трёх брокеров недоступны. Что произойдёт с записью?
Consumer Groups и Offset Management
**Consumer Group** - группа consumer-ов, которые совместно обрабатывают партиции топика. Каждая партиция назначена только одному consumer-у в группе. Разные группы читают один топик независимо.
Kafka топик имеет 6 партиций. Consumer Group имеет 8 consumer-ов. Сколько consumer-ов будут активно обрабатывать сообщения?
Log Retention и Performance
Kafka хранит сообщения на диске в сегментных файлах. Сообщения не удаляются после потребления - только по retention policy. Это фундаментально отличает Kafka от традиционных очередей.
**Log Compaction vs Delete:** Delete retention удаляет старые сегменты полностью. Compaction (для топиков с ключами) хранит только последнее значение каждого ключа - как materialized view. Используется для event sourcing, CDC, configuration топиков.
Kafka - это просто продвинутый message broker, как RabbitMQ с персистентностью
Kafka - это distributed commit log. Принципиальные отличия: retention независимо от потребления, replay сообщений, partitioned parallelism, consumer group независимость.
RabbitMQ удаляет сообщение после подтверждения consumer-а. В Kafka сообщения хранятся по retention policy и можно читать их заново с любого offset. Это позволяет новым сервисам читать историю, реплей при ошибках, event sourcing паттерны.
Consumer Group 'reporting' начинает читать топик с retention.ms=604800000 (7 дней). Данные были записаны 10 дней назад. Что произойдёт?
Ключевые идеи
- **Topic + Partition**: топик делится на партиции - единицы параллелизма и масштабирования
- **Offset**: позиция сообщения в партиции - неизменяемый уникальный идентификатор
- **Replication**: каждая партиция имеет Leader и Followers. ISR (In-Sync Replicas) - реплики в актуальном состоянии
- **Consumer Group**: несколько consumer-ов обрабатывают партиции одного топика параллельно
- **Log Retention**: сообщения хранятся по времени или размеру, не удаляются после потребления
Вопросы для размышления
- Kafka гарантирует порядок внутри партиции, но не между партициями. Как это влияет на дизайн partition key для банковских транзакций?
- ISR (In-Sync Replicas) с acks=all гарантирует durability, но увеличивает latency. При каком сценарии можно использовать acks=1?
- Consumer Group позволяет горизонтальное масштабирование, но максимальный параллелизм = количество партиций. Почему нельзя иметь больше consumer-ов чем партиций?