Mehr als 6.000 Wörter |. Punkte, die beim Entwerfen des Flash Kill-Systems zu beachten sind

Fünf Architekturprinzipien

Die Daten sollten so klein wie möglich sein

Zunächst bedeutet dies, dass die vom Benutzer angeforderten Daten so klein wie möglich sein können. Zu den angeforderten Daten gehören in das System hochgeladene Daten und vom System an den Benutzer zurückgegebene Daten (normalerweise eine Webseite).

Die Anzahl der Anfragen sollte so gering wie möglich sein

Nachdem die vom Benutzer angeforderte Seite zurückgegeben wurde, schließt der Browser beim Rendern der Seite weitere zusätzliche Anfragen ein, beispielsweise CSS/JavaScript, Bilder und Ajax Anfragen, von denen diese Seite abhängt, werden als „zusätzliche Anfragen“ definiert und sollten auf ein Minimum beschränkt werden.

Der Pfad sollte so kurz wie möglich sein

Dies ist die Anzahl der Zwischenknoten, die der Benutzer im Prozess von der Anfrage bis zur Rückgabe der Daten durchlaufen muss.

Abhängigkeiten sollten so gering wie möglich sein.

bezieht sich auf das System oder den Dienst, auf den man sich verlassen muss, um eine Benutzeranfrage abzuschließen. Abhängigkeiten beziehen sich hier auf starke Abhängigkeiten.

Hohe Verfügbarkeit

Ein einzelner Punkt im System kann als Tabu in der Systemarchitektur bezeichnet werden, da ein einzelner Punkt keine Sicherung und unkontrollierbare Risiken bedeutet. Das wichtigste Prinzip beim Entwurf verteilter Systeme besteht darin, „einzelne Punkte zu eliminieren“. , ein anderer Name ist „Hochverfügbarkeit“.

Architektur ist eine Kunst des Gleichgewichts, und sobald die beste Architektur von der Szene, an die sie sich anpasst, getrennt wird, wird alles leeres Gerede sein. Wir müssen bedenken, dass die hier genannten Punkte nur Richtungen sind. Wir sollten unser Bestes geben, um in diese Richtungen zu arbeiten, aber wir müssen auch andere Faktoren berücksichtigen.

Wie erfolgt eine dynamische und statische Trennung?

Was sind dynamische und statische Daten?

Was genau ist also eine dynamische und statische Trennung? Die sogenannte „dynamische und statische Trennung“ bedeutet eigentlich, die vom Benutzer angeforderten Daten (z. B. eine HTML-Seite) in „dynamische Daten“ und „statische Daten“ zu unterteilen. Einfach ausgedrückt besteht der Hauptunterschied zwischen „dynamischen Daten“ und „statischen Daten“ darin, festzustellen, ob die auf der Seite ausgegebenen Daten mit der URL, dem Browser, der Zeit und der Region zusammenhängen und ob sie private Daten wie Cookies enthalten.

1. Bei vielen Medien-Websites ist der Inhalt eines bestimmten Artikels derselbe, unabhängig davon, ob Sie ihn besuchen oder ob ich ihn besuche. Es handelt sich also um typische statische Daten, aber es handelt sich um eine dynamische Seite.
2. Wenn wir jetzt die Homepage von Taobao besuchen, sieht jeder möglicherweise eine andere Seite. Die Homepage von Taobao enthält viele empfohlene Informationen basierend auf Besuchereigenschaften, und diese personalisierten Daten können als dynamische Daten verstanden werden.

Wie speichert man statische Daten zwischen?

Zuerst sollten Sie statische Daten in der Nähe des Benutzers zwischenspeichern. Statische Daten sind Daten, die relativ unverändert sind, sodass wir sie zwischenspeichern können. Wo wird es zwischengespeichert? Es gibt drei gängige: im Browser des Benutzers, im CDN oder im Cache des Servers. Sie sollten sie je nach Situation so nah wie möglich am Benutzer zwischenspeichern.

