Apache Kafka — co to jest i jak działa?

7T/dzień

Wiadomości przetwarzanych przez LinkedIn (pierwotny twórca Kafka) dziennie

80%+

Firm Fortune 100 używa Apache Kafka wg Confluent Annual Report 2023

ms latencja

End-to-end latencja od producenta do konsumenta — Kafka jest optymalizowana pod przepustowość i niskie opóźnienie

Topic

Logiczny kanał wiadomości — jak temat w pub/sub. Producer publikuje, Consumer subskrybuje. Topic podzielony na partycje.

Analogia: Tabela w DB lub kanał w Slack

Partition

Fizyczny podział Topic — umożliwia równoległe przetwarzanie i skalowanie. Wiadomości w partycji są ordered. Liczba partycji = max parallelism.

Analogia: Pas ruchu na autostradzie

Offset

Sekwencyjny numer wiadomości w partycji (0, 1, 2...). Consumer śledzi swój offset — position w logu. Commitowanie offsetu = potwierdzenie przetworzenia.

Analogia: Zakładka w książce

Consumer Group

Logiczne grupy konsumentów współdzielących partycje Topicu. Każda partycja przypisana do jednego konsumenta w grupie. Wiele grup = wiele niezależnych subskrybentów.

Analogia: Dział firmy czytający te same maile

Broker

Serwer Kafka przechowujący partycje. Klaster składa się z wielu brokerów. Każdy broker jest Leaderem dla części partycji.

Analogia: Serwer pocztowy w systemie mail

Replication Factor

Liczba kopii każdej partycji na różnych brokerach. RF=3 oznacza 1 Leader + 2 Follower. Gwarantuje dostępność przy awarii brokerów.

Analogia: RAID dla dysków

Retention

Czas lub rozmiar przechowywania wiadomości. Domyślnie 7 dni. Kafka NIE usuwa wiadomości po dostarczeniu — consumer sam zarządza offsetem.

Analogia: Log serwera z rotacją

Schema Registry

Centralny rejestr schematów (Avro, Protobuf, JSON Schema). Zapewnia zgodność między producentami a konsumentami. Confluent Schema Registry = standard.

Analogia: Kontrakt API między serwisami

Event Sourcing

Kafka jako event log — każda zmiana stanu to event. Możliwość odtworzenia całej historii systemu od zera. Pattern: CQRS + Event Sourcing.

Real-time Analytics

Analiza strumieni danych na bieżąco — liczniki, metryki, dashboardy bez opóźnień. Kafka Streams lub Flink do transformacji.

Log Aggregation

Zbieranie logów z wielu mikroserwisów do jednego miejsca. Producer = agent logów, Consumer = Elasticsearch lub S3.

Microservices Integration

Asynchroniczna komunikacja między mikroserwisami przez zdarzenia zamiast REST/gRPC. Decoupling, fault isolation.

Change Data Capture (CDC)

Śledzenie zmian w bazie danych i przesyłanie ich do Kafki. Debezium = popularne narzędzie CDC dla PostgreSQL/MySQL.

Co to jest Apache Kafka?

Apache Kafka to open-source'owa, rozproszona platforma do strumieniowania zdarzeń (event streaming). Stworzona przez LinkedIn w 2010 roku, open-sourcowana przez Apache Software Foundation w 2011. Kafka umożliwia publishing i subscribing do strumieni rekordów (events), trwałe przechowywanie strumieni z określonym retention i przetwarzanie strumieni w czasie rzeczywistym. Kafka jest używana przez LinkedIn (7 trylionów wiadomości/dzień), Uber, Netflix, Airbnb, Twitter jako kluczowy element architektury.

Czym Kafka różni się od RabbitMQ?

Kafka vs RabbitMQ: Model — Kafka jest log-based (pull model, konsumenci sami pobierają), RabbitMQ jest message queue (push model, broker dostarcza). Retention — Kafka przechowuje wiadomości przez konfigurowalny czas (dni/tygodnie/indefinitely), RabbitMQ usuwa po dostarczeniu. Skalowalność — Kafka jest zoptymalizowana do wysokiej przepustowości (miliony msg/s przez partitioning), RabbitMQ łatwiejszy do skonfigurowania przy mniejszym wolumenie. Replay — Kafka umożliwia replay wiadomości (konsument może czytać od początku), RabbitMQ nie. Use case: Kafka dla high-throughput event streaming, RabbitMQ dla task queues i RPC.

Jak działa Kafka Producer i Consumer?

Producer wysyła wiadomości (records) do Topic. Każdy record ma klucz (opcjonalny), wartość (payload) i timestamp. Klucz determinuje partycję (round-robin jeśli brak klucza). Consumer subskrybuje Topic i polling records przez poll(). Consumer Group — wiele konsumentów w grupie dzieli między sobą partycje (każda partycja czytana przez jednego konsumenta w grupie). Offset — pozycja konsumenta w logu. Consumer commituje offset po przetworzeniu — Kafka nie usuwa wiadomości, offset gwarantuje 'exactly once' delivery przy odpowiedniej konfiguracji.

Co to jest Kafka Streams i ksqlDB?

Kafka Streams to biblioteka Java/Scala do budowania aplikacji streamingowych działających bezpośrednio na Kafce — bez zewnętrznego systemu (Flink, Spark). Obsługuje: stateless (map, filter), stateful (aggregate, join, windowing), fault-tolerant state stores (RocksDB), exactly-once semantics. ksqlDB to SQL-like interfejs do przetwarzania strumieni Kafki — tworzysz streams i tables w SQL, bez pisania kodu Java. Idealny dla transformacji, filtrowania i agregacji bez custom aplikacji.

Jak Kafka zapewnia wysoką dostępność?

Kafka zapewnia HA przez replikację: każda partycja ma jednego Leader i N Follower (replik). Producer pisze do Leader, Followers replikują asynchronicznie. ISR (In-Sync Replicas) — replikasy które są na bieżąco z Leaderem. Jeśli Leader pada — jedna z ISR staje się nowym Leaderem (automatyczny failover zarządzany przez Zookeeper lub KRaft w nowszych wersjach). Konfiguracja: replication.factor=3 (3 kopie), min.insync.replicas=2 (minimum 2 ISR do zapisu) zapewnia wysoka durability.