Wenn man sich ein Produkt ansieht, das seit mehr als einem Jahrzehnt weiterentwickelt wird, ist es keineswegs verwunderlich, darin veraltete Technologien zu finden. Was aber, wenn Sie die Belastung in sechs Monaten zehnmal höher halten müssen und sich die Kosten für Stürze um das Hundertfache erhöhen? In diesem Fall brauchen Sie einen coolen Highload Engineer. Da aber kein Dienstmädchen zur Verfügung stand, übertrugen sie mir die Lösung des Problems. Im ersten Teil des Artikels erzähle ich Ihnen, wie wir von Redis zum Redis-Cluster gewechselt sind, und im zweiten Teil gebe ich Ratschläge, wie Sie mit der Nutzung des Clusters beginnen und worauf Sie bei der Nutzung achten sollten.

Technologiewahl

Ist es so schlimm? separate Redis (eigenständiges Redis) in einer Konfiguration von 1 Master und N Slaves? Warum nenne ich es veraltete Technologie?

Nein, Redis ist nicht so schlecht ... Es gibt jedoch einige Mängel, die nicht ignoriert werden können.

• Erstens unterstützt Redis keine Disaster-Recovery-Mechanismen nach einem Master-Ausfall. Um dieses Problem zu lösen, haben wir eine Konfiguration mit automatischer Übertragung von VIPs an einen neuen Master verwendet, wobei die Rolle eines der Slaves geändert und der Rest gewechselt wurde. Dieser Mechanismus funktionierte, konnte aber nicht als zuverlässige Lösung bezeichnet werden. Erstens kam es zu Fehlalarmen, und zweitens war es ein Einwegartikel, und nach dem Betrieb waren manuelle Maßnahmen erforderlich, um die Feder zu laden.

• Zweitens führte die Tatsache, dass es nur einen Master gab, zu dem Problem des Shardings. Wir mussten mehrere unabhängige Cluster „1 Master und N Slaves“ erstellen, dann die Datenbanken manuell auf diese Maschinen verteilen und hoffen, dass morgen eine der Datenbanken nicht so stark anschwellen würde, dass sie in eine separate Instanz verschoben werden müsste.

Was sind die Möglichkeiten?

• Die teuerste und umfangreichste Lösung ist Redis-Enterprise. Dies ist eine Boxlösung mit vollem technischen Support. Obwohl es aus technischer Sicht ideal aussieht, hat es uns aus ideologischen Gründen nicht gepasst.
• Redis-Cluster. Standardmäßig gibt es Unterstützung für Master-Failover und Sharding. Die Benutzeroberfläche unterscheidet sich fast nicht von der regulären Version. Es sieht vielversprechend aus, über die Fallstricke sprechen wir später.
• Tarantool, Memcache, Aerospike und andere. Alle diese Tools machen so ziemlich das Gleiche. Aber jedes hat seine eigenen Mängel. Wir haben uns entschieden, nicht alle Eier in einen Korb zu legen. Wir verwenden Memcache und Tarantool für andere Aufgaben, und mit Blick auf die Zukunft kann ich sagen, dass es in unserer Praxis mehr Probleme damit gab.

Besonderheiten der Verwendung

Werfen wir einen Blick darauf, welche Probleme wir in der Vergangenheit mit Redis gelöst haben und welche Funktionalität wir verwendet haben:

• Cache vor Anfragen an Remote-Dienste wie 2GIS | Golang
  

  GET SET MGET MSET „SELECT DB“

• Cache vor MYSQL | PHP
  

  GET SET MGET MSET SCAN „KEY BY PATTERN“ „SELECT DB“

• Der Hauptspeicher für den Dienst zum Arbeiten mit Sitzungen und Fahrerkoordinaten | Golang
  

  GET SET MGET MSET „SELECT DB“ „ADD GEO KEY“ „GET GEO KEY“ SCAN

Wie Sie sehen, keine höhere Mathematik. Was ist dann die Schwierigkeit? Schauen wir uns jede Methode einzeln an.

