Das System ist kaputt. Es erkennt nur den Code, nicht aber die Personen.

Liebe Freunde, hören Sie auf meinen Rat, wenn Sie Code schreiben, um Methoden bereitzustellen, die andere aufrufen können, sei es ein interner Systemaufruf, ein externer Systemaufruf oder ein passiv ausgelöster Aufruf (z. B. MQ-Verbrauch, Rückrufausführung usw.). usw.), müssen Sie die erforderliche Zustandsprüfung hinzufügen. Glauben Sie nicht einigen Kollegen, die sagen, dass diese Bedingung definitiv übertragen wird, dass sie definitiv einen Wert hat, dass sie definitiv nicht leer sein wird usw. Nein, kurz vor dem chinesischen Neujahr wurde ich ausgetrickst und hatte einen Produktionsunfall, sodass mein Jahresendbonus quasi um die Hälfte gekürzt wurde.

Ich habe beschlossen, mich auf den Code selbst und nicht auf die Menschen zu konzentrieren, um eine hohe Systemverfügbarkeit und -stabilität sicherzustellen. Hier sind ein paar kleine Lektionen, die auch Ihnen helfen können.

1. Was ist passiert

Mein Geschäftsszenario ist: Wenn sich Geschäft A ändert, wird das Senden von MQ-Nachrichten ausgelöst, und dann empfängt die Anwendung die MQ-Nachrichten und nach der Verarbeitung werden die Daten in Elasticsearch geschrieben.

(1) Ich habe einen ungewöhnlichen Alarm von Unternehmen A erhalten. Der Alarm lautete zu diesem Zeitpunkt wie folgt:

(2) Es scheint auf den ersten Blick etwas seltsam. Wie könnte es eine Redis-Anomalie sein? Dann habe ich eine Verbindung zu Redis hergestellt und es gab kein Problem. Ich habe den Redis-Cluster erneut überprüft und alles war normal. Also ließ ich es sein und dachte, es sei ein zufälliges Netzwerkproblem.

Dann meldete der Kundendienst, dass bei einigen Benutzern ungewöhnliche Situationen auftraten. Ich überprüfte sofort das System, um das Vorliegen sporadischer Probleme zu bestätigen.

(4) Also habe ich mir aus Gewohnheit ein paar Kernkomponenten angeschaut:

• Gateway-Status, Ladestatus der Kerngeschäfts-Pods und Ladestatus der User-Center-Pods.
• MySQL-Situation: Speicher, CPU, langsames SQL, Deadlock, Anzahl der Verbindungen usw.

Ich habe die Situation von langsamem SQL und langer Metadaten-Sperrzeit festgestellt, die hauptsächlich auf die große Datenmenge und die langsame Ausführungsgeschwindigkeit zurückzuführen ist, die durch die vollständige Tabellenabfrage einer großen Tabelle verursacht werden, was wiederum dazu führt, dass die Metadaten-Sperre zu lange anhält und somit anstrengend ist die Datenbankverbindungsnummer.

SELECT xxx,xxx,xxx,xxx FROM 一张大表

(6) Nachdem ich mehrere langsame Sitzungen sofort beendet hatte, stellte ich fest, dass sich das System immer noch nicht vollständig erholt hatte. Warum? Warum wurde die Datenbank nun, da sie normal ist, nicht vollständig wiederhergestellt? Ich schaute mir weiterhin die Anwendungsüberwachung an und stellte fest, dass zwei der zehn Pods im Benutzerzentrum abnormal waren und die CPU und der Speicher erschöpft waren. Kein Wunder, dass es bei der Verwendung gelegentlich zu Auffälligkeiten kommt. Also habe ich den Pod schnell neu gestartet und zunächst die Anwendung wiederhergestellt.

(7) Das Problem wurde gefunden. Als nächstes werden wir weiter untersuchen, warum der Pod im User Center hängen bleibt. Beginnen Sie mit der Analyse anhand der folgenden Zweifelspunkte:

• Stimmt etwas mit dem Code zum Synchronisieren von Daten mit Elasticsearch nicht? Warum kann keine Verbindung zu Redis hergestellt werden?
• Könnte es zu viele Ausnahmen geben, die dazu führen, dass die Thread-Pool-Warteschlange zum Senden von Ausnahmewarnmeldungen voll ist und es dann zu OOM kommt?
• Wo kann ich eine bedingungslose vollständige Tabellenabfrage für die große Tabelle von Unternehmen A durchführen?

(8) Untersuchen Sie weiterhin den Verdachtspunkt a. Zuerst dachte ich, dass der Redis-Link nicht abgerufen werden konnte, was dazu führte, dass die Ausnahme in die Thread-Pool-Warteschlange gelangte, und dann platzte die Warteschlange, was zu OOM führte. Gemäß dieser Idee habe ich den Code geändert, aktualisiert und weiter beobachtet, aber es kam immer noch zur gleichen langsamen SQL- und User-Center-Explosion. Da keine Auffälligkeit vorliegt, kann auch der Verdachtspunkt b ausgeschlossen werden.

