Zookeeper - Fondamenti

Prima di approfondire il lavoro di ZooKeeper, diamo uno sguardo ai concetti fondamentali di ZooKeeper. Discuteremo i seguenti argomenti in questo capitolo:

  • Architecture
  • Spazio dei nomi gerarchico
  • Session
  • Watches

Architettura di ZooKeeper

Dai un'occhiata al diagramma seguente. Raffigura l '"architettura client-server" di ZooKeeper.

Ciascuno dei componenti che fa parte dell'architettura ZooKeeper è stato spiegato nella tabella seguente.

Parte Descrizione
Cliente

I client, uno dei nodi nel nostro cluster di applicazioni distribuite, accedono alle informazioni dal server. Per un determinato intervallo di tempo, ogni client invia un messaggio al server per far sapere al server che il client è vivo.

Allo stesso modo, il server invia un riconoscimento quando un client si connette. Se non c'è risposta dal server connesso, il client reindirizza automaticamente il messaggio a un altro server.

server Server, uno dei nodi del nostro insieme ZooKeeper, fornisce tutti i servizi ai clienti. Dà un riconoscimento al client per informare che il server è attivo.
Ensemble Gruppo di server ZooKeeper. Il numero minimo di nodi richiesto per formare un insieme è 3.
Capo Nodo del server che esegue il ripristino automatico in caso di guasto di uno dei nodi collegati. I leader vengono eletti all'avvio del servizio.
Seguace Nodo del server che segue le istruzioni del leader.

Spazio dei nomi gerarchico

Il diagramma seguente mostra la struttura ad albero del file system ZooKeeper utilizzato per la rappresentazione della memoria. Il nodo ZooKeeper è indicato comeznode. Ogni znode è identificato da un nome e separato da una sequenza di percorso (/).

  • Nel diagramma, prima hai una radice znodedivisi da "/". Sotto root, hai due spazi dei nomi logiciconfig e workers.

  • Il config lo spazio dei nomi viene utilizzato per la gestione centralizzata della configurazione e il workers lo spazio dei nomi viene utilizzato per la denominazione.

  • Sotto configspazio dei nomi, ogni znode può memorizzare fino a 1 MB di dati. È simile al file system UNIX tranne per il fatto che anche lo znode genitore può memorizzare i dati. Lo scopo principale di questa struttura è memorizzare dati sincronizzati e descrivere i metadati di znode. Questa struttura è chiamata comeZooKeeper Data Model.

Ogni znode nel modello di dati di ZooKeeper mantiene un file statstruttura. Una statistica fornisce semplicemente il filemetadatadi uno znode. Consiste di numero di versione, elenco di controllo delle azioni (ACL), data e ora e lunghezza dei dati.

  • Version number- Ogni znode ha un numero di versione, il che significa che ogni volta che i dati associati allo znode cambiano, aumenta anche il numero di versione corrispondente. L'utilizzo del numero di versione è importante quando più client zookeeper stanno tentando di eseguire operazioni sullo stesso znode.

  • Action Control List (ACL)- ACL è fondamentalmente un meccanismo di autenticazione per accedere a znode. Governa tutte le operazioni di lettura e scrittura di znode.

  • Timestamp- Timestamp rappresenta il tempo trascorso dalla creazione e modifica di znode. Di solito è rappresentato in millisecondi. ZooKeeper identifica ogni modifica agli znodes da "Transaction ID" (zxid).Zxid è unico e mantiene il tempo per ogni transazione in modo da poter identificare facilmente il tempo trascorso da una richiesta all'altra.

  • Data length- La quantità totale di dati memorizzati in uno znode è la lunghezza dei dati. È possibile memorizzare un massimo di 1 MB di dati.

Tipi di Znodi

Gli znodi sono classificati come persistenza, sequenziale ed effimero.

  • Persistence znode- La persistenza znode è attiva anche dopo che il client, che ha creato quel particolare znode, è disconnesso. Per impostazione predefinita, tutti gli znodes sono persistenti se non diversamente specificato.

  • Ephemeral znode- Gli znodi temporanei sono attivi fino a quando il client è vivo. Quando un client viene disconnesso dall'insieme ZooKeeper, gli znode temporanei vengono eliminati automaticamente. Per questo motivo, solo gli znodi effimeri non possono avere figli ulteriormente. Se uno znode effimero viene eliminato, il successivo nodo adatto riempirà la sua posizione. Gli znodi effimeri svolgono un ruolo importante nell'elezione del leader.

  • Sequential znode- Znodi sequenziali possono essere persistenti o effimeri. Quando un nuovo znode viene creato come znode sequenziale, ZooKeeper imposta il percorso dello znode allegando un numero di sequenza di 10 cifre al nome originale. Ad esempio, se un znode con path/myapp viene creato come znode sequenziale, ZooKeeper modificherà il percorso in /myapp0000000001e imposta il numero di sequenza successivo come 0000000002. Se due znode sequenziali vengono creati contemporaneamente, ZooKeeper non utilizza mai lo stesso numero per ogni znode. Gli znodi sequenziali svolgono un ruolo importante nel blocco e nella sincronizzazione.

Sessioni

Le sessioni sono molto importanti per il funzionamento di ZooKeeper. Le richieste in una sessione vengono eseguite in ordine FIFO. Una volta che un client si connette a un server, la sessione verrà stabilita e un filesession id è assegnato al cliente.

Il client invia heartbeatsin un determinato intervallo di tempo per mantenere valida la sessione. Se l'insieme ZooKeeper non riceve heartbeat da un client per un periodo superiore al periodo (timeout di sessione) specificato all'inizio del servizio, decide che il client è morto.

I timeout di sessione sono generalmente rappresentati in millisecondi. Quando una sessione termina per qualsiasi motivo, anche gli znodi temporanei creati durante quella sessione vengono eliminati.

Orologi

Gli orologi sono un semplice meccanismo per il client per ricevere notifiche sui cambiamenti nell'insieme di ZooKeeper. I clienti possono impostare orologi durante la lettura di un particolare znode. Gli orologi inviano una notifica al client registrato per qualsiasi modifica di znode (su cui il client si registra).

Le modifiche di Znode sono modifiche dei dati associati a znode o modifiche ai figli di znode. Gli orologi vengono attivati ​​solo una volta. Se un client desidera di nuovo una notifica, deve essere eseguita tramite un'altra operazione di lettura. Quando una sessione di connessione è scaduta, il client verrà disconnesso dal server e anche gli orologi associati verranno rimossi.