Verfahren
Beschreibung
Funktionen des Redis-Clusters
Lösung

SETZEN
Schreib-/Leseschlüssel

MGET MSET
Mehrere Schlüssel schreiben/lesen
Die Schlüssel befinden sich auf verschiedenen Knoten. Vorgefertigte Bibliotheken können mehrere Operationen nur innerhalb eines Knotens ausführen
Ersetzen Sie MGET durch eine Pipeline von N GET-Vorgängen

DB AUSWÄHLEN
Wählen Sie die Basis aus, mit der wir arbeiten möchten
Unterstützt nicht mehrere Datenbanken
Legen Sie alles in einer Datenbank ab. Präfixe zu Schlüsseln hinzufügen

SCAN
Gehen Sie alle Schlüssel in der Datenbank durch
Da wir eine Datenbank haben, ist die Durchsicht aller Schlüssel im Cluster zu aufwendig
Behalten Sie eine Invariante innerhalb eines Schlüssels bei und führen Sie einen HSCAN für diesen Schlüssel durch. Oder ganz ablehnen

GEO
Operationen mit einem Geokey
Der Geokey ist nicht fragmentiert

SCHLÜSSEL NACH MUSTER
Suche nach einem Schlüssel nach Muster
Da wir über eine Datenbank verfügen, durchsuchen wir alle Schlüssel im Cluster. Zu teuer
Verweigern oder behalten Sie die Invariante bei, wie im Fall von SCAN

Redis vs. Redis-Cluster

Was verlieren wir und was gewinnen wir, wenn wir zu einem Cluster wechseln?

• Nachteile: Wir verlieren die Funktionalität mehrerer Datenbanken.
  • Wenn wir logisch unabhängige Daten in einem Cluster speichern möchten, müssen wir Krücken in Form von Präfixen erstellen.
  • Wir verlieren alle „Basis“-Operationen wie SCAN, DBSIZE, CLEAR DB usw.
  • Multioperationen sind viel schwieriger zu implementieren, da sie möglicherweise Zugriff auf mehrere Knoten erfordern.
• Vorteile:
  • Fehlertoleranz in Form von Master-Failover.
  • Sharding auf der Redis-Seite.
  • Übertragen Sie Daten atomar und ohne Ausfallzeiten zwischen Knoten.
  • Fügen Sie Kapazität und Lasten ohne Ausfallzeiten hinzu und verteilen Sie sie neu.

Ich komme zu dem Schluss, dass sich der Wechsel zu einem Cluster nicht lohnt, wenn Sie kein hohes Maß an Fehlertoleranz gewährleisten müssen, da dies eine nicht triviale Aufgabe sein kann. Wenn Sie sich jedoch zunächst zwischen einer separaten Version und einer Cluster-Version entscheiden, sollten Sie sich für einen Cluster entscheiden, da dieser nicht schlechter ist und Ihnen darüber hinaus einige Kopfschmerzen erspart

Wir bereiten uns auf den Umzug vor

Beginnen wir mit den Voraussetzungen für einen Umzug:

• Es sollte nahtlos sein. Ein kompletter Betriebsstopp für 5 Minuten passt für uns nicht.
• Es sollte so sicher und schrittweise wie möglich erfolgen. Ich möchte etwas Kontrolle über die Situation haben. Wir wollen nicht alles auf einmal wegwerfen und über den Rollback-Button beten.
• Minimaler Datenverlust beim Umzug. Wir verstehen, dass es sehr schwierig sein wird, sich atomar zu bewegen, daher erlauben wir eine gewisse Desynchronisierung zwischen Daten in regulären und geclusterten Redis.

Clusterwartung

Kurz vor dem Umzug sollten wir darüber nachdenken, ob wir den Cluster unterstützen können:

