In poche parole, ZooKeeper ti aiuta a creare applicazioni distribuite.
Come funziona
È possibile descrivere ZooKeeper come un servizio di sincronizzazione replicato con eventuale coerenza. È robusto, poiché i dati persistenti sono distribuiti tra più nodi (questo insieme di nodi è chiamato "insieme") e un client si connette a uno di essi (ovvero un "server" specifico), migrando se un nodo fallisce; fintanto che una rigida maggioranza di nodi funziona, l'insieme di nodi ZooKeeper è attivo. In particolare, un nodo master viene scelto dinamicamente per consenso all'interno dell'ensemble; se il nodo principale ha esito negativo, il ruolo del master passa a un altro nodo.
Come vengono gestite le scritture
Il master è l'autorità per le scritture: in questo modo le scritture possono essere garantite come persistenti nell'ordine, cioè le scritture sono lineari . Ogni volta che un client scrive nell'insieme, la maggior parte dei nodi mantiene le informazioni: questi nodi includono il server per il client e ovviamente il master. Ciò significa che ogni scrittura rende il server aggiornato con il master. Significa anche, tuttavia, che non è possibile avere scritture simultanee.
La garanzia di scritture lineari è la ragione per cui ZooKeeper non funziona bene per i carichi di lavoro dominanti in scrittura. In particolare, non dovrebbe essere utilizzato per lo scambio di dati di grandi dimensioni, come i media. Finché la comunicazione coinvolge dati condivisi, ZooKeeper ti aiuta. Quando i dati possono essere scritti contemporaneamente, ZooKeeper si mette in mezzo, perché impone un rigoroso ordinamento delle operazioni anche se non strettamente necessario dal punto di vista degli autori. Il suo utilizzo ideale è per il coordinamento, in cui i messaggi vengono scambiati tra i client.
Come vengono gestite le letture
È qui che eccelle ZooKeeper: le letture sono simultanee poiché sono servite dal server specifico a cui si connette il client. Tuttavia, questo è anche il motivo dell'eventuale coerenza: la "vista" di un client potrebbe essere obsoleta, poiché il master aggiorna il server corrispondente con un ritardo limitato ma non definito.
In dettaglio
Il database replicato di ZooKeeper comprende un albero di znodi , che sono entità che rappresentano approssimativamente nodi di file system (pensate a loro come directory). Ogni znode può essere arricchito da una matrice di byte, che memorizza i dati. Inoltre, ogni znode può avere altri znodi sotto di esso, praticamente formando un sistema di directory interno.
Znodi sequenziali
È interessante notare che il nome di uno znode può essere sequenziale , il che significa che il nome fornito dal client durante la creazione dello znode è solo un prefisso: il nome completo è anche dato da un numero sequenziale scelto dall'ensemble. Ciò è utile, ad esempio, ai fini della sincronizzazione: se più client desiderano ottenere un blocco su una risorsa, possono creare contemporaneamente uno znode sequenziale in una posizione: chiunque ottenga il numero più basso ha diritto al blocco.
Znodi effimeri
Inoltre, uno znode può essere effimero : ciò significa che viene distrutto non appena il client che lo ha creato si disconnette. Ciò è utile soprattutto per sapere quando un cliente fallisce, il che può essere rilevante quando il cliente stesso ha delle responsabilità che dovrebbero essere assunte da un nuovo cliente. Prendendo l'esempio del blocco, non appena il client con il blocco si disconnette, gli altri client possono verificare se hanno diritto al blocco.
Orologi
L'esempio relativo alla disconnessione del client potrebbe essere problematico se avessimo bisogno di effettuare periodicamente il polling dello stato degli znodi. Fortunatamente, ZooKeeper offre un sistema di eventi in cui un orologio può essere impostato su uno znode. Questi orologi possono essere impostati per attivare un evento se lo znode viene specificamente modificato o rimosso o vengono creati nuovi bambini al suo interno. Ciò è chiaramente utile in combinazione con le opzioni sequenziali ed effimere per gli znodi.
Dove e come usarlo
Un esempio canonico dell'utilizzo di Zookeeper è il calcolo della memoria distribuita, in cui alcuni dati sono condivisi tra i nodi client e devono essere accessibili / aggiornati in modo molto accurato per tenere conto della sincronizzazione.
ZooKeeper offre la libreria per costruire le tue primitive di sincronizzazione, mentre la possibilità di eseguire un server distribuito evita il problema del singolo punto di errore che si ha quando si utilizza un repository di messaggi centralizzato (simile a un broker).
ZooKeeper è leggero, il che significa che meccanismi come elezione dei leader, serrature, barriere, ecc. Non sono già presenti, ma possono essere scritti sopra le primitive di ZooKeeper. Se l'API C / Java è troppo ingombrante per i tuoi scopi, dovresti fare affidamento su librerie costruite su ZooKeeper come gabbie e soprattutto curatore .
Dove leggere di più
A parte la documentazione ufficiale, che è abbastanza buona, suggerisco di leggere il capitolo 14 di Hadoop: The Definitive Guide che ha ~ 35 pagine che spiegano essenzialmente cosa fa ZooKeeper, seguito da un esempio di un servizio di configurazione.