Beherrschen Sie umfassend die Analyse und den Aufbau der Redis-Servicearchitektur

Speicherbasiertes Redis sollte in verschiedenen Webentwicklungsunternehmen die am häufigsten verwendete Schlüsselwertdatenbank sein. Wir verwenden es in unserem Unternehmen häufig, um den Benutzeranmeldestatus (Sitzungsspeicher) zu speichern und die Abfrage einiger wichtiger Daten zu beschleunigen Daten (im Vergleich zu MySQL wurde die Geschwindigkeit um Größenordnungen verbessert), wodurch einfache Nachrichtenwarteschlangen (LPUSH und BRPOP), Abonnement-Veröffentlichungssysteme (PUB/SUB) usw. erstellt werden. Größere Internetunternehmen verfügen im Allgemeinen über spezielle Teams, die Redis-Speicher als Basisdienst für verschiedene Geschäftsanrufe bereitstellen.

Allerdings wird jeder Anbieter von Basisdiensten vom Anrufer gefragt: Ist Ihr Dienst hochverfügbar? Es ist am besten, dass mein Unternehmen nicht unter häufigen Problemen mit Ihrem Service leidet. Kürzlich habe ich in meinem Projekt auch einen kleinen „hochverfügbaren“ Redis-Dienst erstellt. Hier ist meine Zusammenfassung und Reflexion.

Zunächst müssen wir definieren, was Hochverfügbarkeit für den Redis-Dienst ausmacht, das heißt, er kann in verschiedenen Ausnahmesituationen weiterhin Dienste normal bereitstellen. Oder seien Sie entspannter: Im Falle einer Auffälligkeit können die normalen Dienste bereits nach kurzer Zeit wiederhergestellt werden. Die sogenannte Ausnahme sollte mindestens die folgenden Möglichkeiten umfassen:

[Ausnahme 1] Ein Prozess eines bestimmten Knotenservers ist plötzlich ausgefallen (zum Beispiel wurde ein Entwickler deaktiviert und der Redis-Server-Prozess eines Servers wurde deaktiviert war ausgefallen.)

[Ausnahme 2] Ein bestimmter Knotenserver ist ausgefallen, was bedeutet, dass alle Prozesse auf diesem Knoten gestoppt wurden (z. B. wird ein Server aufgrund einer Betriebs- und Wartungsbehinderung vom Stromnetz getrennt; (z. B. ein alter Computer hat einen Hardwarefehler)

[Ausnahme 3] Die Kommunikation zwischen zwei beliebigen Knotenservern ist unterbrochen (z. B. hat ein Zeitarbeiter mit einer behinderten Hand das für die Kommunikation verwendete optische Kabel ausgegraben zwischen zwei Computerräumen)

Tatsächlich handelt es sich bei allen oben genannten Anomalien um Ereignisse mit geringer Wahrscheinlichkeit, und die grundlegende Leitidee zum Erreichen einer hohen Verfügbarkeit lautet: Die Wahrscheinlichkeit, dass mehrere Ereignisse mit geringer Wahrscheinlichkeit gleichzeitig auftreten, beträgt vernachlässigbar. Eine hohe Verfügbarkeit kann erreicht werden, solange wir das System so gestalten, dass es einen Single Point of Failure für einen kurzen Zeitraum toleriert.

Im Internet gibt es viele Lösungen für den Aufbau hochverfügbarer Redis-Dienste, wie zum Beispiel Keepalived, Codis, Twemproxy und Redis Sentinel. Unter ihnen werden Codis und Twemproxy hauptsächlich in großen Redis-Clustern verwendet. Sie waren auch Open-Source-Lösungen, die von Twitter und Wandoujia bereitgestellt wurden, bevor Redis Redis Sentinel offiziell veröffentlichte. Die Datenmenge in meinem Unternehmen ist nicht groß, daher ist die Bereitstellung von Clusterdiensten eine Maschinenverschwendung. Schließlich habe ich mich zwischen Keepalived und Redis Sentinel entschieden und mich für die offizielle Lösung Redis Sentinel entschieden.

Redis Sentinel kann als ein Prozess verstanden werden, der überwacht, ob der Redis-Server-Dienst normal ist. Sobald eine Anomalie erkannt wird, kann der Backup-(Slave-)Redis-Server automatisch aktiviert werden, sodass externe Benutzer auftretende Anomalien erkennen können innerhalb des Redis-Dienstes. Wir folgen den Schritten von einfach bis komplex, um einen minimalen und hochverfügbaren Redis-Dienst aufzubauen.

Option 1: Standalone-Version von Redis Server, ohne Sentinel

Unter normalen Umständen richten wir beim Erstellen einer persönlichen Website oder bei der täglichen Entwicklung eine einzelne Instanz von Redis Server ein. Der Anrufer kann sich direkt mit dem Redis-Dienst verbinden, und sogar der Client und Redis selbst befinden sich auf demselben Server. Diese Kombination eignet sich nur zum persönlichen Lernen und zur Unterhaltung. Schließlich wird es in dieser Konfiguration immer einen einzigen Fehlerpunkt geben, der nicht behoben werden kann. Sobald der Redis-Dienstprozess hängt oder Server 1 heruntergefahren wird, ist der Dienst nicht verfügbar. Und wenn die Redis-Datenpersistenz nicht konfiguriert ist, gehen auch die bereits in Redis gespeicherten Daten verloren.

Option 2: Master-Slave-Synchronisierung Redis Server, Einzelinstanz Sentinel

Um eine hohe Verfügbarkeit zu erreichen und das in Lösung 1 beschriebene Single-Point-of-Failure-Problem zu lösen, müssen wir einen Backup-Dienst hinzufügen, d. h. auf jedem der beiden Server einen Redis-Server-Prozess starten. Unter normalen Umständen stellt der Master bereit der Dienst, und der Slave ist nur für die Synchronisierung und Sicherung verantwortlich. Gleichzeitig wird ein zusätzlicher Sentinel-Prozess gestartet, um die Verfügbarkeit von zwei Redis-Server-Instanzen zu überwachen, sodass der Slave rechtzeitig in die Rolle des Masters befördert werden kann, um weiterhin Dienste bereitstellen zu können Verfügbarkeit des Redis-Servers. Dies basiert auf einem hochverfügbaren Service-Design, das heißt, ein einzelner Fehlerpunkt selbst ist ein Ereignis mit geringer Wahrscheinlichkeit und mehrere einzelne Fehlerpunkte gleichzeitig (dh der Master und der Slave hängen gleichzeitig auf). Zeit) kann als (grundsätzlich) unmögliches Ereignis angesehen werden.

