Redis Single-Data-Multi-Source-Lösung mit ultrahoher Parallelität

Redis ist derzeit die beliebteste KV-Cache-Datenbank. Sie ist einfach zu verwenden, sicher und stabil und bietet ein sehr breites Anwendungsspektrum in der Internetbranche.

In diesem Artikel werden hauptsächlich die Lösungen und Lösungen von Redis für den extrem hohen gleichzeitigen Zugriff auf einzelne Daten und mehrere Quellen vorgestellt.

Vorwort

Redis löst hauptsächlich zwei Probleme:

Wenn ein Geschäftsszenario mit zig Millionen täglichen Benutzern und Millionen von Menschen auftritt Gleichzeitig online: Wenn der Front-End-Zugriff direkt in die Back-End-Datenbank geladen wird, kann dies die zugrunde liegende Datenbank überlasten und zum Stillstand des Geschäfts führen. Oder wenn die Anzahl der Abfragebedingungen zunimmt und die Kombinationsbedingungen komplexer werden, kann die Antwortzeit der Abfrageergebnisse nicht garantiert werden, was zu einer Verschlechterung der Benutzererfahrung und zum Verlust von Benutzern führt. Um Geschäftsszenarien mit hoher Parallelität und geringer Latenz zu lösen, wurde Redis ins Leben gerufen.

Sehen wir uns unten zwei Szenarien an

Dies ist ein Geschäftsszenario für die Online-Wohnungssuche. Es gibt so viele Abfragebedingungen, dass das Backend komplex sein muss. SQL-Abfrage: Ist in diesem Szenario die Verwendung von Redis erforderlich?

Die Antwort lautet: Nein. Aufgrund der geringen Parallelität des Online-Haussuchgeschäfts stellen Kunden keine so hohen Anforderungen an die Reaktionszeit des Unternehmens. Die meisten Anfragen können vorübergehend direkt über dynamisches SQL abgefragt werden. Um die Benutzererfahrung zu verbessern, können natürlich einige heiße Abfrageergebnisse vorab in Redis zwischengespeichert werden, um die Benutzererfahrung zu verbessern.

Schauen wir uns dieses Szenario noch einmal an

Das Filmprüfsystem für Videobewerbungen hat fast das gleiche Geschäftsszenario wie das Wohnungssuchsystem, aber das Die Parallelität ist um mehrere Größenordnungen höher. Dieses Szenario eignet sich sehr gut für die Verwendung von Redis als Cache, um den gleichzeitigen Zugriff zu erhöhen, die Antwortzeit zu verkürzen und Hunderttausende oder sogar Millionen gleichzeitiger Zugriffsanforderungen zu erfüllen. Es ist ersichtlich, dass die grundlegenden Faktoren bei der Entscheidung, ob Redis verwendet wird, die Anforderungen an Parallelität und Latenz sind.

Sehen wir uns an, wie Redis die gleichzeitigen Zugriffsanforderungen in extremen Internetszenarien löst.

Caching-Lösung bei extrem hohem gleichzeitigem Zugriff

Dies ist ein typisches Diagramm der Medien-Cache-Architektur. Das Veröffentlichungssystem aktualisiert die Medienbibliothek von Zeit zu Zeit. durch Der verteilte Cache-Dienst synchronisiert jeden aktuellen Artikel mit dem Redis-Cache, und die Front-End-Anwendung findet den entsprechenden Datenquellenzugriff über die Routing-Schicht. Die Daten der einzelnen Cache-Dienste sind nicht synchron. Wenn ein Hotspot-Ereignis auftritt, leitet die Routing-Schicht möglicherweise den Zugriff aus nicht erreichbaren Bereichen an den Cache-Server weiter, auf dem sich die Hotspot-Daten befinden, was zu einem sofortigen Anstieg des Datenverkehrs führt. In extremen Fällen kann dies zu Serverausfällen und Geschäftsschäden führen. Wie lässt sich dieses Szenario mit unregelmäßigen Verkehrsausbrüchen lösen?

Hier ein paar Ideen:

Brechen Sie die Hotspot-Schlüssel mit Präfixen auf, um eine Hot-Data-Replikation zu erreichen

Fügen Sie lokalen Cache hinzu Routing-Schicht, Verbesserung der Caching-Funktionen durch mehrstufiges Caching

