Echte Redis-Cache-Optimierung – Haben Sie jemals eine Optimierungsrate von 97 % gesehen? | Technisches Team von JD Cloud

Dieser Artikel verwendet einen R2M-Alarm vor 618 (unternehmensinterne Cache-Komponente, der als Äquivalent zu Redis angesehen werden kann ), analysiert die direkten und Grundursachen des Alarms von oberflächlich bis tief und schlägt entsprechende Lösungen basierend auf den Gründen vor. Ich hoffe es kann jedem bei der Behebung ähnlicher Probleme entsprechende Anregungen geben.

1. Fehlerbehebung

1.1 E-Mail-Benachrichtigung

Kurz bevor die Notrufnummer 618 Dienst hatte, erhielt ich eines Tages eine E-Mail-Benachrichtigung mit folgendem Inhalt:

Hallo, R2M-Überwachungsalarm, bitte verfolgen Sie ihn rechtzeitig! Alarminformationen: Alarm-ID: 6825899, Anwendung: zr_credit_portal, Verantwortlicher: zhangsan, Alarmtyp: Speichernutzung, Zeit: 2023-06-15 16:00:04. Instanz: (10.0.0.0:5011-slave), aktuell: 9212 MB, Überschreitung des Warnwerts: 8748 MB, maximaler Instanzspeicher: 10800 MB, Speichernutzung: 85 %; Instanz: (10.0.0.0:5023-master), aktuell: 9087 MB, Überschreitung des Warnwerts: 8748 MB Maximaler Speicher der Instanz: 10800 MB, Speichernutzung: 84 %; Instanz: (10.0.0.0:5017-Master), aktuell: 9214 MB Überschreitung des Warnwerts: 8748 MB Maximaler Speicher der Instanz: 10800 MB, Speichernutzung: 85 %;

Der allgemeine Inhalt ist, dass die Auslastung des R2M-Clusters 85 % erreicht hat und dringend behoben werden muss.

Unsere Cache-Cluster-Konfiguration ist wie folgt: Mit einer Gesamtkapazität von 32.400 MB, drei Mastern und drei Slaves hat jeder Masterknoten eine Kapazität von 10.800 MB und die derzeit höchste Auslastung hat 9.087 MB erreicht. R2M verwendet den Cluster-Modus für die Bereitstellung.

Die erste Idee besteht darin, Big-Key-Statistiken zu verwenden, um zu sehen, welche Caches Kapazität belegen. Da große Schlüsselstatistiken vom Slave-Knoten gescannt werden, besteht kein Grund zur Sorge, dass der Haupt-Online-Prozess beeinträchtigt wird.

1.2 Code-Analyse

Große Schlüssel werden hauptsächlich in zwei Kategorien unterteilt: xxx_data und xxx_interfacecode_01 . Befolgen Sie diese Regel, um den Ort zum Speichern des Schlüssels im Code zu finden.

String dataKey = task.getTaskNo() + "_data";
cacheClusterClient.setex(dataKey.getBytes(), EXPIRATION, DataUtil.objectToByte(paramList));

key = task.getTaskNo() + "_" + item.getInterfaceCode() + "_" + partCount;
cacheClusterClient.setex(key.getBytes(), EXPIRATION,DataUtil.objectToByte(dataList));

Analysieren Sie den Geschäftsprozess, nachdem Sie den Speicherort des Codes gefunden haben:

1.3 Gründe zur Besorgnis

Basierend auf der obigen Analyse lassen sich die Gründe für die hohe Auslastung in direkte Ursachen und Grundursachen unterteilen:

1.3.1 Direkte Ursache

Bei der Überprüfung des Operations-Backends stellten wir fest, dass ein Benutzer in den letzten drei Tagen eine große Anzahl von Stapelverarbeitungsaufgaben erstellt hatte, was zu einem Anstieg der Anzahl von Proben und Ergebnissen im Cache und damit zu einer übermäßigen Cache-Nutzung führte.

1.3.2 Grundursache

Nach der Analyse des Codes befinden sich gemäß der obigen Beschreibung zwei Hauptdaten im Cache: Proben und Ergebnisse.

• Zuerst wird die Probe im Cache gespeichert und dann zufällig entnommen. Dieser Vorgang ist bedeutungslos und belegt nur die Cache-Kapazität.

