Architettura di Kafka spiegata: Componenti fondamentali e loro ruoli

L'architettura di Kafka può sembrare confusa all'inizio perché lo stesso sistema gestisce archiviazione, streaming, replica e avanzamento dei consumatori. Una volta separati i componenti principali, il modello diventa molto più semplice: i produttori scrivono record nelle partizioni dei topic, i broker archiviano quelle partizioni e i consumatori leggono i record tramite offset.

Questa guida spiega i componenti fondamentali di Kafka e come lavorano insieme in un cluster reale.

Broker: I server Kafka

Un cluster Kafka è composto da uno o più broker. Un broker è un server Kafka che archivia i dati delle partizioni e gestisce le richieste dei client da produttori e consumatori.

Quando un produttore invia un record, lo scrive sul broker che attualmente è il leader della partizione di destinazione. Quando un consumatore legge i record, li recupera dal broker che serve quella partizione. In configurazioni normali, ogni broker gestisce molte partizioni di molti topic.

Aggiungere broker può aumentare la capacità di archiviazione e distribuire il traffico, ma non risolve automaticamente ogni collo di bottiglia. Sono necessarie anche un numero sufficiente di partizioni, un posizionamento bilanciato delle repliche, dischi in buono stato e capacità di rete adeguata.

Topic: Flussi di record con nome

Un topic è un flusso di record con un nome, come ordini, pagamenti o attività_utente. I produttori scrivono nei topic e i consumatori si iscrivono ai topic.

Un topic è suddiviso in partizioni. Ogni partizione è un log ordinato e solo aggiuntivo. Kafka garantisce l'ordine dei record all'interno di una singola partizione, non nell'intero topic.

Questo dettaglio è importante. Se tutti gli eventi per un cliente devono essere elaborati in ordine, usa una chiave stabile come id_cliente. Il partizionatore predefinito di Kafka usa la chiave per scegliere una partizione, quindi i record con la stessa chiave vanno normalmente nella stessa partizione.

Partizioni e offset

Ogni record in una partizione riceve un offset. L'offset è un numero che identifica la posizione del record in quella partizione.

Ad esempio, un topic chiamato ordini con tre partizioni potrebbe apparire così:

ordini-0: offset 0, offset 1, offset 2
ordini-1: offset 0, offset 1
ordini-2: offset 0, offset 1, offset 2, offset 3

Gli offset hanno significato solo all'interno della propria partizione. L'offset 3 in ordini-2 non è correlato all'offset 3 in un'altra partizione.

Le partizioni forniscono parallelismo a Kafka. Più partizioni consentono a più consumatori nello stesso gruppo di consumatori di lavorare contemporaneamente, fino a un consumatore attivo per partizione all'interno di quel gruppo.

Replica e leader

Kafka utilizza la replica per mantenere i dati disponibili quando un broker fallisce. Ogni partizione può avere più repliche su broker diversi.

Una replica è il leader. Produttori e consumatori normalmente comunicano con il leader per quella partizione. Le altre repliche sono follower. I follower copiano i dati dal leader e rimangono pronti a subentrare se il leader fallisce.

Il fattore di replica controlla quante copie Kafka mantiene. Un fattore di replica di 3 significa che Kafka archivia tre copie di ogni partizione su tre broker, quando sono disponibili abbastanza broker.

Puoi creare un topic in questo modo:

kafka-topics.sh --create \
  --topic attività_utente \
  --bootstrap-server localhost:9092 \
  --partitions 3 \
  --replication-factor 3

Questo comando richiede un cluster con almeno tre broker. In una configurazione locale a singolo broker, usa un fattore di replica di 1.

Produttori: Applicazioni che scrivono eventi

I produttori inviano record ai topic di Kafka. Un record può includere una chiave, un valore, un timestamp e intestazioni.

Il produttore chiede prima al cluster i metadati per sapere quale broker è leader per ogni partizione. Poi invia i record direttamente al broker giusto.

L'affidabilità del produttore dipende fortemente da impostazioni come:

Impostazione	Cosa influenza
acks	Quanti riconoscimenti del broker sono richiesti prima che una scrittura sia considerata riuscita
retries	Se il produttore riprova i fallimenti transitori
enable.idempotence	Aiuta a evitare duplicati causati dai tentativi del produttore
compression.type	Riduce l'uso di rete e disco per molti carichi di lavoro

Per dati importanti, acks=all è comune perché il leader attende le repliche in sincronia prima di riconoscere la scrittura. Il comportamento esatto dipende anche dalle impostazioni del broker come min.insync.replicas.