Zweitens besteht die statische Transformation darin, HTTP-Verbindungen direkt zwischenzuspeichern. Im Vergleich zum normalen Daten-Caching müssen Sie von der statischen Transformation des Systems gehört haben. Die statische Transformation speichert die HTTP-Verbindung direkt zwischen, anstatt nur die Daten zwischenzuspeichern. Wie in der folgenden Abbildung gezeigt, entnimmt der Web-Proxy-Server direkt den entsprechenden HTTP-Antwortheader und Antworttext entsprechend der Anforderungs-URL und gibt ihn direkt zurück ist so einfach, dass es nicht einmal das HTTP-Protokoll verwendet. Neu zusammengesetzt müssen nicht einmal die HTTP-Anforderungsheader analysiert werden.

Drittens ist auch wichtig, wer statische Daten zwischenspeichert. In verschiedenen Sprachen geschriebene Cache-Software weist unterschiedliche Effizienzen bei der Verarbeitung zwischengespeicherter Daten auf. Nehmen Sie Java als Beispiel, da das Java-System selbst auch seine Schwächen hat (z. B. kann es eine große Anzahl von Verbindungsanforderungen nicht gut verarbeiten, jede Verbindung verbraucht mehr Speicher und der Servlet-Container analysiert das HTTP-Protokoll nur langsam). , sodass Sie das Caching nicht auf der Java-Ebene durchführen können, sondern direkt auf der Webserver-Ebene, sodass Sie einige Schwachstellen auf der Java-Sprachebene im Vergleich zu Webservern (wie Nginx, Apache, Varnish) abschirmen können ist auch besser in der Lage, große gleichzeitige statische Dateianforderungen zu verarbeiten.

Wie man die Transformation von dynamischer und statischer Trennung durchführt

1. URL eindeutig
2. Separate browserbezogene Faktoren
3. Separate Zeitfaktoren
4. Asynchrone regionale Faktoren
5. C-Cookie entfernen

Mehrere Architekturlösungen für dynamische und statische Trennung

Je nach Komplexität der Architektur stehen 3 Optionen zur Auswahl:

Einzelmaschinenbereitstellung:

Unified Cache Layer:

plus CDN-Schicht:

Die CDN-Bereitstellungslösung verfügt außerdem über die folgenden Funktionen:

1. Speichern Sie die gesamte Seite im Browser des Benutzers.
2. Wenn die Aktualisierung der gesamten Seite erzwungen wird, wird auch das CDN angefordert.
3. Die eigentliche effektive Anforderung ist nur der Klick des Benutzers auf „Schatz aktualisieren“. " Taste.

Wie gehe ich mit Hotspot-Daten im Flash-Sale-System um?

Was ist „Hotspot“?

Hotspots werden in Hotspot-Vorgänge und Hotspot-Daten unterteilt.

Die sogenannten „Hot Operations“, wie z. B. eine große Anzahl von Seitenaktualisierungen, eine große Anzahl von Einkaufswagen hinzufügen, eine große Anzahl von Bestellungen um 0:00 Uhr bei Double Eleven usw., fallen alle in diese Kategorie . Für das System können diese Vorgänge in „Leseanfragen“ und „Schreibanfragen“ abstrahiert werden. Diese beiden Hotspot-Anfragen werden auf sehr unterschiedliche Weise behandelt. Der Optimierungsraum für Leseanfragen ist im Allgemeinen größer Die Idee der Optimierung besteht darin, auf der Grundlage der CAP-Theorie diesen Inhalt im Detail vorzustellen.

Die „Hotspot-Daten“ sind leichter zu verstehen, also die Daten, die der Hotspot-Anfrage des Benutzers entsprechen. Hotspot-Daten werden in „statische Hotspot-Daten“ und „dynamische Hotspot-Daten“ unterteilt.

