Systemdesign-Hacks:

Feb 23 2023

5.) AP (Verfügbarkeit mit Partitionstoleranz) – Cassandra, Dynamo, CouchDB, Riak, Elastic Search, MongoDB (repliziert).

) Schweres System schreiben – Referenz-1 , Referenz-2
) Schweres System lesen – Referenz-1 , Referenz-2
) CAP-Theorem -

5.) AP (Verfügbarkeit mit Partitionstoleranz) – Cassandra, Dynamo, CouchDB, Riak, Elastic Search, MongoDB (repliziert).

6.) CA (Konsistenz mit Verfügbarkeit) – MySQL, Postgres.

Referenz-Kurznotizen:

MongoDB – MongoDB ist standardmäßig stark konsistent. Wenn Sie einen Schreibvorgang und dann einen Lesevorgang ausführen, können Sie, sofern der Schreibvorgang erfolgreich war, immer das Ergebnis des gerade gelesenen Schreibvorgangs lesen. Dies liegt daran, dass MongoDB ein Single-Master-System ist und alle Lesevorgänge standardmäßig an das Primärsystem gehen. Wenn Sie optional das Lesen von den sekundären Datenbanken aktivieren, wird MongoDB schließlich konsistent, sodass veraltete Ergebnisse gelesen werden können. MongoDB erhält außerdem Hochverfügbarkeit durch automatisches Failover in Replikatsätzen:http://www.mongodb.org/display/DOCS/Replica+Sets

Redis-Cluster-Konsistenzgarantien -

Redis Cluster garantiert keine starke Konsistenz. In der Praxis bedeutet dies, dass es unter bestimmten Bedingungen möglich ist, dass Redis-Cluster Schreibvorgänge verlieren, die vom System gegenüber dem Client bestätigt wurden.

Der erste Grund, warum Redis-Cluster Schreibvorgänge verlieren können, liegt darin, dass er asynchrone Replikation verwendet. Das bedeutet, dass beim Schreiben Folgendes passiert:

Ihr Kunde schreibt an den Master B.

Der Master B antwortet Ihrem Kunden mit „OK“.

Der Master B gibt den Schreibvorgang an seine Replikate B1, B2 und B3 weiter.

Wie Sie sehen, wartet B nicht auf eine Bestätigung von B1, B2, B3, bevor es dem Client antwortet, da dies eine unerschwingliche Latenzstrafe für Redis bedeuten würde. Wenn Ihr Client also etwas schreibt, bestätigt B den Schreibvorgang, stürzt jedoch vorher ab Da es in der Lage ist, den Schreibvorgang an seine Replikate zu senden, kann eines der Replikate (das den Schreibvorgang nicht erhalten hat) zum Master befördert werden, wodurch der Schreibvorgang für immer verloren geht.

In Redis ist Hochverfügbarkeit mehr als Partitionstoleranz. Redis verfügt über eine Master-Slave-Architektur. Wenn ein Master ausfällt, befördern Redis Sentinels einen Slave zum neuen Master, wodurch die gesamte Lösung hochverfügbar wird. Und ein Master kann aus verschiedenen Gründen (z. B. nicht genügend Speicher) ausfallen (oder nicht verfügbar sein). Dies liegt jedoch nicht unbedingt an einer Netzwerkpartition.

Dann kommt der Fall der Netzwerkpartition (P), und wenn (P) auftritt, ist Redis in der Minderheitspartition nicht mehr verfügbar. Deshalb ist Redis aus CAP-Sicht CP, weil es in Minderheitspartitionen nicht mehr verfügbar ist. Bitte beachten Sie, dass es weiterhin in der Mehrheitspartition verfügbar sein wird.

Mehr über Redis High Availability können Sie hier lesen . Einzelheiten zur Partitionierung finden Sie im Abschnitt „Konsistenz unter Partitionen“.

Redis wird auch als „eventuell konsistent“ bezeichnet, da bei (P) die Minderheitspartition noch einige Sekunden lang verfügbar ist und alle während dieser Zeit auf der Minderheitspartition durchgeführten Schreibvorgänge schließlich verworfen werden.