https://zookeeper.apache.org/doc/current/zookeeperOver.html
Per impostazione predefinita, Zookeeper replica tutti i tuoi dati su ogni nodo e consente ai client di guardare i dati per le modifiche. Le modifiche vengono inviate molto rapidamente (entro un periodo di tempo limitato) ai clienti. Puoi anche creare "nodi temporanei", che vengono eliminati entro un tempo specificato se un client si disconnette. ZooKeeper è altamente ottimizzato per le letture , mentre le scritture sono molto lente (poiché generalmente vengono inviate a ogni client non appena avviene la scrittura). Infine, la dimensione massima di un "file" (znode) in Zookeeper è 1 MB, ma in genere saranno stringhe singole.
Nel complesso, ciò significa che zookeeper non è pensato per archiviare molti dati e sicuramente non una cache. Invece, serve per gestire i battiti cardiaci/sapere quali server sono online, archiviare/aggiornare la configurazione e possibilmente il passaggio di messaggi (sebbene se si dispone di un numero elevato di messaggi o di richieste di throughput elevate, qualcosa come RabbitMQ sarà molto meglio per questo compito).
Fondamentalmente, ZooKeeper (e Curator, che è basato su di esso) aiuta a gestire i meccanismi del clustering:heartbeat, distribuzione di aggiornamenti/configurazione, blocchi distribuiti, ecc.
Non è proprio paragonabile a Redis, ma per le domande specifiche...
-
Non supporta alcun calcolo e per la maggior parte dei set di dati, non sarà in grado di archiviare i dati con alcuna prestazione.
-
Viene replicato su tutti i nodi del cluster (non c'è niente come il clustering Redis in cui i dati possono essere distribuiti). Tutti i messaggi vengono elaborati atomicamente per intero e sono sequenziati, quindi non ci sono transazioni reali. Può essere USATO per implementare blocchi a livello di cluster per i tuoi servizi (è molto utile in questo in effetti) e ci sono molte primitive di blocco sugli znode stessi per controllare a quali nodi accedono.
-
Certo, ma ZooKeeper riempie una nicchia. È uno strumento per far funzionare bene le applicazioni distribuite con più istanze, non per archiviare/condividere grandi quantità di dati. Rispetto all'utilizzo di un IMDG per questo scopo, Zookeeper sarà più veloce, gestisce i battiti cardiaci e la sincronizzazione in modo prevedibile (con molte API per semplificare questa parte) e ha un paradigma "push" invece di "pull", quindi i nodi sono notificato molto rapidamente delle modifiche.
La citazione dalla domanda collegata...
Un esempio canonico di utilizzo di Zookeeper è il calcolo a memoria distribuita
... è, IMO, un po' fuorviante. Lo useresti per orchestrare il calcolo, non per fornire i dati. Ad esempio, supponiamo che tu debba elaborare le righe 1-100 di una tabella. Potresti inserire 10 nodi ZK, con nomi come "1-10", "11-20", "21-30", ecc. Le applicazioni client riceverebbero automaticamente una notifica di questa modifica da ZK e il primo afferrerebbe " 1-10" e imposta un nodo temporaneo clients/192.168.77.66/processing/rows_1_10
L'applicazione successiva lo vedrà e passerà al gruppo successivo da elaborare. I dati effettivi da calcolare verrebbero archiviati altrove (ad esempio Redis, database SQL, ecc.). Se il nodo non è riuscito a metà del calcolo, un altro nodo potrebbe vederlo (dopo 30-60 secondi) e riprendere il lavoro.
Direi che l'esempio canonico di ZooKeeper è l'elezione del leader, però. Diciamo che hai 3 nodi:uno è master e gli altri 2 sono slave. Se il master va giù, un nodo slave deve diventare il nuovo leader. Questo tipo di cose è perfetto per ZK.