Die sogenannten „statischen Hotspot-Daten“ beziehen sich auf Hotspot-Daten, die im Voraus vorhergesagt werden können. Beispielsweise können wir durch die Registrierung vorab Verkäufer herausfiltern und diese heißen Produkte über das Registrierungssystem markieren. Darüber hinaus können wir Big-Data-Analysen nutzen, um beliebte Produkte im Voraus zu entdecken. Beispielsweise analysieren wir historische Transaktionsdatensätze und Benutzer-Warenkorbdaten, um herauszufinden, welche Produkte möglicherweise beliebter sind und sich besser verkaufen vorab analysiert werden.

Die sogenannten „dynamischen Hotspot-Daten“ beziehen sich auf Hotspots, die nicht im Voraus vorhersehbar sind und vorübergehend während des Betriebs des Systems entstehen. Wenn beispielsweise ein Verkäufer auf Douyin wirbt, wird das Produkt sofort beliebt, sodass es in kurzer Zeit in großen Mengen gekauft wird.

Da Hotspot-Vorgänge Benutzerverhalten sind, können wir sie nicht ändern, aber wir können einige Einschränkungen und Schutzmaßnahmen vornehmen. Daher werde ich in diesem Artikel hauptsächlich die Optimierung von Hotspot-Daten vorstellen.

Hotspot-Daten entdecken

1. Statische Hotspot-Daten entdecken
2. Dynamische Hotspot-Daten entdecken

Hotspot-Daten verarbeiten

Optimierung

Der effektivste Weg, Hotspot-Daten zu optimieren, ist das Zwischenspeichern Hotspot-Daten: Wenn Hotspot-Daten von statischen Daten getrennt werden, können statische Daten für eine lange Zeit zwischengespeichert werden. Das Zwischenspeichern von Hotspot-Daten ist jedoch eher ein „temporärer“ Cache, d. h. unabhängig davon, ob es sich um statische oder dynamische Daten handelt, werden sie für einige Sekunden kurz in einer Warteschlange zwischengespeichert der LRU-Eliminierungsalgorithmus.

Einschränkungen

Einschränkung ist eher ein Schutzmechanismus, und es gibt viele Möglichkeiten, ihn einzuschränken. Führen Sie beispielsweise einen konsistenten Hash für die ID des Produkts durch, auf das zugegriffen wird, und legen Sie dann eine Verarbeitungswarteschlange für jeden Bucket fest. Damit heiße Produkte verarbeitet werden können. Durch die Beschränkung auf eine Anforderungswarteschlange wird verhindert, dass bestimmte heiße Produkte zu viele Serverressourcen beanspruchen und dazu führen, dass andere Anforderungen niemals Verarbeitungsressourcen vom Server erhalten.

Isolierung

Das erste Prinzip des Flash-Sale-Systemdesigns besteht darin, diese Art von heißen Daten zu isolieren. Lassen Sie nicht zu, dass 1 % der Anfragen die anderen 99 % beeinträchtigen 1 % der Anfragen. Gezielte Optimierung. Isolation kann unterteilt werden in: Geschäftsisolation, Systemisolation und Datenisolation.

So glätten Sie Verkehrsspitzen

Genau wie auf den Straßen in der Stadt gibt es aufgrund der Probleme der Morgen- und Abendspitze eine Lösung durch Spitzenverschiebung und Verkehrsbeschränkungen.

Das Vorhandensein von Peak-Clipping kann erstens die Serververarbeitung stabiler machen und zweitens die Ressourcenkosten des Servers einsparen.

Für das Flash-Sale-Szenario dient das Peak-Clipping im Wesentlichen dazu, die Ausgabe von Benutzeranfragen weiter zu verzögern, um einige ungültige Anfragen zu reduzieren und herauszufiltern. Es folgt dem Prinzip „Die Anzahl der Anfragen sollte so gering wie möglich sein“.

Ideen zur Reduzierung von Verkehrsspitzen

Warteschlange

