Wenn man auf ein Produkt stößt, das seit über einem Jahrzehnt entwickelt wird, ist es nicht überraschend, veraltete Technologien anzutreffen. Aber was, wenn Sie in sechs Monaten eine Last tragen müssen, die zehnmal höher ist, und die Kosten für Ausfälle um ein Vielfaches steigen? In diesem Fall benötigen Sie einen talentierten Highload-Engineer. Aber da es einen solchen nicht gab, wurde mir die Lösung des Problems anvertraut. Im ersten Teil des Artikels berichte ich darüber, wie wir von Redis zu Redis-Cluster gewechselt sind, und im zweiten Teil gebe ich Ratschläge, wie man mit dem Cluster arbeitet und worauf man bei der Nutzung achten sollte.

Technologieauswahl

Ist ein einzelnes Redis (standalone redis) in der Konfiguration 1 Master und N Slaves so schlecht? Warum nenne ich es eine veraltete Technologie?

Nein, Redis ist nicht so schlecht… Es gibt jedoch einige Mängel, die man nicht ignorieren kann.

• Erstens unterstützt Redis keine Mechanismen zur Wiederherstellung nach dem Ausfall des Masters. Um dieses Problem zu lösen, haben wir eine Konfiguration verwendet, die eine automatische Umleitung von VIPs zu einem neuen Master, die Rollenänderung eines Slaves und das Umschalten des Restes beinhaltete. Dieser Mechanismus funktionierte, aber man konnte ihn nicht als zuverlässige Lösung bezeichnen. Erstens gab es Fehlalarme, und zweitens war er einmalig, und nach dem Auslösen waren manuelle Eingriffe nötig, um die Feder zurückzusetzen.

• Zweitens führte das Vorhandensein nur eines Masters zu einem Problem mit der Shardierung. Es war notwendig, mehrere unabhängige Cluster „1 Master und N Slaves“ zu erstellen, die Datenbanken manuell auf diesen Maschinen zu verteilen und zu hoffen, dass eine der Datenbanken am nächsten Tag nicht so groß wird, dass sie auf eine separate Instanz verschoben werden muss.

Was sind die Optionen?

• Die teuerste und umfassendste Lösung ist Redis-Enterprise. Dies ist eine Boxlösung mit vollständigem technischem Support. Obwohl es aus technischer Sicht perfekt aussieht, passte es uns aus ideologischen Gründen nicht.
• Redis-Cluster. Aus der Box heraus gibt es Unterstützung für die Notfallumschaltung des Masters und die Shardierung. Die Schnittstelle unterscheidet sich kaum von der normalen Version. Sie sieht vielversprechend aus; auf die Fallstricke gehen wir später ein.
• Tarantool, Memcache, Aerospike und andere. Alle diese Tools tun im Grunde das Gleiche. Aber jedes hat seine eigenen Nachteile. Wir haben uns entschieden, nicht alle Eier in einen Korb zu legen. Memcache und Tarantool verwenden wir für andere Aufgaben, und um vorzugreifen, kann ich sagen, dass wir in unserer Praxis mehr Probleme mit ihnen hatten.

Spezifik der Nutzung

Lassen Sie uns einen Blick darauf werfen, welche Aufgaben wir historisch mit Redis gelöst haben und welche Funktionen wir genutzt haben:

• Cache vor Anfragen an externe Dienste wie 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Cache vor MYSQL | PHP
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• Hauptspeicher für den Dienst zur Verwaltung von Sitzungen und Fahrerkoordinaten | Golang
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

Wie Sie sehen, keine höhere Mathematik. Wo liegt dann die Schwierigkeit? Lassen Sie uns die einzelnen Methoden genauer betrachten.

Methode
Beschreibung
Besonderheiten von Redis-Cluster
Lösung

GET SET
Schlüssel schreiben/lesen

MGET MSET
Mehrere Schlüssel schreiben/lesen
Die Schlüssel werden auf verschiedenen Knoten liegen. Vorhandene Bibliotheken können Multi-Operationen nur innerhalb eines Knotens durchführen.
MGET durch eine Pipeline aus N GET-Operationen ersetzen

SELECT DB
Wählen Sie die Datenbank, mit der wir arbeiten wollen
Unterstützt keine mehreren Datenbanken
Alles in einer Datenbank speichern. Fügen Sie den Schlüsseln Präfixe hinzu.