• Diagramme. Wir verwenden Prometheus und Grafana, um CPU-Auslastung, Speichernutzung, Anzahl der Clients, Anzahl der GET-, SET-, AUTH-Vorgänge usw. grafisch darzustellen.
• Sachverstand. Stellen Sie sich vor, dass Sie morgen einen riesigen Cluster unter Ihrer Verantwortung haben werden. Wenn es kaputt geht, kann niemand außer Ihnen es reparieren. Wenn er langsamer wird, rennen alle auf dich zu. Wenn Sie Ressourcen hinzufügen oder die Last neu verteilen müssen, melden Sie sich bei uns. Um mit 25 nicht ergraut zu werden, empfiehlt es sich, für diese Fälle vorzusorgen und vorab zu prüfen, wie sich die Technik bei bestimmten Aktionen verhält. Lassen Sie uns im Abschnitt „Expertise“ ausführlicher darüber sprechen.
• Überwachung und Warnungen. Wenn ein Cluster ausfällt, möchten Sie der Erste sein, der davon erfährt. Hier haben wir uns auf eine Benachrichtigung beschränkt, dass alle Knoten die gleichen Informationen über den Zustand des Clusters zurückgeben (ja, es kommt anders vor). Und andere Probleme können durch Warnungen der Redis-Clientdienste schneller erkannt werden.

Bewegen

So bewegen wir uns:

• Zunächst müssen Sie eine Bibliothek für die Arbeit mit dem Cluster vorbereiten. Wir haben go-redis als Basis für die Go-Version genommen und es ein wenig an unsere Bedürfnisse angepasst. Wir haben Multi-Methoden über Pipelines implementiert und auch die Regeln für sich wiederholende Anfragen leicht korrigiert. Die PHP-Version hatte mehr Probleme, aber wir haben uns schließlich für php-redis entschieden. Sie haben kürzlich die Cluster-Unterstützung eingeführt und sie sieht unserer Meinung nach gut aus.
• Als nächstes müssen Sie den Cluster selbst bereitstellen. Dies geschieht buchstäblich in zwei Befehlen basierend auf der Konfigurationsdatei. Auf die Einstellung gehen wir weiter unten genauer ein.
• Für die schrittweise Bewegung verwenden wir den Trockenmodus. Da wir zwei Versionen der Bibliothek mit derselben Schnittstelle haben (eine für die reguläre Version, die andere für den Cluster), kostet es nichts, einen Wrapper zu erstellen, der mit einer separaten Version arbeitet und parallel alle Anforderungen an den Cluster dupliziert. Antworten vergleichen und Unstimmigkeiten in die Protokolle schreiben (in unserem Fall in NewRelic). Selbst wenn die Cluster-Version während des Rollouts ausfällt, ist unsere Produktion daher nicht beeinträchtigt.
• Nachdem wir den Cluster im Trockenmodus ausgerollt haben, können wir uns in aller Ruhe das Diagramm der Antwortdiskrepanzen ansehen. Wenn sich die Fehlerrate langsam aber sicher einer kleinen Konstante nähert, ist alles in Ordnung. Warum gibt es immer noch Unstimmigkeiten? Da die Aufzeichnung in einer separaten Version etwas früher erfolgt als im Cluster und aufgrund von Mikroverzögerungen können die Daten abweichen. Jetzt müssen wir uns nur noch die Diskrepanzprotokolle ansehen, und wenn sie alle durch die Nichtatomarität des Datensatzes erklärt werden, können wir weitermachen.
• Jetzt können Sie den Trockenmodus in die entgegengesetzte Richtung umschalten. Wir werden aus dem Cluster schreiben und lesen und ihn in eine separate Version duplizieren. Wofür? In der nächsten Woche möchte ich die Arbeit des Clusters beobachten. Sollte sich plötzlich herausstellen, dass es bei Spitzenlast Probleme gibt oder wir etwas nicht berücksichtigt haben, haben wir dank Dry-Mode immer einen Notfall-Rollback auf den alten Code und die aktuellen Daten.
• Es bleibt nur noch, den Trockenmodus zu deaktivieren und die separate Version zu demontieren.

