Vorwort
Vor ein paar Tagen sah ich auf Zhihu eine Frage: Wie baut man sein eigenes Wissenssystem und seinen eigenen Standpunkt auf? [1]
In einer hochgelobten Antwort hieß es, dass die Etablierung eines „externen Gehirns“ der Schlüssel sei. Der Standpunkt des Artikels ist, dass das Gehirn zum Denken und nicht zum Gedächtnis genutzt wird.
Ich stimme dieser Ansicht voll und ganz zu. Mein Kontoname ist „Student Yang technotes“. Technotes [2] entstand aus dem Github-Projekt, das ich in den letzten Jahren zusammengefasst habe, was „technische Notizen“ bedeutet. Dies ist mein „externes Gehirn“. Ich werde weiterhin Dinge ergänzen und den Inhalt optimieren, ich bin herzlich eingeladen, darauf zu achten.
- [1] https://www.zhihu.com/question/52782284/answer/1857387360
- [2] https://www.dbses.cn/technotes
Dieser Artikel stammt aus meinem Technotes Redis-Artikel.
Text
Um eine Technologie zu erlernen, müssen wir einen Gesamtüberblick über die Technologie haben. Nachfolgend finden Sie einen Überblick über Redis, der meiner Meinung nach sehr umfassend ist.
Heute konzentrieren wir uns hauptsächlich auf die Hochverfügbarkeitshauptlinie von Redis. Konkret hat die hohe Verfügbarkeit von Redis zwei Bedeutungen: Zum einen bedeutet sie weniger Dienstunterbrechungen und zum anderen weniger Datenverlust.
Um eine geringere Dienstunterbrechung sicherzustellen, besteht die übliche Praxis darin, die Redundanz zu erhöhen und die Anzahl der Dienstkopien zu erhöhen. Wenn jedoch zu viele Kopien vorhanden sind, stellt die Sicherstellung der Datenkonsistenz der Kopien ein Problem dar.
1. Master-Slave-Bibliotheksmodus
In dieser Hinsicht bietet Redis einen Master-Slave-Bibliotheksmodus. Die Master-Slave-Bibliothek verwendet eine Lese-/Schreib-Trennmethode: Für Leseoperationsanforderungen kann die Master-Slave-Bibliothek diese empfangen; für Schreiboperationen gehen Sie zuerst zur Hauptbibliothek zur Ausführung, und dann synchronisiert die Master-Bibliothek Schreibvorgänge mit der Slave-Bibliothek.
Wie wird also die Synchronisierung der Master-Slave-Bibliothek abgeschlossen? Werden die Daten der Master-Datenbank auf einmal an die Slave-Datenbank übertragen oder werden sie stapelweise synchronisiert? Können die Daten konsistent bleiben, wenn das Netzwerk zwischen der Master- und der Slave-Datenbank getrennt wird?
1.1 Implementierungsdetails der Datensynchronisation
Wenn wir mehrere Redis-Instanzen starten, können sie über den Befehl „replicaof“ (slaveof wurde vor Redis 5.0 verwendet) eine Beziehung zwischen der Master-Bibliothek und der Slave-Bibliothek herstellen.
Zum Beispiel gibt es jetzt Instanz 1 (IP: 172.16.19.3) und Instanz 2 (IP: 172.16.19.5). Nachdem wir den folgenden Befehl auf Instanz 2 ausgeführt haben, wird Instanz 2 zur Slave-Bibliothek von Instanz 1 und von der Instanz Daten auf 1 kopieren:
replicaof 172.16.19.3 6379
Danach erfolgt die erste Datensynchronisierung in drei Schritten.
Die erste Phase: Der Prozess des Herstellens einer Verbindung und der Aushandlung der Synchronisierung zwischen der Master- und der Slave-Datenbank dient hauptsächlich der Vorbereitung der vollständigen Replikation. Insbesondere sendet die Slave-Bibliothek den Befehl psync an die Master-Bibliothek, um anzuzeigen, dass eine Datensynchronisierung erforderlich ist, und die Master-Bibliothek startet die Replikation gemäß den Parametern dieses Befehls. Der psync-Befehl enthält zwei Parameter: die runID der Master-Bibliothek und den Offset des Replikationsfortschritts. runID ist eine zufällige ID, die beim Start jeder Redis-Instanz automatisch generiert wird und zur eindeutigen Kennzeichnung dieser Instanz verwendet wird. Wenn die Slave-Bibliothek und die Master-Bibliothek zum ersten Mal kopiert werden, wird die RunID auf „?“ gesetzt, da die RunID der Masterbibliothek nicht bekannt ist. Der Offset, der zu diesem Zeitpunkt auf -1 eingestellt ist, bedeutet die erste Kopie.
Nachdem die Hauptbibliothek den psync-Befehl empfangen hat, verwendet sie den FULLRESYNC-Antwortbefehl, um zwei Parameter zu übermitteln: die RunID der Hauptbibliothek und den aktuellen Replikationsfortschrittsoffset der Hauptbibliothek (dieser Offset ist der aktuellste Wert) und gibt ihn an den zurück Sklavenbibliothek. Diese beiden Parameter werden protokolliert, wenn die Antwort von der Bibliothek empfangen wird.
Die zweite Stufe: Die Master-Bibliothek synchronisiert alle Daten mit der Slave-Bibliothek. Konkret führt die Master-Bibliothek den Befehl bgsave aus, um eine RDB-Datei zu generieren, und sendet die Datei dann an die Slave-Bibliothek. Nach dem Empfang der RDB-Datei von der Bibliothek wird zunächst die aktuelle Datenbank gelöscht und dann die RDB-Datei geladen.
Warum zuerst die aktuelle Datenbank löschen? Dies liegt daran, dass die Slave-Bibliothek möglicherweise andere Daten gespeichert hat, bevor sie mit der Synchronisierung mit der Master-Bibliothek über den Befehl „replicaof“ beginnt. Um die Auswirkungen früherer Daten zu vermeiden, muss die Slave-Bibliothek zuerst die aktuelle Datenbank löschen.
Während des Synchronisierungsprozesses der Daten von der Hauptbibliothek mit der Slave-Bibliothek wird die Hauptbibliothek nicht blockiert und kann weiterhin Anfragen normal empfangen. Andernfalls wird der Redis-Dienst unterbrochen. Allerdings werden die Schreibvorgänge in diesen Anfragen nicht in der gerade generierten RDB-Datei aufgezeichnet. Um die Datenkonsistenz der Master-Slave-Bibliothek sicherzustellen, verwendet die Master-Bibliothek einen speziellen Replikationspuffer im Speicher, um alle nach der Generierung der RDB-Datei empfangenen Schreibvorgänge aufzuzeichnen.
Die dritte Stufe: Wenn die Master-Bibliothek das Senden der RDB-Datei abgeschlossen hat, sendet sie die Änderungsvorgänge im Replikationspuffer an die Slave-Bibliothek und die Slave-Bibliothek führt diese Vorgänge erneut aus.
Das schematische Diagramm des gesamten Prozesses der Master-Slave-Replikation ist unten dargestellt.
Auf diese Weise wird die Master-Slave-Bibliothek synchronisiert. Es kann nicht ignoriert werden, dass es in diesem Prozess Risikopunkte gibt, und die häufigsten sind Netzwerkunterbrechungen oder -blockaden. Wenn die Netzwerkverbindung getrennt ist, können Befehle nicht zwischen der Master- und der Slave-Datenbank weitergegeben werden, und die Daten der Slave-Datenbank stimmen natürlich nicht mit der Master-Datenbank überein, und der Client liest möglicherweise alte Daten aus den Slave-Datenbanken.
1.2 Was soll ich tun, wenn das Netzwerk zwischen den Master- und Slave-Bibliotheken unterbrochen ist?
Wenn es vor Redis 2.8 zu einer Netzwerkunterbrechung der Master-Slave-Bibliothek während der Befehlsweitergabe kam, führte die Slave-Bibliothek erneut eine vollständige Kopie mit der Master-Bibliothek durch, und der Overhead war sehr hoch. Ab Redis 2.8 wird die Master-Slave-Bibliothek nach dem Trennen der Netzwerkverbindung weiterhin mithilfe der inkrementellen Replikation synchronisiert. Nur die Befehle, die die Master-Bibliothek während der Netzwerktrennung der Master-Slave-Bibliothek empfängt, werden mit der Slave-Bibliothek synchronisiert.
Wenn die Master-Slave-Bibliothek getrennt wird, schreibt die Master-Bibliothek die während des Trennungszeitraums empfangenen Schreiboperationsbefehle in den Replikationspuffer und schreibt diese Operationsbefehle auch in den Puffer repl_backlog_buffer. repl_backlog_buffer ist ein Ringpuffer. Die Hauptbibliothek zeichnet die Position auf, die sie geschrieben hat, und die Slave-Bibliothek zeichnet die Position auf, die sie gelesen hat.
Während der Phase der Netzwerktrennung empfängt die Hauptbibliothek möglicherweise neue Schreiboperationsbefehle, sodass im Allgemeinen der von der Hauptbibliothek geschriebene Speicherort größer ist als der von der Slave-Bibliothek gelesene Speicherort. Wenn das Netzwerk wiederhergestellt ist, muss die Master-Bibliothek nur die Befehlsoperationen zwischen dem von der Master-Bibliothek geschriebenen Speicherort und dem von der Slave-Bibliothek gelesenen Speicherort mit der Slave-Bibliothek synchronisieren.
Durch den Master-Slave-Bibliotheksmodus verbessert Redis nicht nur den Durchsatz der Systemverarbeitungsanforderungen, sondern stellt auch die Verfügbarkeit des Systems sicher.
Wenn die Slave-Bibliothek ausfällt, kann der Client weiterhin Anfragen für entsprechende Vorgänge an die Master-Bibliothek oder andere Slave-Bibliotheken senden. Was aber, wenn die Hauptbibliothek ausfällt? Zu diesem Zeitpunkt verfügt die Slave-Bibliothek nicht über eine entsprechende Master-Bibliothek zum Durchführen von Datenreplikationsvorgängen. Sobald eine Schreibvorgangsanforderung vorliegt, kann das System diese nicht verarbeiten.
2. Sentinel-Mechanismus
Wenn die Hauptbibliothek ausfällt, müssen wir daher eine neue Hauptbibliothek ausführen, beispielsweise eine Slave-Bibliothek zur Hauptbibliothek wechseln und sie als Hauptbibliothek behandeln. Im Redis-Master-Slave-Cluster ist der Sentinel-Mechanismus der Schlüsselmechanismus für die automatische Umschaltung der Master-Slave-Bibliothek.
2.1 Pflichten von Sentinels
Sentinel ist eigentlich ein Redis-Prozess, der in einem speziellen Modus ausgeführt wird. Er wird auch ausgeführt, während die Master-Slave-Bibliotheksinstanz ausgeführt wird. Sentry ist hauptsächlich für drei Aufgaben verantwortlich: Überwachung, Masterauswahl (Auswahl der Masterdatenbank) und Benachrichtigung.
Überwachung bedeutet, dass der Sentinel-Prozess während der Ausführung regelmäßig PING-Befehle an alle Master-Slave-Bibliotheken sendet, um zu überprüfen, ob diese noch online ausgeführt werden. Wenn die Slave-Bibliothek nicht innerhalb der angegebenen Zeit auf den PING-Befehl des Sentinels antwortet, markiert der Sentinel dies als „Offline-Status“. Wenn die Master-Bibliothek nicht innerhalb der angegebenen Zeit auf den PING-Befehl des Sentinels antwortet, wird dies ebenfalls der Sentinel tun Stellen Sie fest, dass die Hauptbibliothek offline geht, und starten Sie dann den Prozess des automatischen Wechsels der Hauptbibliothek.
Master-Auswahl bedeutet, dass Sentinel nach dem Aufhängen der Hauptbibliothek nach bestimmten Regeln eine Slave-Bibliotheksinstanz aus vielen Slave-Bibliotheken auswählen und diese als neue Hauptbibliothek verwenden muss. Nachdem dieser Schritt abgeschlossen ist, gibt es im aktuellen Cluster eine neue Hauptbibliothek.
Sentry führt dann eine letzte Aufgabe aus: die Benachrichtigung. Beim Ausführen der Benachrichtigungsaufgabe sendet der Sentinel die Verbindungsinformationen der neuen Hauptbibliothek an andere Slave-Bibliotheken, lässt diese den Befehl „replicaof“ ausführen, eine Verbindung mit der neuen Hauptbibliothek herstellen und die Datenreplikation durchführen. Gleichzeitig benachrichtigt Sentinel den Client über die Verbindungsinformationen der neuen Hauptbibliothek, damit er den Anforderungsvorgang an die neue Hauptbibliothek senden kann.
Aber haben Sie jemals daran gedacht, dass die Master-Slave-Bibliothek trotzdem normal umschalten kann, wenn eine Sentinel-Instanz während der Laufzeit ausfällt?
2.2 Hohe Verfügbarkeit von Sentry
Das Sentinel-Single-Point-of-Failure-Problem wird auch durch die Einrichtung eines Sentinel-Clusters gelöst. Schauen wir uns dann noch einmal die Verantwortlichkeiten des Sentinels an: Was sollten wir tun, wenn bei der Überwachung, ob die Master-Slave-Bibliothek offline ist, eine Meinungsverschiedenheit innerhalb des Sentinels besteht? Zum Beispiel gibt es drei Wachen, und einer der Wachen denkt, dass die Hauptbibliothek offline ist, während die anderen beiden denken, dass die Hauptbibliothek normal ist. Wer sollte zu diesem Zeitpunkt zuhören?
Dies ist wie eine Meinungsverschiedenheit innerhalb unseres Teams. Die beste Lösung besteht darin, demokratisch abzustimmen und das „Prinzip des Gehorsams der Minderheit gegenüber der Mehrheit“ zu übernehmen. Das Gleiche gilt für den Sentinel-Cluster. Wenn das Netzwerk überlastet ist, schlägt der PING-Befehl zwischen einigen Sentinels und der Hauptbibliothek fehl. Zu diesem Zeitpunkt denkt der Sentinel, dass die Hauptbibliothek fehlerhaft ist, aber das ist nicht der Fall. Zu diesem Zeitpunkt muss ein „demokratischer“ Ansatz gewählt werden. Die meisten Wachposten glauben, dass die Master-Datenbank fehlerhaft ist, und werden mit dem nächsten Schritt der Master-Wahl fortfahren.
Die Anzahl der Sentinel-Instanzen sollte eine ungerade Zahl von 2N+1 sein, damit es nicht zu Konflikten zwischen Ansichten kommt. Normalerweise konfigurieren wir mindestens 3 Sentinel-Instanzen.
Bei der Auswahl des Masters muss auch eine Frage berücksichtigt werden: Es gibt so viele Wächter. Welcher sollte den Master-Slave-Schalter durchführen?
Zu diesem Zeitpunkt kann der Wächter Befehle an andere Wächter senden, um anzuzeigen, dass er den Master-Slave-Wechsel selbst durchführen möchte, und alle anderen Wächter abstimmen lassen. Dieser Abstimmungsprozess wird „Leader Election“ genannt. Da der Wächter, der schließlich den Master-Slave-Wechsel durchführt, als Anführer bezeichnet wird, besteht der Abstimmungsprozess darin, den Anführer zu bestimmen.
Bisher haben wir die Reihe der von Redis übernommenen Lösungen grob geklärt, um weniger Dienstunterbrechungen zu gewährleisten. Wie sorgt Redis also für weniger Datenverlust?
Drei, AOF und RDB
Schüler, die MySQL kennen, haben möglicherweise gehört, dass MySQL dank des Write Ahead Log (WAL) Redo Log der Datenbank Crasf-Safe-fähig ist. Ebenso stellt Redis auch AOF-Protokolle bereit.
3.1 Die Hauptdatenbank ist ausgefallen. Wie kann ein Datenverlust vermieden werden?
AOF zeichnet jeden von Redis empfangenen Befehl auf und diese Befehle werden in Textform gespeichert. Nehmen wir als Beispiel das von Redis nach Erhalt des Befehls „set testkey testvalue“ aufgezeichnete Protokoll, um den Inhalt des AOF-Protokolls anzuzeigen. Darunter bedeutet „*3“, dass der aktuelle Befehl aus drei Teilen besteht. Jeder Teil beginnt mit „$+Nummer“, gefolgt von spezifischen Befehlen, Tasten oder Werten. Dabei gibt „Anzahl“ an, wie viele Bytes insgesamt für den Befehl, Schlüssel oder Wert in diesem Abschnitt vorhanden sind. „$3 set“ bedeutet beispielsweise, dass dieser Teil 3 Bytes enthält, was den „set“-Befehl darstellt.
Da jedoch die Betriebsbefehle anstelle der tatsächlichen Daten aufgezeichnet werden, ist es bei Verwendung der AOF-Methode zur Fehlerbehebung erforderlich, alle Betriebsprotokolle einzeln auszuführen. Wenn viele Betriebsprotokolle vorhanden sind, wird Redis sehr langsam wiederhergestellt, was sich auf die normale Nutzung auswirkt.
Daher bietet Redis eine weitere Datenpersistenzmethode: Speicher-Snapshot-RDB. Im Vergleich zu AOF zeichnet RDB Daten zu einem bestimmten Zeitpunkt auf, keine Vorgänge. Daher können wir bei der Datenwiederherstellung RDB-Dateien direkt in den Speicher einlesen, um die Wiederherstellung schnell abzuschließen.
Bei Snapshots hat die Häufigkeit, mit der das System Snapshots durchführt, direkten Einfluss auf das Ausmaß des Datenverlusts. Wie in der Abbildung unten gezeigt, haben wir zunächst einen Schnappschuss zum Zeitpunkt T0 und dann einen Schnappschuss zum Zeitpunkt T0+t erstellt, bei dem die Datenblöcke 5 und 9 geändert wurden. Wenn die Maschine während des Zeitraums t ausfällt, kann sie nur gemäß dem Snapshot zum Zeitpunkt T0 wiederhergestellt werden. Zu diesem Zeitpunkt können die geänderten Werte der Datenblöcke 5 und 9 nicht wiederhergestellt werden, da kein Snapshot-Datensatz vorhanden ist.
Um die Daten so weit wie möglich wiederherzustellen, sollte der t-Wert daher so klein wie möglich sein. Wie klein kann also der t-Wert sein, kann beispielsweise jede Sekunde ein Schnappschuss gemacht werden?
3.2 Wie kann ich Daten nach einer Ausfallzeit schnell wiederherstellen?
In Redis 4.0 wird eine Methode zum Mischen von AOF und RDB vorgeschlagen. Einfach ausgedrückt werden Speicher-Snapshots mit einer bestimmten Häufigkeit ausgeführt und zwischen zwei Snapshots werden AOF-Protokolle verwendet, um alle Befehlsvorgänge während dieses Zeitraums aufzuzeichnen.
Auf diese Weise werden Snapshots seltener durchgeführt. Darüber hinaus muss das AOF-Protokoll nur die Vorgänge zwischen zwei Snapshots aufzeichnen, d.
Diese Methode bietet nicht nur die Vorteile einer schnellen Wiederherstellung von RDB-Dateien, sondern auch die einfachen Vorteile, dass AOF nur Betriebsbefehle aufzeichnet.
Zusammenfassung
Lassen Sie mich den Inhalt dieses Artikels zusammenfassen. Die hohe Verfügbarkeit des Redis-Systems kann auf zwei Arten verstanden werden: zum einen durch weniger Dienstunterbrechungen und zum anderen durch weniger Datenverlust. Der Link zur Wissensverdauung, den ich zusammengestellt habe, lautet wie folgt.
服务少中断 -> 多副本 -> 主从库模式保证数据一致及从库的高可用 -> 哨兵保证主库的高可用 -> 哨兵集群保证哨兵高可用。
数据少丢失 -> AOF日志 -> AOF恢复数据较慢 -> RDB内存快照 -> 执行快照间隔不宜过短 -> AOF+RDB
Für weitere Implementierungsdetails des Sentinel-Mechanismus werde ich ihn später weiter aktualisieren, also bleiben Sie dran. Der öffentliche Account „Student Yang technotes“ begrüßt den technischen Austausch.