Für den Aufrufer des Redis-Dienstes muss jetzt der Redis Sentinel-Dienst verbunden werden, nicht der Redis-Server. Der übliche Aufrufvorgang besteht darin, dass der Client zunächst eine Verbindung zu Redis Sentinel herstellt und fragt, welcher Dienst auf dem aktuellen Redis-Server der Master und welcher der Slave ist, und sich dann für den Betrieb mit dem entsprechenden Redis-Server verbindet. Natürlich haben aktuelle Bibliotheken von Drittanbietern diesen Aufrufprozess im Allgemeinen implementiert, und wir müssen ihn nicht mehr manuell implementieren (z. B. ioredis von Nodejs, predis von PHP, go-redis/redis von Golang, jedis von JAVA usw.).

Nachdem wir jedoch die Master-Slave-Umschaltung des Redis-Serverdienstes implementiert hatten, trat ein neues Problem auf, nämlich dass Redis Sentinel selbst ebenfalls ein Einzelpunktdienst ist. Sobald der Sentinel-Prozess hängt, hat der Client dies getan Nichts zu tun. Mit Sentinel verbunden. Daher kann mit der Konfiguration von Option 2 keine hohe Verfügbarkeit erreicht werden.

Option 3: Master-Slave-Synchronisierung von Redis Server, Dual-Instanz-Sentinel

Um das Problem von Lösung 2 zu lösen, starten wir außerdem einen zusätzlichen Redis Sentinel-Prozess. Die beiden Sentinel-Prozesse stellen gleichzeitig Service-Discovery-Funktionen für den Client bereit. Der Client kann sich mit jedem Redis Sentinel-Dienst verbinden, um grundlegende Informationen über die aktuelle Redis Server-Instanz zu erhalten. Normalerweise konfigurieren wir mehrere Redis Sentinel-Link-Adressen auf der Client-Seite. Sobald der Client feststellt, dass eine Verbindung zu anderen Sentinel-Instanzen hergestellt werden kann, ist eine manuelle Implementierung nicht erforderlich Verschiedene Entwicklungssprachen Die populäreren Redis-Verbindungsbibliotheken haben uns dabei geholfen, diese Funktion zu realisieren. Wir gehen davon aus, dass es, selbst wenn einer der Redis-Sentinels auflegt, einen anderen Sentinel gibt, der Dienste bereitstellen kann.

