Differenze/similarità di Hazelcast (Java) e ETCD (golang)?

Question

Ora stiamo creando un sistema di analisi in tempo reale e dovrebbe essere altamente distribuito. Prevediamo di utilizzare blocchi e contatori distribuiti per garantire la coerenza dei dati e abbiamo bisogno di un qualche tipo di mappa distribuita per sapere quale client è connesso a quale server. Non ho esperienza prima in sistemi distribuiti prima, ma penso che abbiamo due opzioni:

1. Java + Hazelcast

2. Golang + ETCD

Ma che cosa è i pro/contro l'altro nel contesto dell'argomento?

Answer 1

Hazelcast e etcd sono due sistemi molto diversi. Il motivo è CAP theorem.

Il teorema CAP afferma che nessun sistema distribuito può avere coerenza, disponibilità e tolleranza di partizione. I sistemi distribuiti normalmente si avvicinano a CA o CP. Hazelcast è un sistema AP, e etcd (essendo un'implementazione Raft) è CP. Quindi, la tua scelta è tra coerenza e disponibilità/prestazioni.

In generale, Hazelcast sarà molto più performante e sarà in grado di gestire più guasti rispetto a Raft e etcd, ma a costo di potenziali perdite di dati o problemi di coerenza. Il modo in cui funziona Hazelcast è partizioni di dati e memorizza parti dei dati su diversi nodi. Quindi, in un cluster a 5 nodi, la chiave "foo" può essere archiviata sui nodi 1 e 2 e la barra può essere archiviata sui nodi 3 e 4. È possibile controllare il numero di nodi a cui Hazelcast replica i dati tramite l'Hazelcast e la mappa configurazione. Tuttavia, durante una rete o altri errori, c'è il rischio che vedrai vecchi dati o addirittura perdi dati in Hazelcast.

In alternativa, Raft ed etcd è un sistema altamente coerente con un unico leader che memorizza i dati su tutti i nodi. Ciò significa che non è l'ideale per la memorizzazione di grandi quantità di stato. Ma anche durante un errore di rete, etcd può garantire che i tuoi dati rimarranno coerenti. In altre parole, non vedrai mai dati vecchi/obsoleti. Ma questo ha un costo. I sistemi CP richiedono che la maggioranza del cluster sia attiva per funzionare normalmente.

Il problema di coerenza può essere rilevante o meno per l'archiviazione di valori-chiave di base, ma può essere estremamente rilevante per i blocchi. Se ti aspetti che i blocchi siano coerenti su tutto il cluster, ovvero solo un nodo può contenere un blocco anche durante una rete o un altro errore, fare non utilizzare Hazelcast. Poiché Hazelcast sacrifica la coerenza a favore della disponibilità (ancora, vedi il teorema CAP), è del tutto possibile che un errore di rete possa portare due nodi a credere che un blocco sia libero di essere acquisito.

In alternativa, Raft garantisce che durante un errore di rete solo un nodo rimarrà il leader del cluster etcd, e quindi tutte le decisioni vengono prese attraverso quel nodo. Ciò significa che etcd può garantire che abbia una visione coerente dello stato del cluster in ogni momento e può garantire che qualcosa come un lucchetto possa essere ottenuto solo con un singolo processo.

In realtà, è necessario prendere in considerazione ciò che si sta cercando nel database e andare a cercarlo. I casi d'uso per gli archivi di dati CP e AP sono molto diversi. Se si desidera coerenza per la memorizzazione di piccole quantità di stato, serrature coerenti, elezioni per leader e altri strumenti di coordinamento, utilizzare un sistema CP come ZooKeeper o Console. Se si desidera disponibilità elevata e prestazioni al potenziale costo di coerenza, utilizzare Hazelcast o Cassandra o Riak.

Fonte: Io sono l'autore di a Raft implementation