(9) Zu diesem Zeitpunkt ist es fast sicher, dass Punkt C vermutet wird. Dort wird die vollständige Tabellenabfrage der großen Tabelle von Unternehmen A aufgerufen, was dazu führt, dass der Speicher im Benutzercenter zu groß ist JVM hat keine Zeit, es zu recyceln, und explodiert dann direkt die CPU. Da die gesamten Tabellendaten zu groß sind, ist gleichzeitig die Metadaten-Sperrzeit während der Abfrage zu lang, was dazu führt, dass die Verbindung nicht rechtzeitig freigegeben werden kann und schließlich fast erschöpft ist.

(10) Daher wurden die notwendigen Verifizierungsbedingungen für die Abfrage der großen Tabelle von Unternehmen A geändert und für die Online-Beobachtung neu bereitgestellt. Es gab ein Problem mit der endgültigen Positionierung.

2. Ursache des Problems

Denn wenn Sie die Geschäftstabelle B ändern, müssen Sie eine MQ-Nachricht senden (synchronisieren Sie die Daten der Geschäftstabelle A mit ES. Fragen Sie nach dem Empfang der MQ-Nachricht die Daten ab, die sich auf die Geschäftstabelle A beziehen, und synchronisieren Sie die Daten dann mit Elasticsearch.

Aber beim Ändern des Geschäftstisches B wurden die notwendigen Bedingungen für den Geschäftstisch A nicht übertragen, und ich habe auch die notwendigen Bedingungen nicht überprüft, was zu einem vollständigen Tabellenscan des großen Tisches von Geschäft A führte. Denn:

某些同事说，“这个条件肯定会传、肯定有值、肯定不为空...”，结果我真信了他！！！

Aufgrund der häufigen Änderungen in der Business-B-Tabelle zu diesem Zeitpunkt wurden mehr MQ-Nachrichten gesendet und verbraucht, was mehr vollständige Tabellenscans der großen Tabelle von Business A auslöste, was wiederum zu längeren MySQL-Metadaten-Sperrzeiten führte lang und die endgültige Anzahl der Verbindungen wurde zu hoch.

Gleichzeitig werden die Ergebnisse der großen Tabellenabfrage von Unternehmen A jedes Mal an den Speicher des Benutzerzentrums zurückgegeben, wodurch die JVM-Speicherbereinigung ausgelöst wird, sie jedoch nicht recycelt werden kann. Am Ende sind der Speicher und die CPU erschöpft .

Die Ausnahme, dass Redis die Verbindung nicht herstellen kann, ist nur eine Rauchbombe. Da zu viele MQ-Ereignisse gesendet und verbraucht werden, kann eine kleine Anzahl von Threads die Redis-Verbindung nicht sofort herstellen.

Schließlich habe ich die Bedingungsüberprüfung im Code für die Nutzung von MQ-Ereignissen hinzugefügt und auch die erforderliche Bedingungsüberprüfung an der Abfragegeschäftstabelle A hinzugefügt, sie online erneut bereitgestellt und das Problem gelöst.

3. Fassen Sie die Lektionen zusammen

Nach diesem Vorfall habe ich auch einige Lektionen zusammengefasst und teile sie mit Ihnen:

(1) Seien Sie immer auf der Hut vor Online-Problemen. Sobald ein Problem auftritt, dürfen Sie es nicht loslassen und es schnell untersuchen. Zweifeln Sie nicht mehr am Problem des Netzwerk-Jitters. Die meisten Probleme haben nichts mit dem Netzwerk zu tun.

(2) Die große Geschäftstabelle selbst muss sich des Schutzes bewusst sein und die Abfrage muss die erforderliche Bedingungsüberprüfung hinzufügen.

(3) Beim Konsumieren von MQ-Nachrichten müssen Sie die erforderlichen Bedingungen überprüfen und dürfen keiner Informationsquelle vertrauen.

(4) Glauben Sie niemals einigen Kollegen, die sagen: „Diese Bedingung wird definitiv übertragen, sie wird definitiv einen Wert haben, sie wird definitiv nicht leer sein“ usw. Um eine hohe Verfügbarkeit und Stabilität des Systems zu gewährleisten, erkennen wir nur den Code und nicht die Personen.

(5) Allgemeine Fehlerbehebungsreihenfolge bei auftretenden Problemen:

• Datenbank-CPU, Deadlock, langsames SQL.
• CPU, Speicher und Protokolle des Gateways und der Kernkomponenten der Anwendung.

(6) Geschäftsbeobachtbarkeit und Alarme sind unerlässlich und müssen umfassend sein, damit Probleme schneller entdeckt und gelöst werden können.

Das obige ist der detaillierte Inhalt vonDas System ist kaputt. Es erkennt nur den Code, nicht aber die Personen.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!