Condivisione della tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

1. Broker del controllore

Nel cluster Kafka è presente un Controller Broker, responsabile della gestione e del coordinamento dei metadati.

Kafka utilizza Zookeeper come strumento di archiviazione e gestione dei metadati del cluster. Zookeeper salva le informazioni sullo stato del cluster, incluse tutte le informazioni su argomenti, partizioni, leader e repliche, ecc.

Quando lo stato del cluster cambia, Controller Broker scriverà le informazioni sulla modifica su Zookeeper.

Quando l'attuale Controller Broker fallisce, altri Broker nel cluster Kafka rileveranno questa situazione e condurranno le elezioni tramite Zookeeper.

Dopo che un broker è stato eletto con successo come nuovo broker controller, leggerà gli ultimi metadati del cluster da Zookeeper.

Meccanismo di garanzia

• Metadati persistenti: Zookeeper memorizza in modo persistente i metadati del cluster, garantendo che le informazioni sullo stato più recenti possano essere ottenute in qualsiasi momento.
• meccanismo del battito cardiaco: La connessione tra Broker e Zookeeper viene mantenuta tramite il meccanismo heartbeat per rilevare rapidamente gli errori di Controller Broker.
• meccanismo elettorale: Attraverso il meccanismo di elezione di Zookeeper, è possibile eleggere rapidamente un nuovo Controller Broker e sincronizzare i metadati da Zookeeper.

2. Architettura dei componenti

1. Gestore dei registri

LogManagerPrincipalmente responsabile della gestione dell'archiviazione e del recupero dei log di Kafka (log).

Ad esempio: il produttore invia il messaggio al Leader Broker1 della Partizione0.LogManagerScrivere il messaggio nel file di registro di Partition0 su Broker1.

2. Gestore di replicazione

ReplicationManagerPrincipalmente responsabile della gestione della replica e della sincronizzazione dei dati della partizione.

La sincronizzazione tra Leader e Follower di ciascuna partizione viene eseguita in modo indipendente. Cioè, ogni partizione ha il proprio processo di sincronizzazione e non dipende da altre partizioni.

Sebbene il processo di sincronizzazione di ciascuna partizione sia indipendente, ciascun Broker avvierà i thread di replica corrispondenti per ciascuna partizione che gestisce (sia Leader che Follower) e questi thread sono responsabili della gestione di attività di sincronizzazione specifiche.

Per esempio:ReplicationManagerInvia i messaggi appena scritti su Broker1 al follower Broker2 e Broker3 di Partition0.ReplicationManagerLe richieste di replica ricevute da Broker1 vengono elaborate su Broker2 e Broker3, scrivendo messaggi nei rispettivi file di registro.

3. Server di socket

SocketServer È un componente di Kafka Broker ed è responsabile della gestione delle connessioni di rete e delle operazioni di I/O. È responsabile dell'accettazione delle richieste di connessione da parte dei client e di altri broker e dell'assegnazione di un thread a ciascuna connessione per l'elaborazione.

4. Server di rete

NetworkServer È una parte fondamentale del framework di comunicazione di rete di Kafka ed è responsabile della gestione e della pianificazione delle richieste di rete. Utilizza NIO (I/O non bloccante) per gestire connessioni di rete altamente simultanee.

5. Cliente ZK

Componente che comunica con Zookeeper.