SCAN
Alle Schlüssel in der Datenbank durchlaufen
Da wir nur eine Datenbank haben, ist das Durchlaufen aller Schlüssel im Cluster zu kostenintensiv.
Das Invarianz innerhalb eines Schlüssels aufrecht erhalten und HSCAN für diesen Schlüssel durchführen. Oder ganz darauf verzichten.

GEO
Operationen mit Geokey
Geokey wird nicht partitioniert

KEY BY PATTERN
Schlüssel nach Muster suchen
Da wir nur eine Datenbank haben, werden wir nach allen Schlüsseln im Cluster suchen. Zu kostenintensiv.
Aufgeben oder Invarianz aufrechterhalten, wie im Fall mit SCAN.

Redis vs Redis-Cluster

Was verlieren wir und was gewinnen wir bei der Umstellung auf ein Cluster?

• Nachteile: Verlust der Funktionalität mehrerer Datenbanken.
  • Wenn wir in einem Cluster logisch nicht verbundene Daten speichern wollen, müssen wir mit 'Kostümen' in Form von Präfixen arbeiten.
  • Wir verlieren alle operationen 'pro Datenbank', wie SCAN, DBSIZE, CLEAR DB usw.
  • Multi-Operationen sind erheblich komplizierter in der Implementierung, da möglicherweise auf mehrere Knoten zugegriffen werden muss.
• Vorteile:
  • Ausfallsicherheit durch die Notfall-Umschaltung des Masters.
  • Sharding auf der Redis-Seite.
  • Daten atomar und ohne Ausfallzeiten zwischen Knoten verschieben.
  • Hinzufügen und Neuzuordnen von Ressourcen und Lasten ohne Ausfallzeiten.

Ich würde den Schluss ziehen, dass, wenn Sie keinen hohen Grad an Ausfallsicherheit benötigen, ein Umzug zu einem Cluster nicht lohnt, da dies eine nicht triviale Aufgabe sein kann. Wenn Sie jedoch ursprünglich zwischen einer Einzelversion und einer Clusterversion wählen müssen, sollten Sie das Cluster wählen, da es nicht schlechter ist und zusätzlich einen Teil der Kopfschmerzen von Ihnen nimmt.

Vorbereitung auf den Umzug

Beginnen wir mit den Anforderungen an den Umzug:

• Er muss nahtlos sein. Eine vollständige Serviceunterbrechung von 5 Minuten ist für uns inakzeptabel.
• Er muss so sicher und schrittweise wie möglich sein. Wir möchten irgendeine Kontrolle über die Situation haben. Alles auf einmal zu kaputt machen und dann auf den Rücksetzknopf zu bitten, das möchten wir nicht.
• Minimale Datenverluste beim Umzug. Wir verstehen, dass es sehr schwierig sein wird, atomar umzuziehen, daher tolerieren wir eine gewisse Desynchronisation zwischen den Daten im normalen und im Cluster-Redis.

Cluster-Wartung

Vor dem Umzug sollten wir uns überlegen, ob wir den Cluster unterstützen können:

• Grafiken. Wir verwenden Prometheus und Grafana für Grafiken zur Auslastung von Prozessoren, belegtem Speicher, Anzahl der Clients, Anzahl der GET-, SET-, AUTH-Operationen usw.
• Expertise. Stellen Sie sich vor, dass morgen ein riesiger Cluster in Ihrer Verantwortung liegt. Wenn dieser kaputt geht, kann ihn niemand außer Ihnen reparieren. Wenn er anfängt zu stocken, werden alle zu Ihnen rennen. Wenn Ressourcen hinzugefügt oder die Last umverteilt werden muss, kommen sie wieder zu Ihnen. Um mit 25 nicht grau zu werden, sollte man diese Fälle im Voraus berücksichtigen und überprüfen, wie sich die Technologie bei verschiedenen Aktionen verhält. Darüber werden wir im Abschnitt "Expertise" ausführlicher sprechen.
• Überwachungen und Benachrichtigungen. Wenn der Cluster ausfällt, möchten wir als Erster darüber informiert werden. Hier haben wir uns auf die Benachrichtigung beschränkt, dass alle Knoten die gleichen Informationen über den Zustand des Clusters zurückgeben (ja, das kann auch anders sein). Und die anderen Probleme sind schneller über die Benachrichtigungen der Redis-Clientdienste zu erkennen.

Umzug

Wie wir umziehen werden:

