Zookeeper è un sottoprogetto di Hadoop e, anche se deriva da hadoop, ho scoperto che zookeeper utilizza sempre più spesso framework distribuiti al di fuori di Hadoop. Oggi voglio parlare di zookeeper; questo articolo non parlerà di come usare zookeeper, ma quali sono le applicazioni pratiche di zookeeper, quali tipi di applicazioni possono offrire i vantaggi di zookeeper, e infine parlerà del ruolo che zookeeper può avere nell'architettura distribuita dei siti web.
Zookeeper è un sistema di coordinamento altamente affidabile per grandi sistemi distribuiti. Da questa definizione, sappiamo che lo zookeeper è un sistema coordinato che agisce su sistemi distribuiti. Perché i sistemi distribuiti hanno bisogno di un sistema di coordinamento? Le ragioni sono le seguenti:
Sviluppare un sistema distribuito è una cosa molto difficile, e la difficoltà si riflette principalmente nel "fallimento parziale" del sistema distribuito. "Guasto parziale" si riferisce alla trasmissione di informazioni tra due nodi della rete; se la rete fallisce, il mittente non può sapere se il destinatario ha ricevuto il messaggio, e la causa di questo guasto è complessa, il destinatario può o meno aver ricevuto il messaggio prima dell'errore di rete, oppure il processo del ricevitore è morto. L'unico modo in cui il mittente può ottenere il quadro reale è riconnettersi al ricevitore e chiedere al ricevitore perché si è verificato l'errore, che è il problema del "guasto parziale" nello sviluppo di sistemi distribuiti.
Zookeeper è il framework per risolvere il "fallimento parziale" dei sistemi distribuiti. Zookeeper non consente ai sistemi distribuiti di evitare problemi di "guasto parziale", ma consente ai sistemi distribuiti di gestire correttamente tali problemi quando incontrano guasti parziali, così che i sistemi distribuiti possano funzionare normalmente.
Parliamo dell'uso pratico dello zookeeper:
Scenario 1: Esiste un gruppo di server che forniscono un certo servizio al client (ad esempio, il lato server del sito distribuito che ho creato prima è un cluster composto da quattro server per fornire servizi al cluster front-end), e speriamo che il client possa trovare un server nel cluster di server ogni volta che il client lo richiede, così che il server possa fornire al client i servizi richiesti. Per questo scenario, dobbiamo avere una lista di server nel nostro programma, da cui leggiamo la lista dei server ogni volta che il client la richiede. Allora questa sottolista ovviamente non può essere memorizzata su un singolo server nodo, altrimenti il nodo si riattaccherà e l'intero cluster fallirà, e speriamo che questa lista sia molto disponibile in quel momento. Se un server nella storage list è rotto, altri server possono sostituire immediatamente il server rotto, e il server guasto può essere rimosso dalla lista, così che il server guasto possa ritirarsi dall'intero cluster e tutte queste operazioni non saranno gestite dal server guasto, ma dal server normale nel cluster. Si tratta di una struttura dati distribuita attiva che può modificare attivamente lo stato degli elementi dati quando cambiano le condizioni esterne. Il framework Zookeeper fornisce questo servizio. Il nome di questo servizio è: Unified Naming Service, molto simile al servizio JNDI in javaEE.
Scenario 2: Servizio di serratura distribuita. Quando un sistema distribuito manipola dati, come leggere dati, analizzare dati e infine modificarli. Nel sistema distribuito, queste operazioni possono essere disperse tra diversi nodi del cluster, quindi c'è un problema di coerenza nel processo di gestione dei dati; se è incoerente, otterremo un risultato di operazione errato; in un singolo programma di processo, il problema della coerenza è facile da risolvere, ma è più difficile raggiungere il sistema distribuito, perché le operazioni dei diversi server nel sistema distribuito sono in processi indipendenti, e i risultati e processi intermedi dell'operazione devono essere trasmessi attraverso la rete. Allora è molto più difficile ottenere la coerenza delle operazioni dati. Zookeeper fornisce un servizio di blocco che risolve questo problema, permettendoci di garantire la coerenza delle operazioni dati durante le operazioni distribuite.
Scenario 3: Gestione della configurazione. In un sistema distribuito, distribuiremo un'applicazione di servizio su n server separatamente, e i file di configurazione di questi server sono gli stessi (ad esempio, nel framework del sito distribuito che ho progettato, ci sono 4 server lato server, i programmi sui 4 server sono gli stessi e i file di configurazione sono gli stessi), se le opzioni di configurazione dei file di configurazione cambiano, allora dobbiamo modificare questi file uno per uno, se dobbiamo cambiare i server sono relativamente piccoli, queste operazioni non sono troppo problematiche, Se abbiamo un gran numero di server distribuiti, come il cluster Hadoop di una grande azienda Internet con migliaia di server, allora cambiare le opzioni di configurazione può essere una cosa problematica e pericolosa. Al momento, zookeeper può tornare utile: possiamo usare zookeeper come memoria di configurazione altamente disponibile, consegnare questo dispositivo a zookeeper per la gestione, copiare il file di configurazione del cluster in un nodo del file system dello zookeeper, e poi usare zookeeper per monitorare lo stato del file di configurazione in tutti i sistemi distribuiti, una volta che si scopre che il file di configurazione è cambiato, Ogni server riceverà una notifica da Zookeeper per sincronizzare i file di configurazione in Zookeeper, e il servizio Zookeeper garantirà inoltre che l'operazione di sincronizzazione sia atomica per garantire che il file di configurazione di ogni server venga aggiornato correttamente.
Scenario 4: Fornire funzioni di riparazione dei guasti per sistemi distribuiti. La gestione del cluster è difficile, e aggiungere il servizio di custodia allo zoologico al sistema distribuito rende facile per noi gestire il cluster. La cosa più problematica nella gestione del cluster è la gestione dei guasti dei nodi: zookeeper può permettere al cluster di selezionare un nodo sano come master, il nodo master conoscerà lo stato di salute attuale di ogni server nel cluster; una volta che un nodo fallisce, il master notificherà gli altri server del cluster per ridistribuire i compiti di calcolo dei diversi nodi. Zookeeper non solo può trovare i guasti, ma anche controllare il server difettoso, vedere che tipo di guasto è, se il guasto può essere riparato, lo zookeeper può correggere automaticamente o comunicare all'amministratore di sistema la causa dell'errore, così che l'amministratore possa rapidamente individuare il problema e riparare il guasto del nodo. Potresti ancora avere una domanda: cosa dovrei fare se il master è difettoso? Zookeeper tiene conto anche di questo: lo zookeeper ha un "algoritmo per eleggere i leader" interno, i master possono essere selezionati dinamicamente e, quando il master fallisce, lo zookeeper può immediatamente selezionare un nuovo master per gestire il cluster.
Parliamo delle caratteristiche dello zookeeper:
ZooKeeper è un file system semplificato. Questo è un po' simile a Hadoop, ma il file system di ZooKeeper gestisce file piccoli, mentre Hadoop gestisce file molto grandi.
Zookeeper fornisce una ricchezza di "artefatti" che permettono a molte operazioni di coordinare strutture dati e protocolli. Ad esempio: code distribuite, lock distribuiti e l'algoritmo di "elezione del leader" di un gruppo di nodi allo stesso livello.
ZooKeeper è molto disponibile, la sua stabilità è piuttosto buona, i cluster distribuiti possono fare affidamento sulla gestione dei cluster Zookeeper, e ZooKeeper viene utilizzato per evitare il problema del guasto puntuale singolo dei sistemi distribuiti.
Zookeeper adotta una modalità di interazione debolmente accoppiata. Questo è particolarmente evidente nel fatto che zookeeper fornisce locks distribuiti, che possono essere usati come meccanismo di appuntamento per permettere ai processi partecipanti di scoprire e interagire tra loro senza conoscere gli altri processi (o la rete), e le parti partecipanti non devono nemmeno esistere contemporaneamente, purché lasci un messaggio in zookeeper e, dopo la fine del processo, un altro processo possa leggere questo messaggio, disaccoppiando così la relazione tra i nodi.
ZooKeeper fornisce un repository condiviso per il cluster, dal quale il cluster può leggere e scrivere informazioni condivise centralmente, evitando la programmazione di operazioni condivise per ogni nodo e riducendo la difficoltà di sviluppo dei sistemi distribuiti.
Zookeeper è principalmente responsabile di memorizzare e gestire i dati a cui tutti tengono, e poi di accettare la registrazione degli osservatori; una volta cambiato lo stato di questi dati, Zookeeper sarà responsabile di notificare quegli osservatori registrati su Zookeeper affinché rispondano di conseguenza, così da ottenere una modalità di gestione master/slave simile a quella del cluster.
Si può vedere che lo zookeeper è molto favorevole allo sviluppo di sistemi distribuiti, il che può rendere i sistemi distribuiti più robusti ed efficienti.
Non molto tempo fa, ho partecipato al gruppo di interesse hadoop del dipartimento, e ho installato hadoop, mapreduce, Hive e Hbase nell'ambiente di test, e ho installato zookeeper in anticipo quando installavo hbase. Zookeeper può fornire servizi, quindi più della metà dei 3 sono 2, e più della metà dei 4 sono anche due, quindi installare tre server può ottenere l'effetto di 4 server. Nel processo di apprendimento di Hadoop, penso che Zookeeper sia il sottoprogetto più difficile da comprendere, il motivo non è che sia tecnicamente responsabile, ma che la sua direzione applicativa mi risulta molto confusa, quindi il mio primo articolo sulla tecnologia Hadoop inizia con ZooKeeper e non parla di implementazioni tecniche specifiche, ma dagli scenari applicabili di Zookeeper capisco il campo dell'applicazione di Zookeeper, penso che imparare Zookeeper sarà più efficace con metà sforzo.
Il motivo per cui voglio parlare oggi di zookeeper è per integrare il framework distribuito del sito web nel mio articolo precedente. Anche se ho progettato l'architettura del sito web come una struttura distribuita, ho anche creato un semplice meccanismo di gestione dei guasti, come il meccanismo cardiaco, ma non c'è ancora modo di risolvere il singolo punto di guasto del cluster: se un server si rompe, il client cercherà di connettersi a quel server, bloccando alcune richieste e portando anche allo spreco di risorse del server. Tuttavia, al momento non voglio modificare il mio framework, perché penso sempre che aggiungere il servizio di custodia zoologica ai servizi esistenti influenzerà l'efficienza del sito. Fortunatamente, anche il nostro dipartimento ha riscontrato un problema simile: svilupperà un potente framework per chiamate remote, separerà la gestione del cluster e la gestione delle comunicazioni e fornirà servizi efficienti e disponibili in modo centrale.
Trasferito da ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Pubblicato su 18/07/2017 14:19:01
|
|
|