Um Verkehrsspitzen zu erreichen, besteht die einfachste Lösung darin, Nachrichtenwarteschlangen zu verwenden, um den momentanen Verkehr zu puffern, synchrone direkte Anrufe in asynchrone indirekte Pushs umzuwandeln und eine Warteschlange zu übertragen, die den momentanen Verkehr abwickelt an einem Ende seinen Höhepunkt erreicht und am anderen Ende sanft Botschaften ausstößt.

Zusätzlich zu Nachrichtenwarteschlangen gibt es viele ähnliche Warteschlangenmethoden, wie zum Beispiel:

• Die Verwendung des Thread-Pools zum Sperren und Warten ist auch eine gängige Warteschlangenmethode;
• Häufig verwendete Speicherwarteschlangenmethoden wie In-First-Out und First-In-Last-Out Die Implementierungsmethode des Algorithmus;
• serialisiert die Anforderung in eine Datei und liest die Datei dann nacheinander (z. B. den auf MySQL-Binlog basierenden Synchronisierungsmechanismus), um sie wiederherzustellen die Anfrage usw.

Es ist ersichtlich, dass diese Methoden ein gemeinsames Merkmal haben, nämlich die Umwandlung der „einstufigen Operation“ in eine „zweistufige Operation“, bei der die hinzugefügte einstufige Operation als Funktion verwendet wird Puffer.

Leistungsoptimierung

• Reduzierte Codierung
• Reduzierte Serialisierung
• Java ultimative Optimierung
• Gleichzeitige Leseoptimierung

"Inventarreduzierung"-Kern Logik

Das ist sehr wichtig, Alle anderen Schritte sind Hilfsschritte. Wenn 100 Stück auf Lager sind, verkaufen Sie einfach 100 Stück und reduzieren Sie den Wert in der Datenbank auf 0. Was ist das Problem? Ja, das ist theoretisch der Fall, aber in bestimmten Geschäftsszenarien ist die „Reduzierung des Lagerbestands“ nicht so einfach.

Wie kann der Lagerbestand reduziert werden?

Klicken Sie auf der Produktseite auf die Schaltfläche „Jetzt kaufen“, überprüfen Sie die Informationen und klicken Sie auf „Bestellung absenden“. Nachdem Sie eine Bestellung aufgegeben haben, können Sie erst dann wirklich kaufen, wenn Sie den Zahlungsvorgang abgeschlossen haben. Denn „Sicherheit in der Tasche“ heißt es so schön.

Vorgänge zur Bestandsreduzierung haben im Allgemeinen die folgenden Methoden:

Bestandsreduzierung nach der Bestellung

Das heißt, nachdem der Käufer eine Bestellung aufgegeben hat, wird die Kaufmenge des Käufers vom Gesamtbestand des Produkts abgezogen. Das Aufgeben einer Bestellung zur Reduzierung des Lagerbestands ist die einfachste Möglichkeit, den Lagerbestand zu reduzieren, und es ist auch die genaueste Kontrollmethode. Bei der Bestellung wird der Warenbestand direkt über den Transaktionsmechanismus der Datenbank gesteuert, sodass überverkaufte Konditionen auftreten nicht vorkommen. Sie müssen jedoch wissen, dass manche Leute nach der Bestellung möglicherweise nicht bezahlen.

Lagerbestandsreduzierung nach Zahlung

Das heißt, nachdem der Käufer die Bestellung aufgegeben hat, wird der Lagerbestand nicht sofort reduziert, sondern der Lagerbestand wird tatsächlich reduziert, bis ein Benutzer bezahlt, andernfalls wird der Lagerbestand für andere Käufer reserviert. Da der Lagerbestand jedoch erst nach erfolgter Zahlung reduziert wird, kann es bei relativ hoher Parallelität dazu kommen, dass der Käufer nach der Bestellung nicht zahlen kann, weil die Ware möglicherweise von anderen gekauft wurde.

Lagerbestände zurückhalten