• Zunächst muss die Bibliothek zur Arbeit mit dem Cluster vorbereitet werden. Als Grundlage für die Go-Version haben wir go-redis genommen und etwas für unsere Bedürfnisse angepasst. Wir haben Multi-Methoden über Pipelines implementiert und die Regeln für die Wiederholung von Anfragen etwas überarbeitet. Mit der PHP-Version gab es mehr Probleme, aber letztendlich haben wir uns für php-redis entschieden. Kürzlich haben sie die Unterstützung für Cluster eingeführt, und unserer Meinung nach sieht das gut aus.
• Als Nächstes muss das Cluster selbst bereitgestellt werden. Dies geschieht im Grunde genommen mit zwei Befehlen auf Basis der Konfigurationsdatei. Die Konfiguration werden wir weiter unten im Detail besprechen.
• Für den schrittweisen Umstieg verwenden wir den Dry-Modus. Da wir zwei Versionen der Bibliothek mit identischer Schnittstelle haben (eine für die normale Version, eine andere für das Cluster), ist es kein Problem, eine Wrapper zu erstellen, die mit der separaten Version arbeitet und gleichzeitig alle Anfragen an das Cluster dupliziert, die Antworten vergleicht und Abweichungen in Logs schreibt (in unserem Fall in NewRelic). Auf diese Weise, selbst wenn die Cluster-Version bei der Einführung fehlschlägt, wird unsere Produktion nicht betroffen sein.
• Nachdem das Cluster im Dry-Modus bereitgestellt wurde, können wir entspannt auf das Diagramm der Abweichungen der Antworten schauen. Wenn der Fehleranteil langsam, aber sicher auf eine gewisse kleine Konstante hinarbeitet, ist alles in Ordnung. Warum gibt es dennoch Abweichungen? Weil die Aufzeichnung in der separaten Version etwas früher erfolgt als im Cluster, und aufgrund der Mikrolaten können die Daten voneinander abweichen. Wir müssen nur die Protokolle der Abweichungen überprüfen, und wenn alle erklärbar sind durch die Nicht-Atomarität der Aufzeichnung, können wir weitermachen.
• Jetzt können wir den Dry-Modus umschalten. Wir werden aus dem Cluster schreiben und lesen und in die separate Version duplizieren. Warum? In der nächsten Woche möchten wir die Arbeit des Clusters beobachten. Falls sich herausstellt, dass es bei hoher Last Probleme gibt oder wir etwas übersehen haben, haben wir immer die Möglichkeit, auf den alten Code und die aktuellen Daten zurückzugreifen, dank des Dry-Modus.
• Jetzt bleibt nur noch, den Dry-Modus abzuschalten und die separate Version abzubauen.

Expertise

Zuerst eine kurze Zusammenfassung der Struktur des Clusters.

Zuallererst ist Redis ein Key-Value-Speicher. Als Schlüssel werden beliebige Strings verwendet. Als Werte können Zahlen, Strings und komplexe Strukturen genutzt werden. Letztere gibt es in großer Zahl, aber für das Verständnis der allgemeinen Struktur ist das nicht entscheidend.
Die nächste Ebene der Abstraktion nach den Schlüsseln sind die Slots (SLOTS). Jeder Schlüssel gehört zu einem der 16.383 Slots. Innerhalb jedes Slots können beliebig viele Schlüssel vorhanden sein. Somit unterteilen sich alle Schlüssel in 16.383 nicht überlappende Mengen.

Im Cluster müssen N Master-Nodes vorhanden sein. Jede Node kann als separate Redis-Instanz betrachtet werden, die alles über die anderen Nodes im Cluster weiß. Jede Master-Node enthält eine bestimmte Anzahl von Slots. Jeder Slot gehört nur zu einer Master-Node. Alle Slots müssen auf die Nodes verteilt werden. Wenn einige Slots nicht verteilt sind, sind die darin gespeicherten Schlüssel nicht verfügbar. Jede Master-Node sollte sinnvollerweise auf einer separaten logischen oder physischen Maschine betrieben werden. Zudem ist zu beachten, dass jede Node nur auf einem Kern arbeitet. Wenn Sie mehrere Instanzen von Redis auf einer logischen Maschine betreiben möchten, stellen Sie sicher, dass sie auf verschiedenen Kernen arbeiten (wir haben das nicht ausprobiert, aber theoretisch sollte alles funktionieren). Im Grunde genommen sorgen die Master-Nodes für gewöhnliches Sharding, und eine größere Anzahl von Master-Nodes ermöglicht eine Skalierung der Lese- und Schreibanfragen.

