Hazelcast (Java) und ETCD (Golang) Unterschiede/Gemeinsamkeiten?

Question

Jetzt bauen wir ein Echtzeit-Analytik-System und es sollte hoch verteilt werden. Wir planen, verteilte Sperren und Zähler zu verwenden, um die Datenkonsistenz sicherzustellen, und wir benötigen eine Art verteilter Karte, um zu wissen, welcher Client mit welchem ​​Server verbunden ist. Ich habe keine Erfahrung in verteilten Systemen vor, aber ich denke, wir haben zwei Möglichkeiten:

1. Java + Hazelcast

2. Golang + ETCD

Aber was die Profis ist/Nachteile von einander im Thema Kontext?

Answer 1

Hazelcast und etcd sind zwei sehr unterschiedliche Systeme. Der Grund ist der CAP theorem.

Das CAP-Theorem besagt, dass kein verteiltes System Konsistenz, Verfügbarkeit und Partitionstoleranz haben kann. Verteilte Systeme fallen normalerweise näher an CA oder CP. Hazelcast ist ein AP-System, und etcd (eine Raft-Implementierung) ist CP. Sie haben also die Wahl zwischen Konsistenz und Verfügbarkeit/Leistung.

Im Allgemeinen wird Hazelcast leistungsfähiger und in der Lage sein, mehr Fehler als Raft und etcd zu behandeln, aber auf Kosten von möglichen Datenverlust oder Konsistenzproblemen. Die Art, wie Hazelcast funktioniert, teilt Daten auf und speichert Teile der Daten auf verschiedenen Knoten. In einem 5-Knoten-Cluster kann also der Schlüssel "foo" auf Knoten 1 und 2 gespeichert werden und der Balken auf Knoten 3 und 4. Sie können die Anzahl der Knoten steuern, auf die Hazelcast Daten über den Hazelcast und die Karte repliziert Aufbau. Bei einem Netzwerk- oder sonstigen Ausfall besteht jedoch das Risiko, dass in Hazelcast alte Daten angezeigt oder Daten verloren gehen.

Alternativ dazu sind Raft und etcd ein Single-Leader-System mit hoher Konsistenz, das Daten auf allen Knoten speichert. Dies bedeutet, dass es nicht ideal ist, um große Mengen an Zustand zu speichern. Aber auch während eines Netzwerkausfalls kann etcd garantieren, dass Ihre Daten konsistent bleiben. Mit anderen Worten, Sie werden nie alte/veraltete Daten sehen. Aber das hat seinen Preis. CP-Systeme erfordern, dass eine Mehrheit des Clusters am Leben ist, um normal zu arbeiten.

Das Konsistenzproblem kann für den grundlegenden Schlüsselwertspeicher relevant sein oder auch nicht, kann aber für Sperren extrem relevant sein. Wenn Sie erwarten, dass Ihre Sperren im gesamten Cluster konsistent sind - dh nur ein Knoten kann eine Sperre auch während eines Netzwerks oder eines anderen Fehlers halten - tun Sie nicht Verwenden Sie Hazelcast. Da Hazelcast die Konsistenz zugunsten der Verfügbarkeit opfert (siehe auch das CAP-Theorem), ist es durchaus möglich, dass ein Netzwerkfehler dazu führt, dass zwei Knoten glauben, dass eine Sperre frei erworben werden kann.

Alternativ garantiert Raft, dass während eines Netzwerkausfalls nur ein Knoten der Anführer des etcd-Clusters bleibt und daher alle Entscheidungen über diesen einen Knoten getroffen werden. Das bedeutet, dass etcd jederzeit eine konsistente Ansicht des Clusterstatus gewährleisten kann und sicherstellen kann, dass eine Sperre nur durch einen einzigen Prozess erhalten werden kann.

Wirklich, Sie müssen überlegen, was Sie in Ihrer Datenbank suchen und gehen Sie es suchen. Die Anwendungsfälle für CP- und AP-Datenspeicher sind sehr unterschiedlich. Wenn Sie Konsistenz für das Speichern kleiner Mengen von Staat, konsistente Sperren, Führerwahlen und andere Koordinationswerkzeuge wünschen, verwenden Sie ein CP-System wie ZooKeeper oder Consul. Wenn Sie eine hohe Verfügbarkeit und Leistung bei den potenziellen Kosten der Konsistenz wünschen, verwenden Sie Hazelcast oder Cassandra oder Riak.

Quelle: Ich bin der Autor des a Raft implementation