Die Vision ist zwar schön, aber die Realität ist sehr grausam. Unter einer solchen Architektur ist es immer noch unmöglich, eine hohe Verfügbarkeit des Redis-Dienstes zu erreichen. Im schematischen Diagramm von Option 3 ist die rote Linie die Kommunikation zwischen den beiden Servern, und das abnormale Szenario, das wir uns vorgestellt haben ([Anomalie 2]), besteht darin, dass ein bestimmter Server insgesamt ausgefallen ist Derzeit sind nur Redis Sentinel- und Slave-Redis-Server-Prozesse auf Server 2 verfügbar. Zu diesem Zeitpunkt schaltet Sentinel den verbleibenden Slave nicht tatsächlich auf den Master um, um den Dienst fortzusetzen, was dazu führt, dass der Redis-Dienst nicht verfügbar ist, da Redis so eingestellt ist, dass nur dann eine Verbindung hergestellt werden kann, wenn mehr als 50 % der Sentinel-Prozesse eine Verbindung herstellen können Wenn Sie für den neuen Master stimmen, findet tatsächlich eine Master-Slave-Umschaltung statt. In diesem Beispiel kann nur einer der beiden Sentinels verbunden werden, was 50 % entspricht und kein Szenario darstellt, in dem eine Master-Slave-Umschaltung möglich ist.

Sie fragen sich vielleicht, warum Redis diese 50 %-Einstellung hat? Unter der Annahme, dass wir weniger als oder gleich 50 % der Sentinel-Konnektivität zulassen, kann auch eine Master-Slave-Umschaltung durchgeführt werden. Stellen Sie sich [Ausnahme 3] vor, das heißt, das Netzwerk zwischen Server 1 und Server 2 ist unterbrochen, der Server selbst ist jedoch betriebsbereit. Wie in der folgenden Abbildung dargestellt:

Tatsächlich hat ein direkter Ausfall von Server 1 für Server 2 den gleichen Effekt, als ob Server 1 keine Verbindung herstellen könnte Das Netzwerk ist jedoch plötzlich nicht mehr verfügbar. Angenommen, wir erlauben Sentinel von Server 2, bei einer Netzwerkunterbrechung vom Slave zum Master zu wechseln. Das Ergebnis ist, dass Sie jetzt über zwei Redis-Server verfügen, die externe Dienste bereitstellen können. Alle vom Client durchgeführten Hinzufügungs-, Lösch- und Änderungsvorgänge können auf Redis von Server 1 oder Redis von Server 2 (je nachdem, mit welchem ​​Sentinel der Client verbunden ist) erfolgen und zu Datenverwirrung führen. Selbst wenn das Netzwerk zwischen Server 1 und Server 2 später wiederhergestellt wird, können wir die Daten nicht vereinheitlichen (zwei verschiedene Daten, wem sollten wir vertrauen?) Und die Datenkonsistenz wird vollständig zerstört.

Option 4: Master-Slave-Synchronisierung von Redis Server, drei Instanzen von Sentinel

Da mit Option 3 keine hohe Verfügbarkeit erreicht werden kann, ist unsere endgültige Version Option 4, wie im Bild oben gezeigt. Tatsächlich ist dies die Architektur, die wir letztendlich gebaut haben. Wir haben Server 3 eingeführt und einen Redis Sentinel-Prozess auf 3 aufgebaut. Jetzt verwalten drei Sentinel-Prozesse zwei Redis Server-Instanzen. In diesem Szenario können Redis-Dienste weiterhin für die Außenwelt bereitgestellt werden, unabhängig davon, ob es sich um einen einzelnen Prozessfehler, einen einzelnen Maschinenfehler oder einen Netzwerkkommunikationsfehler zwischen zwei Maschinen handelt.

Wenn Ihr Computer relativ inaktiv ist, können Sie natürlich auch einen Redis-Server auf Server 3 öffnen, um eine 1-Master- + 2-Slave-Architektur zu bilden. Für jede Datengruppe gibt es zwei Sicherungen, wodurch die Verfügbarkeit verbessert wird . Manche. Natürlich gilt: Je mehr Slaves, desto besser. Denn auch die Master-Slave-Synchronisation erfordert Zeit.

