Architettura Apache Kafka®: una guida completa (2023)

Apache Kafkaè una piattaforma di streaming distribuita che offre quattro API chiave: l'API Producer, l'API Consumer, l'API Streams e l'API Connector con funzionalità come l'archiviazione ridondante di enormi volumi di dati e un bus di messaggi in grado di raggiungere milioni di messaggi al secondo. Queste e altre funzionalità rendono Kafka una soluzione su misura per l'elaborazione di dati in streaming da applicazioni in tempo reale.

1. Cos'è Apache Kafka?

Kafkaè essenzialmente un log di commit con una struttura dati semplicistica. L'API Kafka Producer, l'API Consumer, l'API Streams e l'API Connect possono essere utilizzate per gestire la piattaforma e l'architettura del cluster Kafka è composta da broker, consumatori, produttori eZooKeeper.

Architettura di Apache Kafka

Nonostante il suo nome suggerisca la complessità kafkiana,L'architettura di Apache Kafkain realtà offre un approccio più facile da capire alla messaggistica delle applicazioni rispetto a molte delle alternative. Kafka è essenzialmente un log di commit con una struttura dati molto semplicistica. Si dà il caso che sia eccezionalmente tollerante ai guasti e scalabile orizzontalmente.

Log di commit di Apache Kafka

Il registro dei commit di Kafka fornisce una struttura di dati ordinata persistente. I record non possono essere cancellati o modificati direttamente, ma solo aggiunti al registro. L'ordine degli elementi nei registri di Kafka è garantito. Il cluster Kafka crea e aggiorna un log di commit partizionato per ogni argomento esistente. Tutti i messaggi inviati alla stessa partizione vengono archiviati nell'ordine in cui arrivano. Per questo motivo, la sequenza dei record all'interno di questa struttura del log di commit è ordinata e immutabile. Kafka assegna inoltre a ciascun record un ID sequenziale univoco noto come "offset", che viene utilizzato per recuperare i dati.

Kafka risolve problemi comuni con i sistemi distribuiti fornendo l'ordinamento degli insiemi e l'elaborazione deterministica. Poiché Kafka archivia i dati dei messaggi su disco e in modo ordinato, trae vantaggio dalle letture sequenziali del disco. Considerando l'elevato costo delle risorse delle ricerche su disco, il fatto che in primo luogo Kafka elabori le letture e le scritture a un ritmo costante e, in secondo luogo, le letture e le scritture avvengano simultaneamente senza intralciarsi a vicenda, si combinano per offrire enormi vantaggi in termini di prestazioni.

Con Kafka, il ridimensionamento orizzontale è facile. Ciò significa che Kafka può ottenere le stesse prestazioni elevate quando si tratta di qualsiasi tipo di compito, dal piccolo al massiccio.

2. Architettura di Apache Kafka: panoramica dei componenti

L'architettura di Kafka è composta da argomenti, produttori, consumatori, gruppi di consumatori, cluster, broker, partizioni, repliche, leader e follower.

Il diagramma seguente offre uno sguardo semplificato alle interrelazioni tra questi componenti.

Architettura dell'API di Kafka

Apache Kafka offre quattro API principali: l'API Producer, l'API Consumer, l'API Streams e l'API Connector.

Diamo una breve occhiata a come ciascuno di essi può essere utilizzato per migliorare le capacità delle applicazioni:

API del produttore

L'API Kafka Producer consente a un'applicazione di pubblicare un flusso di record in uno o piùArgomenti di Kafka.

API del consumatore

L'API Kafka Consumer consente a un'applicazione di sottoscrivere uno o più argomenti Kafka. Consente inoltre all'applicazione di elaborare flussi di record prodotti per tali argomenti.

API dei flussi

ILFlussi di KafkaL'API consente a un'applicazione di elaborare i dati in Kafka utilizzando un paradigma di elaborazione dei flussi. Con questa API, un'applicazione può consumare flussi di input da uno o più argomenti, elaborarli con operazioni di flussi e produrre flussi di output e inviarli a uno o più argomenti. In questo modo, l'API Streams consente di trasformare i flussi di input in flussi di output.

Collega l'API

ILConnettore KafkaL'API collega applicazioni o sistemi di dati agli argomenti di Kafka. Ciò fornisce opzioni per creare e gestire il funzionamento di produttori e consumatori e ottenere connessioni riutilizzabili tra queste soluzioni. Ad esempio, un connettore potrebbe acquisire tutti gli aggiornamenti in un database e garantire che tali modifiche siano rese disponibili all'interno di un argomento Kafka.