Die Cache-Schicht stellt Datenkopien bereit und verbessert die Möglichkeiten des gleichzeitigen Zugriffs

Die erste Lösung kann heiße Daten effektiv ableiten, aber heiße Ereignisse treten zufällig und unregelmäßig auf . Der Betriebs- und Wartungsdruck ist hoch und die Kosten sind hoch. Dies ist nur eine Lösung, um die Kopfschmerzen und das Problem zu lösen.

Die zweite Lösung kann die Caching-Funktionen durch Hinzufügen eines lokalen Caches verbessern. Allerdings sind die Frage, wie groß der lokale Cache eingestellt werden sollte, wie hoch die Aktualisierungsfrequenz ist und ob das Unternehmen schmutzige Lesevorgänge tolerieren kann, allesamt unvermeidbare Probleme.

Die dritte Lösung kann schreibgeschützte Replikate hinzufügen, um eine Datenreplikation zu erreichen, aber sie verursacht auch hohe Kosten und eine hohe Belastung der Hauptdatenbank.

Das obige Architekturdiagramm ist eine optimierte Lösung. Es zieht mehrere Zweige schreibgeschützter Slave-Bibliotheken durch die Hauptbibliothek und teilt unabhängige Caches für verschiedene Anforderungsquellen auf. Beispielsweise werden mobile Anwendungen fest an die APP-Datenressourcengruppe weitergeleitet, und der WEB-Zugriff wird an die WEB-Datenressourcengruppe usw. weitergeleitet. Jede Ressourcengruppe kann N schreibgeschützte Kopien bereitstellen, um die gleichzeitigen Zugriffsmöglichkeiten unter demselben Ursprung zu verbessern Zugang. Diese Architektur kann die Ressourcenisolationsfähigkeiten verschiedener Zugriffsquellen verbessern und die Stabilität und Verfügbarkeit von Diensten beim Zugriff aus mehreren Quellen verbessern.

Die Probleme dieser Lösung liegen ebenfalls auf der Hand:

Die Hauptbibliothek hat eine schlechte Lese- und Schreibleistung

Es gibt viele schreibgeschützte Replikate und die Kosten sind hoch

Der schreibgeschützte Link ist lang, schwierig zu verwalten und zu warten und verursacht hohe Betriebs- und Wartungskosten

Das übertriebenste Beispiel unserer Kunden ist die Verwendung eines 1-Master-40-Read-Links -Nur-Architektur zur Erfüllung ähnlicher Geschäftsszenarien.

Wie löst Alibaba Cloud Redis dieses Problem des extrem hohen gleichzeitigen Zugriffs?

Alibaba Cloud hat eine leistungsgesteigerte Version von Redis auf den Markt gebracht. Durch die Verbesserung der gleichzeitigen Verarbeitungsfunktionen von Netzwerk-E/A wurde die Lese- und Schreibleistung von Redis-Einzelknoten erheblich verbessert In der Community-Version wurde die Leistung dreimal verbessert. Durch die Beibehaltung des Single-Worker-Verarbeitungsmodus ist es zu 100 % mit dem Redis-Protokoll kompatibel. Die oben genannte Zugriffsfähigkeit von einer Million QPS für einzelne Daten kann problemlos erreicht werden. Das in diesem Artikel vorgestellte Medienszenario kann mehr als 2 Millionen QPS für einzelne Daten erreichen, indem die leistungsgesteigerten 5 schreibgeschützten Master-Instanzen der Version 1 aktiviert werden, wodurch der durch plötzliche Hot-Events, extrem hohe gleichzeitige Zugriffe und andere Branchen verursachte Verkehrsanstieg effektiv gemindert wird Schmerzpunkte. Im Vergleich zur selbst erstellten Community-Version mit 1 Master und 40 Lesevorgängen verfügt die leistungsverbesserte Version von Alibaba Cloud Redis mit denselben Leistungsstandards über eine 1-Master- und 5 schreibgeschützte Architektur, die stabiler, bequemer zu verwalten und mehr ist bequem zu verwenden.

Das obige ist der detaillierte Inhalt vonRedis Single-Data-Multi-Source-Lösung mit ultrahoher Parallelität. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!