Diese Methode ist relativ kompliziert. Nachdem der Käufer eine Bestellung aufgegeben hat, wird der Lagerbestand für einen bestimmten Zeitraum (z. B. 10 Minuten) reserviert Käufer können nach der Veröffentlichung weiterhin kaufen. Bevor der Käufer zahlt, überprüft das System, ob der Lagerbestand der Bestellung noch reserviert ist: Wenn keine Reservierung vorliegt, wird die Einbehaltung erneut versucht. Wenn der Lagerbestand nicht ausreicht (d. h. die Einbehaltung schlägt fehl), erfolgt keine Zahlung kann fortgefahren werden; wenn die Einbehaltung erfolgreich ist, ist die Zahlung abgeschlossen und der Lagerbestand wird tatsächlich abgezogen.

Wo sollen wir mit der Hochverfügbarkeitskonstruktion beginnen?

Apropos Hochverfügbarkeitskonstruktion des Systems: Es handelt sich tatsächlich um ein Systemprojekt, das alle Phasen der Systemkonstruktion berücksichtigen muss, was bedeutet, dass es tatsächlich durchlaufen wird den gesamten Lebenszyklus des Systemaufbaus, wie im Bild unten dargestellt:

Architekturphase

Die Architekturphase berücksichtigt hauptsächlich die Skalierbarkeit und Fehlertoleranz des Systems und vermeidet Einzelpunktprobleme im System. Wenn beispielsweise bei der Einheitsbereitstellung mehrerer Computerräume ein bestimmter Computerraum in einer bestimmten Stadt einen Gesamtausfall erleidet, hat dies dennoch keine Auswirkungen auf den Betrieb der gesamten Website.

Codierungsphase

Das Wichtigste bei der Codierung besteht darin, die Robustheit des Codes sicherzustellen. Wenn es beispielsweise um Remote-Anrufprobleme geht, muss ein angemessener Timeout-Exit-Mechanismus eingerichtet werden, um zu verhindern, dass er von anderen heruntergezogen wird Systeme und die vom Aufruf zurückgegebene Ergebnismenge müssen ebenfalls sichergestellt werden. Um zu verhindern, dass die zurückgegebenen Ergebnisse den Verarbeitungsbereich des Programms überschreiten, besteht die häufigste Methode darin, Fehlerausnahmen zu erfassen und Standardverarbeitungsergebnisse für unvorhergesehene Fehler bereitzustellen.

Testphase

Testen dient hauptsächlich dazu, die Abdeckung von Testfällen sicherzustellen und sicherzustellen, dass wir im schlimmsten Fall auch über entsprechende Verarbeitungsverfahren verfügen.

Release-Phase

Außerdem gibt es einige Dinge, die bei der Veröffentlichung beachtet werden müssen, da während der Veröffentlichung am wahrscheinlichsten Fehler auftreten, sodass ein Notfall-Rollback-Mechanismus vorhanden sein muss.

Laufphase

Die Laufzeit ist der normale Zustand des Systems. Das Wichtigste im laufenden Zustand ist, dass die Überwachung des Systems genau sein muss Wenn Probleme festgestellt werden, müssen der Alarm korrekt und die Alarmdaten genau und detailliert sein, um die Fehlerbehebung zu erleichtern.

Ein Fehler tritt auf

Wenn ein Fehler auftritt, ist das Erste und Wichtigste, den Verlust rechtzeitig zu stoppen. Wenn beispielsweise der Produktpreis aufgrund eines Programmproblems falsch ist, muss das Produkt aus dem Regal genommen werden oder der Kauflink muss rechtzeitig geschlossen werden, um größere Vermögensverluste zu verhindern. Dann gilt es, die Dienste zeitnah wiederherstellen zu können, die Ursache zu lokalisieren und das Problem zu beheben.

Wie können wir den normalen Betrieb unseres Systems bei starkem Verkehr maximieren?

Downgrade