Nachdem alle Schlüssel auf die Slots verteilt sind und die Slots auf die Master-Nodes verteilt sind, können zu jeder Master-Node beliebig viele Slave-Nodes hinzugefügt werden. Innerhalb dieser „Master-Slave“-Verbindung erfolgt eine gewöhnliche Replikation. Slaves sind notwendig, um die Leseanfragen zu skalieren und für das Failover im Falle eines Ausfalls des Masters.

Lassen Sie uns nun über die Operationen sprechen, die wir besser beherrschen sollten.

Wir werden auf das System über die Redis-CLI zugreifen. Da Redis keinen einzelnen Einstiegspunkt hat, können die folgenden Operationen auf jeder der Nodes durchgeführt werden. In jedem Punkt weise ich besonders auf die Möglichkeit hin, die Operation unter Last auszuführen.

• Das Erste und Wichtigste, was wir benötigen, ist die Operation cluster nodes. Sie gibt den Zustand des Clusters zurück, zeigt die Liste der Nodes, ihre Rollen, die Verteilung der Slots usw. Weitere Informationen können mit cluster info und cluster slots abgerufen werden.
• Es wäre gut, in der Lage zu sein, Knoten hinzuzufügen und zu entfernen. Dafür gibt es die Operationen cluster meet und cluster forget. Beachten Sie, dass cluster forget auf JEDEN Knoten angewendet werden muss, sowohl auf Master- als auch auf Replikatknoten. Umgekehrt reicht es, cluster meet nur auf einem Knoten zu starten. Diese Unterscheidung kann verwirrend sein, daher ist es besser, sich darüber zu informieren, bevor Sie den Cluster in Betrieb nehmen. Das Hinzufügen eines Knotens erfolgt sicher im laufenden Betrieb und hat keinen Einfluss auf die Funktion des Clusters (was logisch ist). Wenn Sie jedoch einen Knoten aus dem Cluster entfernen möchten, sollten Sie sicherstellen, dass auf ihm keine Slots mehr vorhanden sind (ansonsten riskieren Sie den Verlust des Zugriffs auf alle Schlüssel auf diesem Knoten). Entfernen Sie auch nicht den Master-Knoten, der Replikate hat, da sonst ein unnötiges Abstimmen auf einen neuen Master stattfinden würde. Falls auf den Knoten bereits keine Slots mehr vorhanden sind, ist das ein kleines Problem, aber warum sollten wir uns zusätzliche Entscheidungen aufbürden, wenn wir zuerst die Replikate entfernen können.
• Wenn Sie Master und Slave zwangsläufig umkehren müssen, ist der Befehl cluster failover geeignet. Wenn Sie diesen im laufenden Betrieb aufrufen, müssen Sie sich bewusst sein, dass der Master während der Ausführung der Operation nicht verfügbar sein wird. In der Regel erfolgt der Wechsel in weniger als einer Sekunde, jedoch nicht atomar. Sie können damit rechnen, dass einige Anfragen an den Master in dieser Zeit mit einem Fehler enden.
• Bevor Sie einen Knoten aus dem Cluster entfernen, sollten keine Slots mehr darauf verbleiben. Es ist besser, diese mit dem Befehl cluster reshard neu zu verteilen. Die Slots werden von einem Master auf einen anderen übertragen. Der gesamte Vorgang kann mehrere Minuten in Anspruch nehmen, abhängig von der Menge der übertragenen Daten; jedoch ist der Übertragungsprozess sicher und hat keine Auswirkungen auf die Funktionsweise des Clusters. Auf diese Weise können alle Daten unter Last von einem Knoten auf einen anderen übertragen werden, ohne dass sie dadurch unzugänglich werden. Es gibt jedoch einige Feinheiten zu beachten. Erstens ist der Datentransfer mit einer bestimmten Last auf dem empfangenden und sendenden Knoten verbunden. Wenn der empfangende Knoten bereits stark ausgelastet ist, sollte er nicht auch noch mit neuen Daten belastet werden. Zweitens, sobald auf dem sendenden Master kein Slot mehr vorhanden ist, werden alle zugehörigen Slaves sofort zu dem Master wechseln, auf den diese Slots übertragen wurden. Das Problem hierbei ist, dass all diese Slaves gleichzeitig versuchen werden, die Daten zu synchronisieren. Und es wäre Ihnen noch gegönnt, wenn es sich dabei um eine partielle und nicht um eine vollständige Synchronisation handelt. Berücksichtigen Sie dies und kombinieren Sie die Vorgänge zur Übertragung von Slots und das Trennen/Übertragen von Slaves. Oder hoffen Sie, dass Sie ausreichend Puffer haben.
• Was tun, wenn Sie beim Übertragen feststellen, dass Sie irgendwo Slots verloren haben? Ich hoffe, dieses Problem betrifft Sie nicht, aber falls doch, gibt es die Operation cluster fix. Diese verteilt die Slots mehr oder weniger zufällig auf die Knoten. Ich empfehle, die Funktionsweise vorher zu prüfen, indem Sie einen Knoten mit verteilten Slots aus dem Cluster entfernen. Da die Daten in nicht verteilten Slots sowieso nicht verfügbar sind, ist es zu spät, sich über Probleme mit deren Verfügbarkeit zu sorgen. Die Operation wird hingegen keine Auswirkungen auf die verteilten Slots haben.
• Eine weitere nützliche Operation ist monitor. Sie ermöglicht es Ihnen, in Echtzeit die gesamte Liste der Anfragen zu sehen, die an den Knoten gerichtet werden. Darüber hinaus können Sie damit einen grep durchführen und herausfinden, ob der benötigte Datenverkehr vorhanden ist.