3. Architettura del cluster Kafka

Ora diamo un'occhiata più da vicino ad alcuni dei principali componenti architettonici di Kafka:

Broker Kafka

UNMediatore Kafkaè un server in esecuzione in aCluster di Kafka(o, in altre parole: un cluster Kafka è composto da un numero di broker).

In genere, più broker collaborano per formare il cluster Kafka e ottenere bilanciamento del carico, ridondanza e failover affidabili.I broker utilizzanoApache ZooKeeper®per la gestione e il coordinamento del cluster. Ogni istanza del broker è in grado di gestire quantità di lettura e scrittura che raggiungono le centinaia di migliaia al secondo (e terabyte di messaggi) senza alcun impatto sulle prestazioni. Ogni broker ha un ID univoco e può essere responsabile delle partizioni di uno o più log degli argomenti.

I broker Kafka sfruttano anche ZooKeeper per le elezioni dei leader, in cui viene eletto un broker per gestire le richieste dei clienti per una singola partizione di un argomento. La connessione a qualsiasi broker eseguirà il bootstrap di un client al cluster Kafka completo. Per ottenere un failover affidabile, è necessario utilizzare un minimo di 3 broker: con un numero maggiore di broker aumenta l'affidabilità.

Architettura di Apache ZooKeeper

I broker Kafka usanoZooKeepergestire e coordinare il cluster Kafka.ZooKeeper notifica a tutti i nodi quando la topologia del cluster Kafka cambia, incluso quando vengono aggiunti o rimossi broker e argomenti.

Ad esempio, ZooKeeper informa il cluster se un nuovo broker si unisce al cluster o quando un broker riscontra un errore. ZooKeeper consente inoltre le elezioni di leadership tra broker e coppie di partizioni di argomenti, aiutando a determinare quale broker sarà il leader per una particolare partizione (e le operazioni di lettura e scrittura del server da parte di produttori e consumatori) e quali broker detengono repliche degli stessi dati. Quando ZooKeeper notifica al cluster le modifiche del broker, iniziano immediatamente a coordinarsi tra loro ed eleggono i nuovi leader di partizione richiesti. Questo protegge dall'eventualità che un broker sia improvvisamente assente.

Produttori di Kafka

Un produttore Kafka funge da origine dati che ottimizza, scrive e pubblica messaggi su uno o più argomenti Kafka. I produttori di Kafka inoltre serializzano, comprimono e bilanciano il carico dei dati tra i broker attraverso il partizionamento.

Consumatori di Kafka

Consumatorileggere i dati leggendo i messaggi dagli argomenti a cui si iscrivono. I consumatori apparterranno a un gruppo di consumatori. Ogni consumatore all'interno di un particolare gruppo di consumatori avrà la responsabilità di leggere un sottoinsieme delle partizioni di ciascun argomento a cui è iscritto.

4. Concetti di base

I seguenti concetti sono la base per comprendere l'architettura di Kafka:

Argomenti di Kafka

UNArgomento Kafkadefinisce un canale attraverso il quale i dati vengono trasmessi.I produttori pubblicano messaggi negli argomenti e i consumatori leggono i messaggi dall'argomento a cui si iscrivono.

Gli argomenti organizzano e strutturano i messaggi, con tipi particolari di messaggi pubblicati su argomenti particolari. Gli argomenti sono identificati da nomi univoci all'interno di un cluster Kafka e non c'è limite al numero di argomenti che possono essere creati.

Partizioni di Kafka

All'interno del cluster Kafka, gli argomenti sono suddivisi inpartizioni,e le partizioni vengono replicate tra i broker. Da ogni partizione, più consumatori possono leggere da un argomento in parallelo. È anche possibile che i produttori aggiungano una chiave a un messaggio: tutti i messaggi con la stessa chiave andranno alla stessa partizione.

Mentre i messaggi vengono aggiunti e archiviati all'interno delle partizioni in sequenza, i messaggi senza chiavi vengono scritti nelle partizioni in modalità round robin. Sfruttando le chiavi, puoi garantire l'ordine di elaborazione per i messaggi in Kafka che condividono la stessa chiave. Questa è una funzione particolarmente utile per le applicazioni che richiedono il controllo totale sui record. Non c'è limite al numero diPartizioni di Kafkache possono essere creati (in base alla capacità di elaborazione di un cluster).

