![Guardiano dello zoo o come vive un lavoratore dello zoo - 1]()
introduzione
Le applicazioni Java hanno spesso configurazioni diverse. Ad esempio, indirizzo e porta di connessione. Ad esempio, potrebbe apparire così se utilizzassimo la classe
Properties :
public static void main(String []args) {
Properties props = new Properties();
props.setProperty("host", "www.tutorialspoint.com");
System.out.println("Hello, " + props.getProperty("host"));
}
E questo sembra bastare, perché... possiamo ottenere Proprietà dal file. E tutto sembra andare d'accordo con noi su una macchina. Ma immaginiamo che il nostro sistema inizi a consistere di sistemi diversi separati gli uni dagli altri? Un tale sistema è anche chiamato sistema distribuito. Su Wikipedia si trova la seguente definizione:
I sistemi distribuiti sono sistemi i cui componenti si trovano su diversi computer della rete che comunicano tra loro e coordinano le loro azioni scambiando messaggi tra loro. Puoi guardare il seguente diagramma:
Con questo approccio, un unico sistema viene suddiviso in componenti. La configurazione è un componente comune separato. Ciascuno degli altri componenti funge da client per il componente di configurazione. Questo caso è chiamato "
Configurazione distribuita ". Esistono molte implementazioni diverse della configurazione distribuita. E nella recensione di oggi propongo di conoscerne uno, che si chiama Zookeeper.
Guardiano dello zoo
Il percorso per conoscere Zookeeper inizia dal loro sito ufficiale:
zookeeper.apache.org Sul sito ufficiale è necessario andare nella sezione “
Download ” . In questa sezione scaricare l’archivio in formato .tar.gz, ad esempio “zookeeper-3.4.13.tar.gz”. tar è un formato di archivio tradizionale per i sistemi Unit. gz - significa che gzip viene utilizzato per comprimere l'archivio. Se lavoriamo su una macchina Windows, questo non dovrebbe disturbarci. La maggior parte degli archiviatori moderni (ad esempio
7-zip ) possono funzionare perfettamente con loro su Windows. Estraiamo il contenuto in una directory. Allo stesso tempo, vedremo la differenza: sul disco nello stato estratto occuperà circa 60 megabyte e abbiamo scaricato un archivio di circa 35 megabyte. Come puoi vedere, la compressione funziona davvero. Ora devi avviare Zookeeper. In generale, Zookeeper è una sorta di server. Zookeeper può essere eseguito in due modalità:
autonoma o
replicata . Consideriamo l'opzione più semplice, nota anche come prima opzione: la modalità autonoma. Per poter funzionare Zookeper ha bisogno di un file di configurazione. Pertanto, creiamolo qui:
[КаталогРаспаковкиZookeeper]/conf/zoo.cfg. Per Windows utilizzeremo il consiglio di Medium: “
Installazione di Apache ZooKeeper su Windows ”. Il contenuto del file di configurazione sarà simile a questo:
tickTime=2000
dataDir=C:/zookeeper-3.4.13/data
clientPort=2181
Aggiungiamo la variabile d'ambiente ZOOKEEPER_HOME contenente il percorso della directory root di zookeper (come nelle istruzioni su medium) e aggiungiamo anche il seguente frammento alla variabile d'ambiente PATH:
;%ZOOKEEPER_HOME%\bin; Inoltre, la directory specificata in dataDir deve esistere, altrimenti Zookeeper non sarà in grado di avviare il server. Ora possiamo avviare in sicurezza il server utilizzando il comando: zkServer. Grazie al fatto che la directory Zookeeper è stata aggiunta alla variabile d'ambiente path, possiamo chiamare i comandi Zookeper da qualsiasi luogo, non solo dalla directory bin.
ZNodo
Come affermato nella "
Panoramica Zookeeper ", i dati in Zookeper sono rappresentati sotto forma di
ZNodes (nodi) organizzati in una struttura ad albero. Cioè, ogni ZNode può contenere dati e avere ZNode figli. Maggiori informazioni sull'organizzazione ZNode possono essere trovate nella documentazione di Zookeeper: "
Modello di dati e spazio dei nomi gerarchico ". Per lavorare con Zookeeper e ZNode utilizzeremo
Zookeeper CLI (interfaccia della riga di comando). In precedenza, abbiamo avviato il server utilizzando il comando zkServer. Adesso per connetterci eseguiamo,
zkCli.cmd -server 127.0.0.1:2181 in caso di successo verrà creata una sessione di connessione a Zookeeper e vedremo approssimativamente il seguente output:
È interessante notare che, anche subito dopo l'installazione, Zookeeper ha già ZNode. Ha il seguente percorso:
/zookeeper/quota
Queste sono le cosiddette "
quote ". Come affermato in "
Apache ZooKeeper Essentials ", a ogni ZNode può essere associata una quota, limitando i dati che può archiviare. È possibile specificare un limite al numero di znode e alla quantità di dati archiviati. Inoltre, se questo limite viene superato, l'operazione con ZNode non verrà annullata, ma verrà ricevuto un avviso in caso di superamento del limite. Si consiglia di leggere informazioni su ZNode nella "
Guida del programmatore ZooKeeper: ZNodes ". Alcuni esempi da lì di come puoi lavorare con ZNode:
Vorrei anche notare che gli ZNode sono diversi. Gli ZNode regolari (a meno che non si specifichino flag aggiuntivi) sono di tipo "
persistente ". Esiste uno ZNode del tipo "
Nodo Effimero ". Tali ZNode esistono solo per la durata della sessione di connessione Zookeeper all'interno della quale sono stati creati. Esiste uno ZNode di tipo "
Sequence Node ". A questi ZNode viene aggiunto un numero dalla sequenza per garantire l'unicità. Il nodo sequenza può essere persistente o effimero. Si consigliano anche alcune informazioni di base su ZNode: “
ZNode Zookeeper – Caratteristiche ed esempio ”.
Osservatore ZNode
Vorrei parlare anche degli osservatori. I dettagli su di essi sono scritti nella documentazione di Zookeeper: "
ZooKeeper Watches ". In breve, un osservatore è un trigger occasionale che viene attivato da qualche evento. Recuperando i dati eseguendo le operazioni getData(), getChildren() o esiste(), possiamo creare un trigger come azione aggiuntiva. Zookeeper garantisce l'ordine in cui viene elaborato l'evento. Inoltre, la documentazione afferma che prima di poter vedere il nuovo valore ZNode, vedremo un evento relativo alla modifica del vecchio valore con quello nuovo. Puoi leggere ulteriori informazioni sugli Watchers qui: “
Orologi ZooKeeper – Caratteristiche e garanzie ”. Per provarlo, utilizziamo nuovamente
la CLI : supponiamo di avere alcuni ZNode con un valore in cui memorizziamo lo stato di alcuni servizi:
[zk: 127.0.0.1:2181(CONNECTED) 0] create /services/service1/status stopped
Created /services/service1/status
[zk: 127.0.0.1:2181(CONNECTED) 1] get /services/service1/status [watch]
stopped
Ora, se i dati
/services/service1/statuscambiano, si attiverà il nostro trigger una tantum:
È interessante notare che quando ci connettiamo a Zookeeper vediamo anche come funziona l'osservatore:
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
SyncConnected è uno dei possibili eventi Zookeper. Maggiori dettagli a riguardo possono essere trovati nella descrizione dell'API.
Guardiano dello zoo e Java
Ora abbiamo una conoscenza di base di ciò che Zookeeper può fare. Ora lavoriamo con Java e non tramite la CLI. E per questo avremo bisogno di un'applicazione Java, nella quale vedremo come lavorare con Zookeeper. Per creare l'applicazione, utilizzeremo il sistema di compilazione del progetto
Gradle . Utilizzando il "
Plugin Gradle Build Init " creeremo il progetto. Per fare ciò, eseguiamo il comando:
gradle init --type java-application Se Gradle ci chiede domande chiarificatrici, lasceremo i valori predefiniti (basta premere Invio). Ora apriamo lo script di build, ad es. file build.gradle. Contiene una descrizione di cosa è fatto il nostro progetto e da quali artefatti (librerie, framework) dipende. Perché vogliamo usare Zookeeper, quindi dobbiamo aggiungerlo. Pertanto, aggiungiamo una dipendenza da Zookeeper al blocco delle dipendenze:
dependencies {
implementation 'org.apache.zookeeper:zookeeper:3.4.13'
Puoi leggere di più su Gradle nella recensione: "
A Brief Introduction to Gradle ". Quindi, abbiamo un progetto Java, ad esso abbiamo collegato la libreria Zookeeper. Scriviamo qualcosa adesso. Come ricordiamo, utilizzando la CLI abbiamo collegato qualcosa del genere:
zkCli.cmd -server 127.0.0.1:2181 Dichiariamo l'attributo "server" nella classe App nel metodo principale:
String server = "127.0.0.1:2181";
La connessione non è un'azione immediata. Dovremo attendere in qualche modo nel thread principale dell'esecuzione del programma affinché avvenga la connessione. Pertanto, abbiamo bisogno di un lucchetto. Dichiariamolo di seguito:
Object lock = new Object();
Ora abbiamo bisogno che qualcuno dica che la connessione è stata stabilita. Come ricordiamo, quando lo facevamo tramite la CLI, l'osservatore lavorava per noi. Quindi nel codice Java tutto è esattamente lo stesso. Il nostro osservatore visualizzerà un messaggio relativo al completamento riuscito e avviserà tutti coloro che lo attendono tramite un lucchetto. Scriviamo un osservatore:
Watcher connectionWatcher = new Watcher() {
public void process(WatchedEvent we) {
if (we.getState() == Event.KeeperState.SyncConnected) {
System.out.println("Connected to Zookeeper in " + Thread.currentThread().getName());
synchronized (lock) {
lock.notifyAll();
}
}
}
};
Ora aggiungiamo la connessione al server zooKeeper:
int sessionTimeout = 2000;
ZooKeeper zooKeeper = null;
synchronized (lock) {
zooKeeper = new ZooKeeper(server, sessionTimeout, connectionWatcher);
lock.wait();
}
Tutto è semplice qui. Quando eseguiamo il metodo main nel thread principale del programma, afferriamo il lock e richiediamo una connessione allo zookeeper. Allo stesso tempo, rilasciamo il lucchetto e aspettiamo che qualcun altro lo afferri e ci avvisi che possiamo continuare. Una volta stabilita la connessione, l'osservatore funzionerà. Controllerà che sia arrivato l'evento SyncConnected (come ricordiamo, questo è ciò che l'osservatore ha catturato tramite la CLI), quindi scriverà un messaggio. Successivamente, prendiamo il lock (poiché il thread principale lo ha rilasciato in precedenza) e comunichiamo a tutti i thread in attesa del lock che possiamo continuare. Il thread di elaborazione degli eventi esce dal blocco sincronizzato, rilasciando così il blocco. Il thread principale ha ricevuto una notifica e, dopo aver atteso il rilascio del blocco, continua l'esecuzione, perché finché non riceve il blocco, non sarà in grado di uscire dal blocco sincronizzato e continuare a lavorare. Pertanto, utilizzando il multithreading e l'API Zookeeper, possiamo eseguire varie azioni. L'API Zookeeper è molto più ampia di quanto consentito dalla CLI. Per esempio:
String znodePath = "/zookeepernode2";
List<ACL> acls = ZooDefs.Ids.OPEN_ACL_UNSAFE;
if (zooKeeper.exists(znodePath, false) == null) {
zooKeeper.create(znodePath, "data".getBytes(), acls, CreateMode.PERSISTENT);
}
byte[] data = zooKeeper.getData(znodePath, null, null);
System.out.println("Result: " + new String(data, "UTF-8"));
Come puoi vedere, quando creiamo un nodo possiamo configurare un ACL. Questa è un'altra caratteristica importante. Gli ACL sono permessi che si applicano alle azioni con ZNode. Ci sono molte impostazioni, quindi ti consiglio di fare riferimento alla documentazione ufficiale per i dettagli: “
Autorizzazioni ACL Zookeeper ”.
Conclusione
Perché abbiamo letto questo? Perché Zookeeper è utilizzato in altre tecnologie popolari. Ad esempio, Apache Kafka richiede Zookeeper, di cui puoi leggere la "
Guida rapida a Kafka ". Viene utilizzato anche nel database NOSQL HBase, di cui puoi leggere ulteriori informazioni nella loro "
HBase Quickstart Guide ". In effetti, molti altri progetti utilizzano Zookeeper. Alcuni di essi sono elencati in "
Utilizzo di Zookeeper nel mondo reale ". Spero di aver risposto alla domanda “perché”. La domanda più importante ora è: “Qual è il prossimo passo?” Innanzitutto, puoi leggere i seguenti libri sull'argomento Apache Zookeeper:
In secondo luogo, ci sono eccellenti reportage video su Zookeeper. Visione consigliata:
In terzo luogo, ci sono diversi articoli utili che completeranno il quadro del mondo:
Questa è una recensione molto breve, ma come parola introduttiva, spero che possa essere utile. #Viacheslav
GO TO FULL VERSION