Es ist auch wichtig, das Verfahren zur Notfallumschaltung des Masters zu erwähnen. Kurz gesagt, es existiert und funktioniert meiner Meinung nach hervorragend. Man sollte jedoch nicht denken, dass Redis sofort umschaltet und die Clients keinen Verlust bemerken, wenn das Kabel des Master-Nodes aus der Steckdose gezogen wird. In meiner Erfahrung dauert der Umschaltvorgang einige Sekunden. Während dieser Zeit sind Teile der Daten nicht verfügbar: Der Master wird als nicht erreichbar erkannt, die Nodes stimmen für einen neuen ab, die Slaves schalten um und die Daten werden synchronisiert. Der beste Weg, um selbst sicherzustellen, dass das Schema funktioniert, ist, lokale Übungen durchzuführen. Erstellen Sie einen Cluster auf Ihrem Laptop, gewähren Sie eine minimale Last, simulieren Sie einen Ausfall (zum Beispiel durch Blockieren der Ports) und bewerten Sie die Umschaltgeschwindigkeit. Meiner Ansicht nach kann man nur durch ein- oder zweitägiges Ausprobieren sicher sein, dass die Technologie funktioniert. Oder man hofft, dass die Software, die von der Hälfte des Internets genutzt wird, bestimmt funktioniert.

Konfiguration

Oft ist die Konfiguration das Erste, was man benötigt, um mit dem Tool zu beginnen. Und wenn alles funktioniert, möchte man die Konfiguration nicht mehr anfassen. Man braucht gewisse Anstrengungen, um sich zu motivieren, zu den Einstellungen zurückzukehren und sie gründlich zu durchforsten. Soweit ich mich erinnere, hatten wir mindestens zwei ernsthafte Fehler wegen Unachtsamkeit bei der Konfiguration. Achten Sie besonders auf die folgenden Punkte:

• timeout 0
  Die Zeit, nach der inaktive Verbindungen (in Sekunden) geschlossen werden. 0 — sie werden nicht geschlossen
  Nicht jede unserer Bibliotheken konnte Verbindungen korrekt schließen. Wenn diese Einstellung deaktiviert ist, laufen wir Gefahr, die Grenze für die Anzahl der Clients zu erreichen. Andererseits, wenn ein solches Problem besteht, dann wird der automatische Abbruch verlorener Verbindungen es maskieren, und wir könnten es nicht bemerken. Darüber hinaus sollte diese Einstellung nicht aktiviert werden, wenn persistente Verbindungen verwendet werden.
• Save x y & appendonly yes
  Speicherung eines RDB-Snapshots.
  Probleme mit RDB/AOF werden wir gleich ausführlich besprechen.
• stop-writes-on-bgsave-error no & slave-serve-stale-data yes
  Wenn aktiviert, wird der Master bei einem Fehler beim Erstellen des RDB-Snapshots aufhören, Änderungsanfragen anzunehmen. Wenn die Verbindung zum Master verloren geht, kann der Slave weiterhin auf Anfragen antworten (ja). Oder aufhören zu antworten (nein)
  Wir sind mit einer Situation, in der Redis zu einer Kürbis wird, nicht zufrieden.