Vuoi risposte a domande come

"Che impatto ha l'aumento delle partizioni sulla velocità effettiva?"

"Esiste un numero ottimale di partizioni per un cluster per massimizzare il throughput di scrittura?"

Scopri di più nel nostro blog su Kafka Partitions

Fattore di replica dell'argomento

Replica dell'argomentoè essenziale per progettare implementazioni Kafka resilienti e altamente disponibili.

Quando un broker si arresta, le repliche degli argomenti su altri broker rimarranno disponibili per garantire che i dati rimangano disponibili e che la distribuzione di Kafka eviti guasti e tempi di inattività. Il fattore di replica impostato definisce quante copie di un argomento vengono mantenute nel cluster Kafka. È definito a livello di argomento e si svolge a livello di partizione.

Ad esempio, un fattore di replica pari a 2 manterrà 2 copie di un argomento per ogni partizione. Come accennato in precedenza, un determinato broker funge da leader eletto per ciascuna partizione e altri broker mantengono areplica da utilizzare se necessario. Logicamente, il fattore di replica non può essere maggiore del numero totale di broker disponibili nel cluster. Una replica che è aggiornata con il leader di una partizione è detta In-Sync Replica (ISR).

Gruppo Consumatori

UNGruppo di consumatori Kafkainclude correlaticonsumatoricon un compito comune.

Kafka invia messaggi dalle partizioni di un argomento ai consumatori nel gruppo di consumatori. Al momento della lettura, ogni partizione viene letta solo da un singolo consumatore all'interno del gruppo. Un gruppo di consumatori ha un ID gruppo univoco e può eseguire più processi o istanze contemporaneamente. Ciascun gruppo di consumatori può avere un consumatore letto da una singola partizione. Se la quantità di consumatori all'interno di un gruppo è maggiore del numero di partizioni, alcuni consumatori saranno inattivi.

Architettura interna di Kafka in breve

Assemblando i componenti sopra descritti, i produttori di Kafka scrivono sugli argomenti, mentre i consumatori di Kafka leggono dagli argomenti. Gli argomenti rappresentano le strutture di dati del log di commit memorizzate su disco. Kafka aggiunge i record scritti dai produttori alla fine di quei registri di commit dell'argomento. I registri degli argomenti sono inoltre costituiti da più partizioni, a cavallo di più file e potenzialmente più nodi del cluster. I consumatori possono utilizzare gli offset per leggere da determinate posizioni all'interno dei registri degli argomenti. Ciascun gruppo di consumatori ricorda l'offset che rappresenta il punto in cui ha letto l'ultima volta da un argomento.

Le partizioni dei log degli argomenti sono distribuite tra i nodi del cluster, o broker, per ottenere scalabilità orizzontale e prestazioni elevate. L'architettura di Kafka può essere sfruttata per migliorare questi obiettivi, semplicemente utilizzando consumatori aggiuntivi secondo necessità in un gruppo di consumatori per accedere alle partizioni di log degli argomenti replicate tra i nodi. Ciò consente ad Apache Kafka di fornire maggiore failover e affidabilità, aumentando allo stesso tempo la velocità di elaborazione.

5. Vantaggi

Ci sono molti buoni motivi per utilizzare Kafka, ognuno dei quali risale all'architettura della soluzione. Alcuni di questi vantaggi chiave includono:

Scalabilità e prestazioni

Kafka offre scritture sequenziali ad alte prestazioni e suddivide gli argomenti in partizioni per letture e scritture altamente scalabili. Di conseguenza, Kafka consente a più produttori e consumatori di leggere e scrivere simultaneamente (ea velocità estreme). Inoltre, gli argomenti divisi su più partizioni possono sfruttare l'archiviazione su più server, che a loro volta possono consentire alle applicazioni di utilizzare la potenza combinata di più dischi.

Con più produttori che scrivono sullo stesso argomento tramite partizioni replicate separate e più consumatori di più gruppi di consumatori che leggono anche da partizioni separate, è possibile raggiungere praticamente qualsiasi livello di scalabilità e prestazioni desiderate attraverso questa architettura efficiente.

Affidabilità

L'architettura di Kafka raggiunge naturalmente il failover attraverso il suo uso intrinseco della replica. Le partizioni degli argomenti vengono replicate su più broker Kafka, o nodi, con argomenti che utilizzano un fattore di replica impostato. Il fallimento di qualsiasi broker Kafka fa sì che un ISR assuma il ruolo di leader per i suoi dati e continui a servirli senza problemi e senza interruzioni.