Sobald in Szenario 4 die Kommunikation zwischen Server 1 und anderen Servern vollständig unterbrochen ist, wechseln die Server 2 und 3 vom Slave zum Master. Für den Client gibt es derzeit zwei Master, die Dienste bereitstellen, und sobald das Netzwerk wiederhergestellt ist, gehen alle neuen Daten verloren, die während des Ausfalls auf Server 1 gelangt sind. Wenn Sie dieses Problem teilweise lösen möchten, können Sie den Redis-Serverprozess so konfigurieren, dass er den Dienst sofort stoppt, wenn er ein Problem mit seinem eigenen Netzwerk erkennt, um zu verhindern, dass während des Netzwerkausfalls neue Daten eingehen (siehe Redis-Min- (slaves-to-write und min-slaves-max-lag zwei Konfigurationselemente).

Zu diesem Zeitpunkt haben wir einen hochverfügbaren Redis-Dienst mit 3 Maschinen aufgebaut. Tatsächlich gibt es im Internet eine maschinenschonendere Möglichkeit, einen Sentinel-Prozess auf dem Client-Rechner statt auf dem Rechner des Dienstanbieters zu platzieren. Es ist nur so, dass im Unternehmen Anbieter und Anrufer allgemeiner Dienstleistungen nicht aus demselben Team stammen. Wenn zwei Teams dieselbe Maschine gemeinsam bedienen, kann es aufgrund von Kommunikationsproblemen leicht zu Fehlbedienungen kommen. Aus Gründen menschlicher Faktoren haben wir daher dennoch die Architektur von Option 4 übernommen. Und da auf Server 3 nur ein Sentinel-Prozess ausgeführt wird, verbraucht dieser nicht viele Serverressourcen. Server 3 kann auch zum Ausführen einiger anderer Dienste verwendet werden.

Benutzerfreundlichkeit: Verwenden Sie Redis Sentinel genau wie die eigenständige Version von Redis

Als Service Anbieter, wir Es gibt immer das Problem der Benutzererfahrung. Unter den oben genannten Lösungen gibt es immer etwas, das die Nutzung für den Kunden nicht so komfortabel macht. Bei der eigenständigen Version von Redis stellt der Client eine direkte Verbindung zum Redis-Server her. Wir müssen lediglich eine IP und einen Port angeben, und der Client kann unseren Dienst nutzen. Nach der Umwandlung in den Sentinel-Modus muss der Client einige externe Abhängigkeitspakete verwenden, die den Sentinel-Modus unterstützen, und außerdem seine eigene Redis-Verbindungskonfiguration ändern, was für „anspruchsvolle“ Benutzer offensichtlich inakzeptabel ist. Gibt es eine Möglichkeit, Dienste bereitzustellen, indem dem Client nur eine feste IP und ein fester Port zugewiesen werden, wie bei der eigenständigen Version von Redis?

Die Antwort ist natürlich ja. Dies erfordert möglicherweise die Einführung einer virtuellen IP (Virtual IP, VIP), wie in der Abbildung oben gezeigt. Wir können die virtuelle IP auf den Server verweisen, auf dem sich der Redis-Master-Slave befindet. Wenn ein Redis-Master-Slave-Wechsel stattfindet, wird ein Rückrufskript ausgelöst, das die VIP auf den Server umschaltet, auf dem sich der Slave befindet. Auf diese Weise scheint es für den Kunden so zu sein, dass er immer noch eine eigenständige Version des hochverfügbaren Redis-Dienstes verwendet.

Fazit

Es ist eigentlich sehr einfach, jeden Dienst zu erstellen und „nutzbar“ zu machen, genau wie wir eine eigenständige Version betreiben Redis. Doch wenn man „hohe Verfügbarkeit“ erreichen will, wird es kompliziert. Im Unternehmen werden zwei zusätzliche Server eingesetzt, 3 Sentinel-Prozesse + 1 Slave-Prozess, um sicherzustellen, dass der Dienst im unwahrscheinlichen Fall eines Unfalls weiterhin verfügbar ist. Im tatsächlichen Geschäftsbetrieb aktivieren wir außerdem die Prozessüberwachung durch den Supervisor. Sobald der Prozess unerwartet beendet wird, versucht er automatisch, neu zu starten.

Verwandte Empfehlungen:

Linux-Installations-Redis-Dienst und PHP-Redis-Erweiterung

Das obige ist der detaillierte Inhalt vonBeherrschen Sie umfassend die Analyse und den Aufbau der Redis-Servicearchitektur. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!