• repl-ping-slave-period 5
  Nach diesem Zeitraum beginnen wir uns Sorgen zu machen, dass der Master ausgefallen ist und es Zeit für die Failover-Prozedur wäre.
  Wir müssen manuell das Gleichgewicht zwischen Fehlalarmen und der Aktivierung des Failovers finden. In unserer Praxis sind das 5 Sekunden.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  So viele Daten können wir im Puffer für einen ausgefallenen Replikat speichern. Wenn der Puffer erschöpft ist, müssen wir eine vollständige Synchronisation durchführen.
  Die Praxis zeigt, dass es besser ist, einen höheren Wert festzulegen. Es gibt viele Gründe, warum das Replikat ins Hintertreffen geraten kann. Wenn dies der Fall ist, hat Ihr Master wahrscheinlich schon Schwierigkeiten, und eine vollständige Synchronisation wird der letzte Tropfen sein.
• maxclients 10000
  Maximale Anzahl an gleichzeitigen Clients.
  Nach unserer Erfahrung ist es besser, einen höheren Wert festzulegen. Redis bewältigt problemlos 10.000 Verbindungen. Stellen Sie nur sicher, dass im System genügend Sockets vorhanden sind.
• maxmemory-policy volatile-ttl
  Regel, nach der Schlüssel beim Erreichen des verfügbaren Speicherkapazitätslimits gelöscht werden.
  Hier ist nicht das Regelwerk wichtig, sondern das Verständnis, wie dies geschehen wird. Redis kann für seine Fähigkeit gelobt werden, auch bei Erreichen des Speicherkapazitätslimits ordnungsgemäß zu arbeiten.

Probleme mit RDB und AOF

Obwohl Redis alle Informationen im Arbeitsspeicher speichert, gibt es auch einen Mechanismus zum Speichern von Daten auf der Festplatte. Genauer gesagt, drei Mechanismen:

• RDB-Snapshot — ein vollständiges Abbild aller Daten. Dies wird mit der Konfiguration SAVE X Y festgelegt und liest sich als "Vollständigen Snapshot aller Daten alle X Sekunden speichern, wenn sich mindestens Y Schlüssel geändert haben."
• Append-only file — eine Liste von Operationen in der Reihenfolge ihrer Ausführung. Fügt neue eingegangene Operationen alle X Sekunden oder alle Y Operationen in die Datei hinzu.
• RDB und AOF — eine Kombination der beiden vorherigen.

Alle Methoden haben ihre Vor- und Nachteile, ich werde sie nicht alle auflisten, sondern lediglich auf die, meiner Meinung nach, weniger offensichtlichen Punkte hinweisen.

Erstens erfordert das Speichern eines RDB-Snapshots das Aufrufen von FORK. Bei einer großen Datenmenge kann dies Redis für einen Zeitraum von mehreren Millisekunden bis zu einer Sekunde blockieren. Außerdem benötigt das System zusätzlichen Speicher für einen solchen Snapshot, was dazu führt, dass auf der logischen Maschine eine doppelte Menge an Arbeitsspeicher erforderlich sein sollte: Wenn Redis 8 GB zugewiesen ist, sollten auf der virtuellen Maschine 16 GB verfügbar sein.

Zweitens gibt es Probleme mit der partielle Synchronisation. Im AOF-Modus kann beim Wiederverbinden des Slaves anstelle einer partielle Synchronisation eine vollständige erfolgen. Warum das so ist, konnte ich nicht verstehen. Aber man sollte daran denken.

Diese beiden Punkte führen bereits dazu, darüber nachzudenken, ob wir diese Daten auf der Festplatte wirklich benötigen, wenn sie ohnehin von den Slaves dupliziert werden. Daten können nur verloren gehen, wenn alle Slaves ausfallen, und das ist ein Problem auf der Ebene "Brand im Rechenzentrum". Als Kompromiss könnte man vorschlagen, die Daten nur auf den Slaves zu speichern, aber in diesem Fall sollte man sicherstellen, dass diese Slaves niemals beim Notfall-Wiederherstellung zum Master werden (dafür gibt es eine Einstellung zur Priorität der Slaves in ihrer Konfiguration). In jedem einzelnen Fall überlegen wir für uns, ob es notwendig ist, die Daten auf der Festplatte zu speichern, und antworten meist mit „nein“.

Fazit

Abschließend hoffe ich, dass ich einen allgemeinen Überblick über die Funktionsweise von redis-cluster gegeben habe für diejenigen, die überhaupt noch nichts davon gehört haben, und auch auf einige nicht offensichtliche Punkte für diejenigen hingewiesen habe, die es schon lange benutzen.
Danke für Ihre Zeit und wie gewohnt sind Kommentare zum Thema willkommen.

Quelle: habr.com