Ripristino di emergenza

Oltre all'uso della replica da parte di Kafka per fornire il failover, l'utilità Kafka MirrorMaker offre una soluzione di ripristino di emergenza completa. MirrorMaker è progettato per replicare l'intero cluster Kafka, ad esempio in un'altra regione della rete del provider di servizi cloud o all'interno di un altro data center.

In questo modo, l'architettura di Kafka MirrorMaker consente alla distribuzione di Kafka di mantenere operazioni senza soluzione di continuità anche durante i disastri su scala macro. Questa funzionalità viene definita mirroring, in contrapposizione alla replica di failover standard eseguita all'interno di un cluster Kafka. Per un esempio di come utilizzare Kafka e MirrorMaker, un'organizzazione potrebbe posizionare l'intero cluster Kafka in una singola regione del provider cloud per sfruttare le efficienze localizzate e quindi eseguire il mirroring di tale cluster in un'altra regione con MirrorMaker per mantenere un solido ripristino di emergenza opzione.

6. Architettura di Kafka: esempi di relazioni tra componenti

Diamo un'occhiata alle relazioni tra i componenti chiave all'interno dell'architettura di Kafka. Tieni presente quanto segue quando si tratta di broker, repliche e partizioni:

• I cluster Kafka possono includere uno o più broker.
• I broker Kafka sono in grado di ospitare più partizioni.
• Gli argomenti possono includere 1 o più partizioni.
• I broker sono in grado di ospitare 1 o zero repliche per ciascuna partizione.
• Ogni partizione include 1 replica leader e zero o più repliche follower.
• Ognuna delle repliche di una partizione deve trovarsi su un broker diverso.
• Ogni replica di partizione deve adattarsi completamente a un broker e non può essere suddivisa in più di un broker.
• Ogni broker può essere il leader per zero o più coppie argomento/partizione.

Ora diamo un'occhiata ad alcuni esempi di come i produttori, gli argomenti e i consumatori si relazionano tra loro:

Qui vediamo un semplice esempio di un produttore che invia un messaggio a un argomento e di un consumatore che è iscritto a quell'argomento che legge il messaggio.

Il diagramma seguente mostra come i produttori possono inviare messaggi a singoli argomenti:

I consumatori possono iscriversi a più argomenti contemporaneamente e ricevere messaggi da loro in un singolo sondaggio (il consumatore 3 nel diagramma ne mostra un esempio). I messaggi che i consumatori ricevono possono essere controllati e filtrati per argomento quando necessario (utilizzando la tecnica dell'aggiunta di chiavi ai messaggi, descritta sopra).

Ora diamo un'occhiata a un produttore che invia messaggi a più argomenti contemporaneamente, in modo asincrono:

Tecnicamente, un produttore può essere in grado di inviare messaggi a un solo argomento alla volta. Tuttavia, inviando i messaggi in modo asincrono, i produttori possono consegnare funzionalmente più messaggi a più argomenti secondo necessità.

L'architettura di Kafka è costruita per enfatizzare le prestazioni e la scalabilità dei broker. Ciò lascia ai produttori la responsabilità di controllare quale partizione riceve quali messaggi. Una funzione di hashing sulla chiave del messaggio determina la partizione predefinita in cui finirà un messaggio. Se non viene definita alcuna chiave, il messaggio arriva nelle partizioni in una serie roundrobin.

Tuttavia, questi metodi possono causare problemi o risultati non ottimali, in scenari che includono l'ordinamento dei messaggi o una distribuzione uniforme dei messaggi tra i consumatori. Per risolvere tali problemi, è possibile controllare il modo in cui i produttori inviano messaggi e li indirizzano aspecificapartizioni. Per fare ciò è necessario utilizzare un partizionatore del cliente o le partizioni predefinite insieme alle opzioni manuali o di hashing disponibili

Il valore dei consumatori nell'architettura di Kafka

All'interno dell'architettura Kafka, ogni argomento è associato a 1 o più partizioni e queste sono distribuite su 1 o più broker.

Ciascuna partizione viene replicata su tali broker in base al fattore di replica impostato. Mentre il fattore di replica controlla il numero di repliche (e quindi l'affidabilità e la disponibilità), il numero di partizioni controlla il parallelismo dei consumatori (e quindi la scalabilità in lettura). Ciò è dovuto al fatto che ciascuna partizione può essere associata solo a 11 istanze consumer di ciascun gruppo consumer e il numero totale di istanze consumer per ciascun gruppo è inferiore o uguale al numero di partizioni. L'aggiunta di più partizioni abilita più istanze consumer, consentendo in tal modo letture su scala maggiore.

Come risultato di questi aspetti dell'architettura di Kafka, gli eventi all'interno di una partizione si verificano in un certo ordine. All'interno di un particolare gruppo di consumatori, ogni evento viene elaborato da un singolo consumatore, come previsto. Quando più gruppi di consumatori si iscrivono allo stesso argomento e ciascuno ha un consumatore pronto a elaborare l'evento, tutti questi consumatori ricevono tutti i messaggi trasmessi dall'argomento. In pratica, questa capacità di trasmissione è piuttosto preziosa.

I prossimi esempi mostrano alcune tecniche diverse per sfruttare in modo vantaggioso un singolo argomento insieme a più partizioni, consumatori e gruppi di consumatori.

In questo esempio, l'architettura di distribuzione di Kafka utilizza un numero uguale di partizioni e consumatori all'interno di un gruppo di consumatori:

Come abbiamo stabilito, i protocolli dinamici di Kafka assegnano un singolo consumatore all'interno di un gruppo a ciascuna partizione. Questa è di solito la configurazione migliore, ma èPotereessere aggirato collegando direttamente un consumatore a una specifica coppia argomento/partizione. Ciò significa essenzialmente rimuovere il consumatore dalla partecipazione al sistema dei gruppi di consumatori. Sebbene sia insolito farlo, può essere utile in determinate situazioni specializzate.

Ora diamo un'occhiata a un caso in cui utilizziamo più consumatori in un gruppo di quanti ne abbiamo le partizioni. Ciò fa sì che alcuni consumatori rimangano inattivi. Kafka può fare buon uso di questi consumatori inattivi eseguendo il failover su di essi nel caso in cui un consumatore attivo muoia o assegnando loro il lavoro se viene creata una nuova partizione.

Successivamente, diamo un'occhiata a un esempio di un gruppo che include meno consumatori rispetto alle partizioni. Il risultato in questo esempio è che il consumatore A2 è bloccato con la responsabilità di elaborare più messaggi rispetto alla sua controparte, il consumatore A1:

Nel nostro ultimo esempio, più gruppi di consumatori ricevono ogni evento da ogni partizione Kafka, con il risultato che i messaggi vengono completamente trasmessi a tutti i gruppi:

Il protocollo dinamico di Kafka gestisce tutti i lavori di manutenzione necessari per garantire che un consumatore rimanga un membro del suo gruppo di consumatori. Quando nuove istanze di consumatori si uniscono a un gruppo di consumatori, vengono anche assegnate automaticamente e dinamicamente alle partizioni, prendendole in consegna dai consumatori esistenti nel gruppo di consumatori, se necessario. Se e quando un'istanza consumer muore, la sua partizione verrà riassegnata a un'istanza rimanente nello stesso modo.

7. Risorse per consumatori e produttori

Nello sviluppare la tua comprensione di come i consumatori di Kafka operano all'interno dell'architettura di Kafka e dal punto di vista delle risorse, è fondamentale riconoscere che i consumatori e i produttori non funzionano sui broker Kafka e richiedono invece le proprie risorse di CPU e IO. Questa indipendenza delle risorse è un vantaggio quando si tratta di gestire i consumatori in qualsiasi metodo e quantità sia ideale per l'attività da svolgere, fornendo piena flessibilità senza la necessità di considerare le relazioni delle risorse interne durante la distribuzione dei consumatori tra i broker.

Detto questo, questa flessibilità comporta responsabilità: sta a te capire i metodi di implementazione e risorse ottimali per i tuoi consumatori e produttori. Questa non è una sfida da poco e deve essere considerata con attenzione. Sfruttare microservizi altamente scalabili ed elastici per soddisfare questa esigenza è una strategia suggerita.

8. Conclusione

Apache Kafka offre un'architettura straordinariamente versatile e potente per lo streaming di carichi di lavoro con estrema scalabilità, affidabilità e prestazioni. Per saperne di più su come i servizi gestiti di Instaclustr possono aiutare la tua organizzazione a ottenere il massimo da Kafka e da tutte le tecnologie open source al 100% disponibili sulla piattaforma gestita di Instaclustriscriviti per una prova gratuita qui.