Prüfung

Zunächst kurz zum Cluster-Design.

Erstens ist Redis ein Schlüsselwertspeicher. Als Schlüssel werden beliebige Zeichenfolgen verwendet. Als Werte können Zahlen, Zeichenfolgen und ganze Strukturen verwendet werden. Letztere gibt es in großer Zahl, aber für das Verständnis der Gesamtstruktur ist das für uns nicht wichtig.
Die nächste Abstraktionsebene nach Schlüsseln sind Slots (SLOTS). Jeder Schlüssel gehört zu einem von 16 Steckplätzen. In jedem Steckplatz können sich beliebig viele Schlüssel befinden. Somit sind alle Schlüssel in 383 disjunkte Mengen unterteilt.

Als nächstes müssen N Masterknoten im Cluster vorhanden sein. Jeder Knoten kann als separate Redis-Instanz betrachtet werden, die alles über andere Knoten innerhalb des Clusters weiß. Jeder Masterknoten enthält eine Reihe von Slots. Jeder Slot gehört nur zu einem Masterknoten. Alle Slots müssen auf die Knoten verteilt werden. Wenn einige Steckplätze nicht zugewiesen sind, ist der Zugriff auf die darin gespeicherten Schlüssel nicht möglich. Es ist sinnvoll, jeden Masterknoten auf einer separaten logischen oder physischen Maschine auszuführen. Denken Sie auch daran, dass jeder Knoten nur auf einem Kern ausgeführt wird. Wenn Sie mehrere Redis-Instanzen auf derselben logischen Maschine ausführen möchten, stellen Sie sicher, dass diese auf verschiedenen Kernen ausgeführt werden (wir haben dies nicht versucht, aber theoretisch sollte es funktionieren). . Im Wesentlichen stellen Masterknoten regelmäßiges Sharding bereit, und mehr Masterknoten ermöglichen die Skalierung von Schreib- und Leseanforderungen.

Nachdem alle Schlüssel auf die Slots verteilt und die Slots auf die Master-Knoten verteilt sind, kann jedem Master-Knoten eine beliebige Anzahl von Slave-Knoten hinzugefügt werden. Innerhalb jeder dieser Master-Slave-Verbindungen funktioniert die normale Replikation. Slaves werden benötigt, um Leseanfragen zu skalieren und für den Failover im Falle eines Master-Ausfalls.

Lassen Sie uns nun über Operationen sprechen, die besser durchgeführt werden könnten.

Wir werden über Redis-CLI auf das System zugreifen. Da Redis keinen einzigen Einstiegspunkt hat, können Sie die folgenden Vorgänge auf jedem der Knoten ausführen. An jedem Punkt mache ich gesondert auf die Möglichkeit aufmerksam, den Betrieb unter Last durchzuführen.

