Ich mache ein einfaches Benchmarking mit Hazelcast, um zu sehen, ob es unseren Anforderungen für ein verteiltes Datengrid entspricht. Die Idee ist eine ungerade Anzahl von Servern (zB 5) mit '> n/2' Replikation (zB 3).Ist Hazelcast async transitiv schreiben?
Mit allen Servern und Client auf meinem lokalen Rechner ausgeführt wird (kein Netzwerk-Latenz) Ich nehme die folgenden Ergebnisse erhalten:
5 x H/C server (sync backup = 2, async backup = 0); 100 Client Threads : 35,196 puts/second
5 x H/C server (sync backup = 1, async backup = 1); 100 Client Threads : 41,918 puts/second
5 x H/C server (sync backup = 0, async backup = 2); 100 Client Threads : 52,007 puts/second
Wie erwartet, Asynchron-Backups ermöglichen einen höheren Durchsatz als Sync-Backups. Für unseren Anwendungsfall würden wir uns wahrscheinlich für die mittlere Option (1x Sync und 1x Async) entscheiden, da dies ein akzeptables Gleichgewicht zwischen Belastbarkeit und Leistung bietet.
Meine Frage ist: Wenn Hazelcast mit 1x sync und 1x async konfiguriert ist und der Knoten abstürzt, nachdem die Synchronisierungssicherung ausgeführt wurde (Server gibt 'OK' an Client- und Client-Thread weiter), aber bevor die asynchrone Sicherung ausgeführt wird (Damit die Daten nur auf einer Replik und nicht auf der zweiten Replik vorliegen), wird der Knoten, der die Synchronisierungssicherung empfangen hat, die Aufgabe der asynchronen Sicherung übernehmen, oder wird nur gewartet, bis der gesamte Cluster die "fehlenden" Daten ausgeglichen hat von dem abgestürzten Knoten wird von Kopien neu verteilt? Und wenn der Cluster neu ausbalanciert wird, werden insgesamt 3 Kopien der Daten vorhanden sein, so wie es der Fall gewesen wäre, wenn der Knoten nicht abgestürzt wäre, oder wenn nur 2 Kopien vorhanden sind, weil der Sync-Knoten annimmt dass ein anderer Knoten bereits seine Kopie erhalten hat?