Das sogenannte „Downgrade“ bedeutet, dass bestimmte nicht zum Kerngeschäft gehörende Funktionen des Systems eingeschränkt oder heruntergefahren werden, wenn die Kapazität des Systems ein bestimmtes Niveau erreicht, wodurch begrenzte Ressourcen für weitere Kerngeschäfte reserviert werden. Da es sich um einen zielgerichteten und geplanten Ausführungsprozess handelt, benötigen wir für ein Downgrade im Allgemeinen eine Reihe von Plänen zur Koordinierung der Ausführung. Wenn wir es systematisieren, können wir eine Verschlechterung durch ein Planungssystem und ein Vermittlungssystem erreichen.

Strombegrenzung

Strombegrenzung bedeutet, dass wir das System schützen müssen, indem wir einen Teil des Datenverkehrs einschränken, wenn die Systemkapazität den Engpass erreicht, und nicht nur eine manuelle Umschaltung durchführen, sondern auch einen automatischen Schutz unterstützen können Maßnahmen.

Vor- und Nachteile der clientseitigen Strombegrenzung und der serverseitigen Strombegrenzung:

Die clientseitige Strombegrenzung hat den Vorteil, dass die Ausgabe von Anforderungen begrenzt und der Systemverbrauch reduziert wird, indem die Ausgabe nutzloser Anforderungen reduziert wird. Der Nachteil besteht darin, dass es bei verstreuten Clients unmöglich ist, einen angemessenen Strombegrenzungsschwellenwert festzulegen: Wenn der Schwellenwert zu klein eingestellt ist, wird der Client eingeschränkt, bevor der Server den Engpass erreicht. Wenn er zu groß eingestellt ist, wird dies nicht der Fall sein in der Lage sein, die Grenze zu erreichen.

Der Vorteil der serverseitigen Strombegrenzung besteht darin, dass ein angemessener Schwellenwert entsprechend der Leistung des Servers festgelegt werden kann. Der Nachteil besteht darin, dass es sich bei den eingeschränkten Anforderungen um ungültige Anforderungen handelt und die Verarbeitung dieser ungültigen Anforderungen selbst auch Serverressourcen verbraucht.

Gemeinsamer Strombegrenzungsalgorithmus

Zähleralgorithmus (festes Fenster)

Der Zähleralgorithmus verwendet einen Zähler, um die Anzahl der Besuche innerhalb eines Zyklus zu akkumulieren Begrenzungsstrategie wird ausgelöst. Zu Beginn des nächsten Zyklus wird der Wert gelöscht und erneut gezählt.

Dieser Algorithmus lässt sich sehr einfach in einer eigenständigen oder verteilten Umgebung implementieren. Er kann mithilfe der inkrementellen atomaren Selbstinkrementierung und der Thread-Sicherheit von Redis problemlos implementiert werden.

Schiebefenster-Algorithmus

Der Schiebefenster-Algorithmus unterteilt den Zeitraum in N kleine Zeiträume, zeichnet die Anzahl der Besuche in jedem kleinen Zeitraum auf und löscht abgelaufene kleine Zeiträume basierend auf dem Zeitgleiten. Dieser Algorithmus kann das kritische Problem des Festfensteralgorithmus gut lösen.

Leaky-Bucket-Algorithmus

Der Leaky-Bucket-Algorithmus besteht darin, die Zugriffsanforderung bei ihrem Eintreffen direkt in den Leaky-Bucket zu stellen. Wenn die aktuelle Kapazität die Obergrenze (aktueller Grenzwert) erreicht hat, wird sie verworfen (was den Fehler auslöst). aktuelle Limitpolitik). Der Leaky Bucket gibt Zugriffsanfragen (d. h. die Anforderungen werden weitergeleitet) mit einer festen Rate frei, bis der Leaky Bucket leer ist.

Token-Bucket-Algorithmus