• Das erste und wichtigste, was wir brauchen, ist der Betrieb der Clusterknoten. Es gibt den Status des Clusters zurück, zeigt eine Liste der Knoten, ihre Rollen, Slot-Verteilung usw. Weitere Informationen erhalten Sie über Cluster-Info und Cluster-Slots.
• Es wäre schön, Knoten hinzufügen und entfernen zu können. Zu diesem Zweck gibt es Cluster-Meet- und Cluster-Forget-Operationen. Bitte beachten Sie, dass Cluster Forget auf JEDEN Knoten angewendet werden muss, sowohl auf Master als auch auf Replikate. Und Cluster Meet muss nur auf einem Knoten aufgerufen werden. Dieser Unterschied kann beunruhigend sein. Informieren Sie sich daher am besten darüber, bevor Sie Ihren Cluster in Betrieb nehmen. Das Hinzufügen eines Knotens erfolgt sicher im Kampf und hat keinerlei Auswirkungen auf den Betrieb des Clusters (was logisch ist). Wenn Sie einen Knoten aus dem Cluster entfernen, sollten Sie sicherstellen, dass darauf keine Steckplätze mehr vorhanden sind (andernfalls riskieren Sie, den Zugriff auf alle Schlüssel auf diesem Knoten zu verlieren). Löschen Sie außerdem keinen Master, der über Slaves verfügt, da sonst eine unnötige Abstimmung für einen neuen Master durchgeführt wird. Wenn die Knoten keine Slots mehr haben, ist das ein kleines Problem, aber warum brauchen wir zusätzliche Auswahlmöglichkeiten, wenn wir zuerst die Slaves löschen können?
• Wenn Sie die Master- und Slave-Positionen zwangsweise vertauschen müssen, reicht der Cluster-Failover-Befehl aus. Wenn Sie es in die Schlacht rufen, müssen Sie verstehen, dass der Meister während der Operation nicht verfügbar sein wird. Normalerweise erfolgt der Wechsel in weniger als einer Sekunde, ist jedoch nicht atomar. Sie können damit rechnen, dass einige Anfragen an den Master in dieser Zeit fehlschlagen.
• Bevor Sie einen Knoten aus dem Cluster entfernen, sollten darauf keine Steckplätze mehr vorhanden sein. Es ist besser, sie mit dem Cluster-Reshard-Befehl neu zu verteilen. Slots werden von einem Master auf einen anderen übertragen. Der gesamte Vorgang kann mehrere Minuten dauern, abhängig von der übertragenen Datenmenge, aber der Übertragungsprozess ist sicher und beeinträchtigt den Betrieb des Clusters in keiner Weise. Somit können alle Daten direkt unter Last von einem Knoten zum anderen übertragen werden, ohne sich Sorgen um die Verfügbarkeit machen zu müssen. Allerdings gibt es auch Feinheiten. Erstens ist die Datenübertragung mit einer gewissen Belastung der Empfänger- und Senderknoten verbunden. Wenn der Empfängerknoten den Prozessor bereits stark belastet, sollten Sie ihn nicht mit dem Empfang neuer Daten belasten. Zweitens: Sobald auf dem sendenden Master kein einziger Slot mehr vorhanden ist, gehen alle seine Slaves sofort an den Master, an den diese Slots übertragen wurden. Und das Problem besteht darin, dass alle diese Slaves Daten gleichzeitig synchronisieren möchten. Und Sie haben Glück, wenn es sich um eine teilweise und nicht um eine vollständige Synchronisierung handelt. Berücksichtigen Sie dies und kombinieren Sie die Vorgänge Slot-Übertragung und Deaktivierung/Übertragung von Slaves. Oder hoffen Sie, dass Sie einen ausreichenden Sicherheitsspielraum haben.
• Was sollten Sie tun, wenn Sie bei der Übertragung feststellen, dass Sie Ihre Slots irgendwo verloren haben? Ich hoffe, dass Sie von diesem Problem nicht betroffen sind. Sollte dies jedoch der Fall sein, gibt es einen Cluster-Fix-Vorgang. Zumindest wird sie die Slots in zufälliger Reihenfolge über die Knoten verteilen. Ich empfehle, den Betrieb zu überprüfen, indem man zunächst den Knoten mit verteilten Slots aus dem Cluster entfernt. Da Daten in nicht zugewiesenen Slots bereits nicht verfügbar sind, ist es zu spät, sich über Probleme mit der Verfügbarkeit dieser Slots Gedanken zu machen. Der Vorgang hat wiederum keine Auswirkungen auf verteilte Slots.
• Eine weitere nützliche Operation ist die Überwachung. Es ermöglicht Ihnen, in Echtzeit die gesamte Liste der an den Knoten gerichteten Anforderungen anzuzeigen. Darüber hinaus können Sie es durchsuchen und herausfinden, ob der erforderliche Datenverkehr vorhanden ist.