Consumatori e gruppi di consumatori

I consumatori leggono i record dai topic. La maggior parte dei consumatori in produzione opera all'interno di un gruppo di consumatori.

All'interno di un gruppo di consumatori, Kafka assegna ogni partizione a un solo consumatore attivo alla volta. È così che Kafka permette di scalare l'elaborazione preservando l'ordine all'interno di ogni partizione.

Ad esempio, se ordini ha tre partizioni e il tuo servizio ha tre consumatori nello stesso gruppo, ogni consumatore può elaborare una partizione. Se aggiungi un quarto consumatore allo stesso gruppo, un consumatore rimarrà inattivo perché ci sono solo tre partizioni da assegnare.

Gruppi di consumatori diversi ottengono letture indipendenti. Il tuo servizio di fatturazione e il servizio di analisi possono entrambi leggere il topic ordini senza rubarsi i record a vicenda.

Offset e avanzamento dei consumatori

I consumatori tengono traccia dell'avanzamento confermando gli offset. Kafka memorizza gli offset confermati per i gruppi di consumatori in un topic interno chiamato __consumer_offsets.

Se un consumatore si blocca e riparte, utilizza l'offset confermato per riprendere. La tempistica delle conferme influisce sul comportamento di elaborazione:

Tempistica della conferma	Possibile risultato
Conferma prima del completamento dell'elaborazione	Un crash può saltare record
Conferma dopo il completamento dell'elaborazione	Un crash può rielaborare record

Molti sistemi scelgono l'elaborazione almeno una volta: elabora il record, poi conferma l'offset. Questo può creare duplicati dopo un crash, quindi le scritture a valle dovrebbero essere idempotenti quando possibile.

Metadati del cluster: ZooKeeper e KRaft

I cluster Kafka più vecchi usano Apache ZooKeeper per gestire i metadati del cluster e l'elezione del controller. Molte installazioni esistenti funzionano ancora in questo modo.

Le distribuzioni Kafka più recenti possono utilizzare la modalità KRaft, il quorum di metadati integrato di Kafka. Nei cluster KRaft, Kafka non dipende più da ZooKeeper per la gestione dei metadati.

Quando leggi tutorial Kafka più vecchi, verifica se assumono ZooKeeper o KRaft. Comandi, file di configurazione e passaggi operativi possono differire.

Come si muove un record attraverso Kafka

Un tipico flusso di scrittura e lettura appare così:

1. Un produttore si connette a un broker bootstrap e recupera i metadati.
2. Il produttore sceglie una partizione in base alla chiave del record o alla strategia di partizionamento.
3. Il produttore invia il record al broker leader per quella partizione.
4. Il leader aggiunge il record al suo log e i follower lo replicano.
5. Il leader riconosce la scrittura in base all'impostazione acks del produttore.
6. Un consumatore interroga la partizione e riceve i record a partire dal suo offset corrente.
7. Il consumatore elabora i record e conferma gli offset per il suo gruppo di consumatori.

Questo flusso è il motivo per cui Kafka può supportare sia l'elaborazione in tempo reale che la riproduzione. I consumatori non rimuovono i record quando li leggono.

Conservazione: Kafka mantiene i dati secondo una politica

Kafka non è una coda tradizionale in cui un messaggio scompare non appena un consumatore lo legge. Kafka mantiene i record in base alle impostazioni di conservazione.

Impostazioni comuni dei topic includono:

retention.ms=604800000
retention.bytes=10737418240

retention.ms controlla la conservazione basata sul tempo. retention.bytes controlla la conservazione basata sulla dimensione. La pulizia effettiva dipende anche dalle impostazioni dei segmenti e dalla configurazione del broker.

Alcuni topic utilizzano la compattazione del log invece, o insieme, alla conservazione basata sulla cancellazione. La compattazione mantiene l'ultimo valore per ogni chiave, utile per topic simili a stati come profili utente o modifiche di configurazione.

Cosa ricordare

L'architettura di Kafka è costruita attorno a log partizionati. I broker archiviano le partizioni, i produttori scrivono nei leader delle partizioni, i consumatori leggono tramite offset e i gruppi di consumatori dividono il lavoro tra le partizioni.

Quando progetti un topic Kafka, pensa insieme a ordinamento, numero di partizioni, fattore di replica, conservazione e comportamento del gruppo di consumatori. Queste scelte modellano come il tuo sistema scala, si riprende dai guasti e riproduce eventi passati.