• Die Ergebnisse werden in Stapeln und Shards gespeichert. Dieser Schritt ist sinnvoll. Er dient hauptsächlich dazu, zu verhindern, dass die Daten viel Platz in der JVM beanspruchen, wenn die Daten während der Multitask-Parallelverarbeitung nicht fragmentiert und im Cache gespeichert werden kann zu einer VOLLSTÄNDIGEN GC-Frage führen. (In früheren Artikeln analysiert)

• Nach Abschluss des Batch-Laufs sind die Zwischendaten normalerweise unbrauchbar, der Geschäftsprozess löscht die nutzlosen Daten jedoch nicht aktiv, sondern löscht sie automatisch, nachdem er auf eine Zeitüberschreitung gewartet hat. Dieser Vorgang führt dazu, dass die Daten für eine Weile im Cache gespeichert werden zusätzliche Zeitspanne.

Zu diesem Zeitpunkt wurde der Grund für die hohe Cache-Nutzung analysiert (eigentlich noch nicht, die direkte Ursache wurde nur oberflächlich analysiert und die „Grundursache“ der direkten Ursache wurde noch nicht geklärt).

2. Problemlösung

Oben wurde der Fehlerbehebungsprozess dieses Alarms analysiert. Im Folgenden wird beschrieben, wie das Problem gelöst werden kann, das auch in die Lösung der direkten Ursache und die Lösung der Grundursache unterteilt ist.

2.1 Direkte Ursache

2.1.1 Ursachenanalyse

Am Vorabend von 618 ist es am besten, die Auswirkungen des Betriebs auf das System nicht zu berücksichtigen. Daher können wir nur in Betracht ziehen, die entsprechenden Benutzer aufzufordern, die Erstellung laufender Stapel vorübergehend einzustellen, um zu vermeiden, dass weiterhin Speicher belegt wird und das Online-Geschäft beeinträchtigt wird.

Zu diesem Zeitpunkt haben wir bei der Beobachtung des Überwachungsdiagramms Folgendes festgestellt:

Der Benutzer hat vor drei Tagen mit der Erstellung von Batch-Aufgaben begonnen (entsprechend dem Zeitpunkt, als der Cache zu wachsen begann), aber der Cache ist nur für einen Tag gültig. Logischerweise sollte der Cache ab dem nächsten Tag stark fallen ( Da der Cache Warum steigt die Cache-Nutzungsrate in den letzten drei Tagen bei Betrachtung des Überwachungsdiagramms nahezu linear an?

Sie können hier an 30s denken, was mit Redis-Funktionen zusammenhängt.

Nachdem ich auf dieses Problem aufmerksam gemacht hatte, begann ich darüber nachzudenken, ob es möglich ist, dass die Daten nicht tatsächlich physisch gelöscht wurden, obwohl wir das Zeitlimit auf einen Tag festgelegt haben (Redis ' Cache-Eliminierungsstrategie )?

Dann schauen Sie sich die R2M-bezogenen Dokumente an:

In:

Wenn viele Schlüssel mit einer Lebensdauer vorhanden sind, 0kann zwischen der Änderung der Schlüssellebensdauer und dem tatsächlichen Löschen der Schlüssel ein erheblicher Zeitabstand liegen.

Ist das nicht unser Merkmal? Wie Sie auf dem Bild sehen können, auf dem wir gerade nach großen Schlüsseln gesucht haben, haben wir viele Schlüssel mit Zeitüberschreitungen und die Größen sind sehr groß. Es ist sehr wahrscheinlich, dass sie zwar eine Zeitüberschreitung hatten (das Das heißt, die TTL wird 0. Auf die Daten wurde nicht zugegriffen, und aufgrund der progressiven Löschung durch R2M wird ein bestimmter Schlüssel möglicherweise erst lange nach dem Timeout tatsächlich physisch gelöscht .

An diesem Punkt wurde die Grundursache der direkten Ursache gefunden.

2.1.2 Lösung

Wie kann man es also lösen? Gemäß zwei Strategien wird ein Schlüssel physisch gelöscht, wenn er abläuft:

Beachten:

Redis verwendet die folgenden zwei Methoden, um abgelaufene Schlüssel zu löschen

• Wenn auf einen Schlüssel zugegriffen wird, überprüft das Programm den Schlüssel und wenn der Schlüssel abgelaufen ist, wird der Schlüssel gelöscht.

• Das zugrunde liegende System sucht und löscht nach und nach abgelaufene Schlüssel im Hintergrund und verarbeitet so Schlüssel, die abgelaufen sind, auf die aber nicht zugegriffen werden kann.

Erstens ist es dumm und unnötig, Daten durch Zugriff darauf zu löschen (es ist besser, sie direkt zu löschen, wenn Sie darauf zugreifen können und wissen, dass sie bald ablaufen), dann können Sie die progressive Suchrate erhöhen . Dadurch werden diese abgelaufenen Daten physisch gelöscht

Deshalb haben wir den entsprechenden Betriebs- und Wartungsdienst von R2M kontaktiert:

Den obigen Chat-Aufzeichnungen zufolge gibt es tatsächlich Parameter zum Anpassen der Häufigkeit des progressiven physischen Löschens . Aus unbekannten Gründen wurde unser Cache-Cluster zuvor auf 10 eingestellt (das Projektteam hat Änderungen vorgenommen), was etwa sechsmal niedriger ist. Dieses Ergebnis ist Außerdem entspricht es unseren Erwartungen und bestätigt, dass unsere Vermutung richtig ist.

Es war am Vorabend von 618 und wir haben diesen Parameter nicht geändert. Nach 618 haben wir sofort einen Arbeitsauftrag zur Änderung dieses Parameters übermittelt und den Parameter von 10 auf 80 erhöht:

Nachdem die Genehmigung bestanden wurde, beobachten wir die Rückgangsrate von r2m:

Es ist ersichtlich, dass nach der Anpassung der Parameter am 20. Juni die Rückgangsrate der R2M-Nutzung deutlich schneller wurde, nachdem keine großen Datenmengen hinzugefügt wurden .

Zu diesem Zeitpunkt wurde die direkte Ursache für den Cache-Nutzungsalarm behoben. Der wahre Grund liegt darin, dass eine große Anzahl von Schlüsseln nach Ablauf nicht gelöscht wurde. Es wird beobachtet, dass die nachfolgende Cache-Nutzung nicht zu hoch ist. Wenn außerdem eine große Anzahl ausgeführter Batch-Aufgaben vorhanden ist und diese nicht direkt am selben Tag hinzugefügt werden, führt dies im Allgemeinen nicht zu hohen Nutzungsproblemen.

2.2 Grundursache

Nach der Anpassung der oben genannten Parameter kann es grundsätzlich den täglichen Geschäftsanforderungen des Benutzers gerecht werden. Wenn der Benutzer jedoch eine große Anzahl von Batch-Aufgaben an einem Tag ausführen muss, kann diese Lösung das grundlegende Problem immer noch nicht lösen und kann dies auch tun Dies kann dazu führen, dass die Nutzungsrate zu hoch ist. Risiken für das Online-Geschäft.

Um dieses Problem grundlegend zu lösen, müssen wir den Batch-Prozess optimieren. Gemäß dem Prozessdiagramm und der Ursachenanalyse in 1.2:

1. Es ist nicht erforderlich, die Beispiele im Cache zu speichern, sodass die Parameter direkt an den nächsten Schritt im Code übergeben werden.

2. Ergebnis-Sharding ist aus den oben genannten Gründen auf jeden Fall sinnvoll, aber der Redis-Cache-Speicherplatz (d. h. Speicher) ist relativ wertvoll, während die Speicherplatzkosten (Festplatte) von OSS relativ günstig sind und wenn man bedenkt, dass das Geschäft selbst offline ist und die Abfragegeschwindigkeit sind nicht die kritischsten Faktoren, daher wird der Speicherung der Shard-Daten der Batch-Laufergebnisse in OSS umfassend Rechnung getragen.

3. Nach Abschluss des Batch-Laufvorgangs werden die resultierenden Shard-Daten im OSS aktiv gelöscht, um zu verhindern, dass die Daten nach ihrer Unbrauchbarkeit noch Speicherplatz belegen. Darüber hinaus ist auf der Oss-Seite die automatische Löschung auf 7 Tage eingestellt, um zu verhindern, dass Daten aufgrund abnormaler Systemgründe dauerhaft gelöscht werden.

Zusammenfassend sieht das neu gestaltete Flussdiagramm in Kombination mit den oben genannten Optimierungsideen wie folgt aus:

Unabhängig davon, wie groß die Menge der nachfolgenden Benutzerdaten ist und ob sie an einem Tag oder an mehreren Tagen erstellt werden, löst dies zu diesem Zeitpunkt keine Cache-Nutzungsalarme aus und kann zu Problemen im Online-Geschäft führen.

2.3 Optimierungsrate

Cache-Nutzung nach Online-Abschluss:

Sie können sehen, dass es sich fast um einen Abgrund handelt.

Cache-Optimierungsrate:

Transformation des ersteren

Nach der Transformation

(8,35-0,17)/8,35≈97,96 %

3. Zusammenfassung

In diesem Artikel wird hauptsächlich eine Alarm-E-Mail verwendet, um die Caching-Probleme und die Prozessoptimierung im System von oberflächlich bis tief zu analysieren. Nachdem wir das eigentliche Problem gelöst haben, sollten wir alle einige Erfahrungen und Zusammenfassungen haben, damit wir beim nächsten Mal solche Probleme im Entwicklungsprozess vermeiden können, und wir können uns auch noch einmal zusammenfassen und archivieren. Um zu wissen, was geschieht, muss man auch wissen, warum es geschieht . Die folgende Zusammenfassung ist ein kleiner Teil meiner eigenen Erfahrung von oberflächlich bis tief.

3.1 Unterschiedliche Middleware sollte für unterschiedliche Dinge verantwortlich sein

„Han Xin befiehlt Truppen, je mehr, desto besser.“ Ein guter General ist jemand, der verschiedenen Soldaten unterschiedliche Verantwortlichkeiten zuweisen kann, damit die Soldaten ihre Aufgaben in ihren Fachgebieten erfüllen können. Für unsere Forschung und Entwicklung kann die Auswahl unterschiedlicher Middleware zur Ausführung verschiedener Funktionen das technische Niveau unserer Forschung und Entwicklung widerspiegeln.

Für diesen Artikel stehen viele Middlewares zum Speichern von Zwischendaten zur Verfügung. Neben Redis und Oss gibt es auch MySQL, Hive, ES, CK usw. Wir müssen je nach Geschäftsanforderungen unterschiedliche Middlewares auswählen, um die entsprechenden Funktionen auszuführen . In diesem Fall ist es offensichtlich, dass die Dateneigenschaften große Mengen sind und keine Geschwindigkeit erfordern , während die Speichereigenschaften von Redis kleine Mengen und schnell sind. Es ist offensichtlich, dass es sich bei diesen beiden um widersprüchliche Bedürfnisse und Unternehmen handelt, daher sollten wir uns dafür entscheiden Richten Sie es bei der Auswahl der Middleware ein.

3.2 Ist es sinnvoll, technische Details zu erfahren?

Tatsächlich habe ich schon viele Details zur Technologie und Framework-Implementierung gelernt, aber die meisten davon wurden sofort nach dem Lernen abgeschlossen und es gab nicht viel Übung. Diese Fallanalyse erfolgte unmittelbar nachdem ich die relevanten Details von Redis kennengelernt hatte, und es dauerte nicht lange, bis ich sie auf diese praktische Sitzung anwenden konnte, die als eine Kombination aus Theorie und Praxis betrachtet werden kann. Darüber hinaus kann dieser Fall Ihr Interesse am Lernen erheblich steigern.

Autor: JD Technology Korea Kai

Quelle: JD Cloud Developer Community Bitte geben Sie beim Nachdruck die Quelle an

200 Yuan Geldstrafe und mehr als 1 Million Yuan beschlagnahmt You Yuxi: Die Bedeutung hochwertiger chinesischer Dokumente Musks Hardcore-Migrationsserver Solon für JDK 21, virtuelle Threads sind unglaublich! ! ! TCP-Überlastungskontrolle rettet das Internet- Flutter für OpenHarmony ist da. Die LTS-Periode des Linux-Kernels wird von 6 auf 2 Jahre wiederhergestellt. Go 1.22 behebt den Variablenfehler der For-Schleife. Svelte hat ein „neues Rad“ gebaut – Runen. Google feiert sein 25-jähriges Jubiläum

{{o.name}}

{{m.name}}