Der Token-Bucket-Algorithmus besteht darin, dass das Programm Token mit einer Rate von r (r=Zeitraum/aktueller Grenzwert) zum Token-Bucket hinzufügt, bis der Token-Bucket voll ist, und dem Token Token hinzufügt Bucket, wenn die Anforderung eintrifft. Bucket-Anforderungstoken. Wenn das Token erhalten wird, wird die Anforderung weitergeleitet. Andernfalls wird die aktuelle Begrenzungsrichtlinie ausgelöst den Dienst direkt verweigern. Wenn die Systemlast einen bestimmten Schwellenwert erreicht, beispielsweise die CPU-Auslastung 90 % erreicht oder der Systemlastwert 2*CPU-Kerne erreicht, lehnt das System alle Anfragen direkt ab. Diese Methode ist die heftigste, aber auch effektivste Systemschutzmethode . Für das Flash-Sale-System entwerfen wir beispielsweise einen Überlastschutz in folgenden Aspekten:

Richten Sie einen Überlastschutz auf dem Front-End-Nginx ein. Wenn die Maschinenlast einen bestimmten Wert erreicht, lehnt es die HTTP-Anfrage direkt ab und gibt eine 503 zurück Fehlercode. Dasselbe kann auf der Java-Ebene mit Überlastungsschutz durchgeführt werden. Denial of Service kann als letztes Mittel bezeichnet werden, um den schlimmsten Fall zu verhindern und zu verhindern, dass der Server über einen längeren Zeitraum hinweg völlig außerstande ist, Dienste bereitzustellen. Obwohl ein solcher Systemüberlastungsschutz bei Überlastung keine Dienste leisten kann, kann das System dennoch betrieben werden und sich problemlos erholen, wenn die Last abfällt. Daher sollte jedes System und jede Verbindung diesen Backup-Plan einrichten, um das System auf den schlimmsten Fall vorzubereiten. unter Schutz.

Cache-Probleme

Cache-Lawine

Daten werden nicht in den Cache geladen oder der Cache fällt in einem großen Bereich gleichzeitig aus, was dazu führt, dass alle Anfragen die Datenbank durchsuchen müssen, was zu Datenbank-, CPU- und Speicherproblemen führt Überlastung oder sogar Ausfallzeiten.

Ein einfacher Lawinenprozess:

1) Großflächiger Ausfall des Redis-Clusters;

2) Caching-Fehler, aber es gibt immer noch eine große Anzahl von Anfragen für den Zugriff auf den Cache-Dienst Redis; Bei fehlgeschlagenen Redis-Anfragen werden die Anfragen an die Datenbank umgeleitet

4) Datenbankanfragen nehmen stark zu, was dazu führt, dass die Datenbank abstürzt

5) Da die meisten Ihrer Anwendungsdienste auf die Datenbank- und Redis-Dienste angewiesen sind, wird dies bald der Fall sein verursachen eine Lawine des Serverclusters und schließlich wird das gesamte System vollständig zusammenbrechen.

Lösung

:

Vorab

: Hochverfügbarer Cache Hochverfügbarer Cache soll den gesamten Cache-Ausfall verhindern. Selbst wenn einzelne Knoten, Maschinen oder sogar Computerräume heruntergefahren werden, kann das System weiterhin Dienste bereitstellen und sowohl Redis Sentinel als auch Redis Cluster können eine hohe Verfügbarkeit erreichen.

Laufend

: Cache-Downgrade (vorübergehende Unterstützung)

Wie stellen wir sicher, dass der Dienst weiterhin verfügbar ist, wenn ein starker Anstieg der Besuche zu Problemen mit dem Dienst führt? Hystrix, das in China weit verbreitet ist, verwendet drei Methoden: Sicherung, Herabstufung und Strombegrenzung, um Verluste nach Lawinen zu reduzieren. Solange die Datenbank nicht tot ist, kann das System immer auf Anfragen reagieren. Kommen wir nicht jedes Mal zum Frühlingsfest 12306 hierher? Solange Sie noch antworten können, haben Sie zumindest die Chance, ein Ticket zu ergattern.