Erwähnenswert ist auch das Master-Failover-Verfahren. Kurz gesagt, es existiert und meiner Meinung nach funktioniert es großartig. Denken Sie jedoch nicht, dass Redis sofort umschaltet, wenn Sie das Netzkabel einer Maschine mit einem Masterknoten abziehen, und dass die Clients den Verlust nicht bemerken. In meiner Praxis erfolgt die Umschaltung in wenigen Sekunden. Während dieser Zeit sind einige Daten nicht verfügbar: Die Nichtverfügbarkeit des Masters wird erkannt, Knoten stimmen für einen neuen, Slaves werden umgeschaltet, Daten werden synchronisiert. Der beste Weg, sich selbst davon zu überzeugen, dass das Programm funktioniert, ist die Durchführung lokaler Übungen. Erhöhen Sie den Cluster Ihres Laptops, geben Sie ihm eine Mindestlast, simulieren Sie einen Absturz (z. B. durch Blockieren der Ports) und bewerten Sie die Schaltgeschwindigkeit. Meiner Meinung nach kann man erst nach ein oder zwei Tagen auf diese Weise Vertrauen in die Funktionsweise der Technologie haben. Nun, oder hoffen, dass die Software, die die Hälfte des Internets verwendet, wahrscheinlich funktioniert.

Konfiguration

Oft ist die Konfiguration das Erste, was Sie brauchen, um mit dem Tool zu arbeiten. Und wenn alles funktioniert, möchten Sie die Konfiguration gar nicht erst anfassen. Es erfordert einige Anstrengung, sich dazu zu zwingen, zu den Einstellungen zurückzukehren und sie sorgfältig durchzugehen. Meiner Erinnerung nach hatten wir mindestens zwei schwerwiegende Fehler aufgrund von Unachtsamkeit bei der Konfiguration. Achten Sie besonders auf folgende Punkte:

• Zeitüberschreitung 0
  Zeit, nach der inaktive Verbindungen geschlossen werden (in Sekunden). 0 – nicht schließen
  Nicht jede unserer Bibliotheken konnte Verbindungen korrekt schließen. Durch das Deaktivieren dieser Einstellung besteht die Gefahr, dass die maximale Anzahl der Clients erreicht wird. Wenn andererseits ein solches Problem vorliegt, wird es durch die automatische Beendigung verlorener Verbindungen maskiert, und wir bemerken es möglicherweise nicht. Darüber hinaus sollten Sie diese Einstellung nicht aktivieren, wenn Sie dauerhafte Verbindungen verwenden.
• xy speichern & nur anhängen ja
  Speichern eines RDB-Snapshots.
  Wir werden RDB/AOF-Probleme im Folgenden ausführlich besprechen.
• stop-writes-on-bgsave-error nein & Slave-serve-stale-data ja
  Wenn diese Option aktiviert ist und der RDB-Snapshot unterbrochen wird, akzeptiert der Master keine Änderungsanforderungen mehr. Sollte die Verbindung zum Master verloren gehen, kann der Slave weiterhin auf Anfragen antworten (ja). Oder antwortet nicht mehr (nein)
  Wir sind nicht zufrieden mit der Situation, in der sich Redis in einen Kürbis verwandelt.
• repl-ping-slave-period 5
  Nach dieser Zeitspanne beginnen wir zu befürchten, dass der Master ausgefallen ist und es an der Zeit ist, den Failover-Vorgang durchzuführen.
  Sie müssen manuell ein Gleichgewicht zwischen Fehlalarmen und dem Auslösen eines Failovers finden. In unserer Praxis sind es 5 Sekunden.
• repl-backlog-size 1024 MB & epl-backlog-ttl 0
  Wir können genau so viele Daten für ein ausgefallenes Replikat in einem Puffer speichern. Wenn der Puffer erschöpft ist, müssen Sie eine vollständige Synchronisierung durchführen.
  Die Praxis zeigt, dass es besser ist, einen höheren Wert einzustellen. Es gibt viele Gründe, warum ein Replikat ins Stocken geraten könnte. Wenn es zu Verzögerungen kommt, hat Ihr Master höchstwahrscheinlich bereits Schwierigkeiten, damit klarzukommen, und die vollständige Synchronisierung wird der letzte Tropfen sein, der das Fass zum Überlaufen bringt.