Nach dem Ereignis: Redis-Sicherung und schnelles Aufwärmen

1) Redis-Datensicherung und -wiederherstellung

2) Schnelles Cache-Aufwärmen

Cache-Aufschlüsselung

Cache-Aufschlüsselung bedeutet, dass der Hotspot-Datenspeicher abläuft. Mehrere Threads fordern gleichzeitig Hotspot-Daten an. Da der Cache gerade abgelaufen ist, werden alle gleichzeitigen Anforderungen an die Datenbank gesendet, um Daten abzufragen.

Lösung:

Tatsächlich erfolgt der Cache-Ausfall in den meisten tatsächlichen Geschäftsszenarien in Echtzeit, aber er wird die Datenbank nicht zu stark belasten, da im allgemeinen Unternehmensgeschäft das Ausmaß der Parallelität nicht so hoch sein wird hoch . Wenn Ihnen das passiert, können Sie diese Hotspot-Schlüssel natürlich so einstellen, dass sie niemals ablaufen. Eine andere Methode besteht darin, eine Mutex-Sperre zu verwenden, um den Thread-Zugriff auf die Abfragedatenbank zu steuern. Dies führt jedoch zu einer Verringerung des Systemdurchsatzes und muss in tatsächlichen Situationen verwendet werden.

Cache-Penetration

Cache-Penetration bezieht sich auf die Abfrage von Daten, die definitiv nicht vorhanden sind. Da sich keine Informationen über die Daten im Cache befinden, werden diese direkt auf der Datenbankebene abgefragt Diese Art der Abfrage von Daten, die nicht vorhanden sein dürfen, kann eine Gefahr für das System darstellen Darf nicht vorhanden sein, um häufige Anfragen an das System zu stellen, nein, um genau zu sein, Angriffe auf das System, die Anfragen erreichen die Datenbankschicht, was zu Datenbanklähmungen und Systemausfällen führt.

Lösung:

Die Lösungen in der Cache-Penetrationsbranche sind relativ ausgereift. Die am häufigsten verwendeten sind die folgenden:

• Bloom-Filter: ein Algorithmus ähnlich einer Hash-Tabelle, der alle möglichen Abfragebedingungen generiert Eine Bitmap wird zum Filtern vor der Datenbankabfrage verwendet. Wenn sie nicht in der Abfrage enthalten ist, wird sie direkt gefiltert, wodurch der Druck auf der Datenbankebene verringert wird.
• Nullwert-Cache: Eine relativ einfache Lösung besteht darin, den Schlüssel und den entsprechenden Nullwert (Null oder nur Schlüssel im Objekt) nach der ersten Abfrage der nicht vorhandenen Daten in den Cache zu legen B. ein paar Minuten, damit Sie in kurzer Zeit eine große Anzahl von Angriffen auf diesen Schlüssel abwehren können. Der Grund für die Einstellung einer kürzeren Ablaufzeit liegt darin, dass dieser Wert möglicherweise nichts damit zu tun hat Das Unternehmen ist nicht von Bedeutung, und seine Existenz ist von geringer Bedeutung. Die Abfrage kann nicht von einem Angreifer initiiert werden und es besteht keine Notwendigkeit, sie über einen längeren Zeitraum zu speichern, sodass sie frühzeitig ungültig gemacht werden kann.

Zusammenfassung

Da dieser Artikel ein theoretischer Artikel ist, enthält der gesamte Artikel keine einzige Codezeile, sondern was im Artikel vorgeschlagen wird, ist im Grunde das, was im Flash-Sale-System passiert ist, und Die Probleme, die in jedem System auftreten können, sind unterschiedlich.

Das obige ist der detaillierte Inhalt vonMehr als 6.000 Wörter |. Punkte, die beim Entwerfen des Flash Kill-Systems zu beachten sind. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!