• maxclients 10000
  Maximale Anzahl einmaliger Kunden.
  Unserer Erfahrung nach ist es besser, einen höheren Wert einzustellen. Redis verarbeitet 10 Verbindungen problemlos. Stellen Sie einfach sicher, dass im System genügend Steckdosen vorhanden sind.
• maxmemory-policy volatile-ttl
  Die Regel, nach der Schlüssel gelöscht werden, wenn das verfügbare Speicherlimit erreicht ist.
  Wichtig ist hier nicht die Regel selbst, sondern das Verständnis, wie dies geschehen wird. Redis kann für seine Fähigkeit gelobt werden, normal zu arbeiten, wenn das Speicherlimit erreicht ist.

RDB- und AOF-Probleme

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

• RDB-Snapshot – ein vollständiger Snapshot aller Daten. Wird mithilfe der SAVE XY-Konfiguration festgelegt und lautet: „Speichern Sie alle X Sekunden einen vollständigen Schnappschuss aller Daten, wenn sich mindestens Y-Tasten geändert haben.“
• Nur anfügbare Datei – eine Liste der Vorgänge in der Reihenfolge, in der sie ausgeführt werden. Fügt der Datei alle X Sekunden oder alle Y Vorgänge neue eingehende Vorgänge hinzu.
• RDB und AOF sind eine Kombination der beiden vorherigen.

Alle Methoden haben ihre Vor- und Nachteile, ich werde sie nicht alle aufzählen, sondern nur auf Punkte aufmerksam machen, die meiner Meinung nach nicht offensichtlich sind.

Zum Speichern eines RDB-Snapshots ist zunächst der Aufruf von FORK erforderlich. Wenn viele Daten vorhanden sind, kann dies dazu führen, dass Redis für einen Zeitraum von einigen Millisekunden bis zu einer Sekunde hängen bleibt. Darüber hinaus muss das System Speicher für einen solchen Snapshot zuweisen, was dazu führt, dass auf der logischen Maschine eine doppelte RAM-Versorgung vorgehalten werden muss: Wenn 8 GB für Redis zugewiesen werden, sollten 16 GB auf der virtuellen Maschine verfügbar sein Es.

Zweitens gibt es Probleme mit der teilweisen Synchronisierung. Im AOF-Modus kann beim erneuten Verbinden des Slaves anstelle einer teilweisen Synchronisierung eine vollständige Synchronisierung durchgeführt werden. Warum das passiert, konnte ich nicht verstehen. Aber es lohnt sich, sich daran zu erinnern.

Diese beiden Punkte lassen uns bereits darüber nachdenken, ob wir diese Daten wirklich auf der Festplatte benötigen, wenn alles bereits durch Slaves dupliziert ist. Daten können nur verloren gehen, wenn alle Slaves ausfallen. Dabei handelt es sich um ein „Fire in the DC“-Problem. Als Kompromiss können Sie vorschlagen, Daten nur auf Slaves zu speichern. In diesem Fall müssen Sie jedoch sicherstellen, dass diese Slaves während der Notfallwiederherstellung niemals zu Mastern werden (dafür gibt es in ihrer Konfiguration eine Slave-Prioritätseinstellung). Für uns selbst überlegen wir in jedem Einzelfall, ob es notwendig ist, Daten auf der Festplatte zu speichern, und meistens lautet die Antwort „Nein“.

Abschluss

Abschließend hoffe ich, dass ich denjenigen, die noch nie davon gehört haben, eine allgemeine Vorstellung davon geben konnte, wie Redis-Cluster funktioniert, und auch diejenigen, die es verwendet haben, auf einige nicht offensichtliche Punkte aufmerksam gemacht habe für eine lange Zeit.
Vielen Dank für Ihre Zeit. Kommentare zum Thema sind wie immer willkommen.

Source: habr.com