Hallo! Ich bin Jayon.

Heute möchte ich die Kriterien für die Cache-Konfiguration erklären. Dieser Beitrag basiert auf meinen persönlichen Erfahrungen in der Praxis, daher sollten Sie ihn nur als Referenz betrachten. ㅎㅎ

Was ist Cache?

Cache bedeutet, Ergebnisse für zukünftige Anfragen vorab zu speichern, um sie schnell bereitzustellen. Das heißt, die Ergebnisse werden im Voraus gespeichert, und bei einer späteren Anfrage wird die Anfrage nicht über DB oder API abgewickelt, sondern der Cache wird aufgerufen, um die Anfrage zu verarbeiten. Der Hintergrund für diese Caches liegt im Pareto-Prinzip.

Das Pareto-Prinzip besagt, dass 80 % der Ergebnisse auf 20 % der Ursachen zurückzuführen sind. Sehen Sie sich dazu bitte das folgende Bild an!

Das heißt, Cache muss nicht für alle Ergebnisse verwendet werden, sondern nur für die 20 %, die am häufigsten in der Dienstleistung verwendet werden, um so die Gesamteffizienz zu steigern.

Welche Daten sollten zwischengespeichert werden?

Gemäß dem Pareto-Prinzip sollten nicht beliebige Daten zwischengespeichert werden, sondern nur die unbedingt notwendigen Daten. Welche Daten sollten dann zwischengespeichert werden?

Daten, die häufig gelesen, aber selten geschrieben werden

Es wird oft gesagt, dass „Daten, die häufig gelesen, aber selten geschrieben werden, zwischengespeichert werden sollten", aber die Kriterien für „häufig lesen" und „selten schreiben" waren sehr vage.

Daher untersuche ich die zu zwischenspeichernden Daten in folgenden Schritten.

• Überprüfen Sie die Top 5 der RDB-Anrufliste mit APM-Tools wie DataDog.
• Suchen Sie nach Abfrageanfragen und finden Sie heraus, aus welcher Tabelle die Abfragen stammen.
• Überprüfen Sie, wie oft die Update-Anfrage für diese Tabelle aufgerufen wird.

Dabei geht es darum, zu sehen, ob die Abfragen häufig sind, aber die Update-Anfragen selten vorkommen. In der Praxis habe ich festgestellt, dass für eine bestimmte Tabelle 1.740.000 Abfragen pro Tag, aber maximal 500 Update-Anfragen stattfanden. Das sind eindeutig geeignete Voraussetzungen für Cache. ㅎㅎ

Daten, die empfindlich auf Aktualisierungen reagieren

Daten, die empfindlich auf Aktualisierungen reagieren, sollten eine geringe Diskrepanz zwischen RDB und Cache aufweisen. Beispielsweise sollten Informationen im Zusammenhang mit Zahlungen, die sehr empfindlich auf Aktualisierungen reagieren, auch dann, wenn sie die oben genannten Cache-Bedingungen erfüllen, mit Vorsicht betrachtet werden.

Ich musste für Tabellen mit Zahlungsinformationen, die diese beiden Eigenschaften erfüllen, Cache verwenden. Daher habe ich Cache nicht für alle Logiken, die diese Tabellen mit Zahlungsinformationen verwenden, angewendet, sondern mich für eine partielle Caching-Lösung für relativ sichere Logiken entschieden, die tatsächlich nicht mit Zahlungen zusammenhängen.

Lokaler Cache vs. globaler Cache

Nachdem wir nun die zu zwischenspeichernden Daten und den Umfang der Zwischenspeicherung festgelegt haben, müssen wir überlegen, „wo" wir die zu zwischenspeichernden Daten speichern sollen. Im Allgemeinen können Sie sie im lokalen Speicher oder auf einem separaten Server wie Redis speichern.

Lokaler Cache

Beim lokalen Caching werden die zu zwischenspeichernden Daten im Arbeitsspeicher des Anwendungsservers gespeichert. Üblicherweise werden Guava Cache oder Caffeine Cache verwendet.

Vorteile

• Da der Cache direkt aus dem Arbeitsspeicher desselben Servers abgefragt werden kann, während die Anwendungslogik ausgeführt wird, ist er sehr schnell.
• Er ist einfach zu implementieren.

Nachteile

• Wenn mehrere Instanzen vorhanden sind, treten mehrere Probleme auf.
  • Änderungen am Cache in einer Instanz können nicht an andere Instanzen weitergegeben werden. Es gibt jedoch auch lokale Caching-Bibliotheken, die Änderungen an andere Instanzen weitergeben können.
  • Da der Cache in jeder Instanz gespeichert wird, muss der Cache neu eingetragen werden, wenn eine neue Instanz gestartet wird. Dadurch kann es zu vielen Cache-Fehlern kommen, was zu einer Überlastung des Datenverkehrs führt und zum Absturz der Instanz führen kann.

Globaler Cache

Beim globalen Caching wird ein separater Server wie Redis verwendet, um die Cache-Daten zu speichern.

Vorteile

• Da der Cache zwischen den Instanzen geteilt wird, können alle Instanzen denselben Cache-Wert erhalten, selbst wenn der Cache in einer Instanz geändert wird.
• Wenn eine neue Instanz gestartet wird, muss sie nur auf das bereits vorhandene Cache-Repository zugreifen, sodass der Cache nicht neu gefüllt werden muss.

Nachteile

• Da der Netzwerkverkehr durchlaufen werden muss, ist er langsamer als der lokale Cache.
• Es muss ein separater Cache-Server bereitgestellt werden, was zusätzliche Infrastrukturkosten verursacht.
  • Infrastrukturkosten? → Serverkosten, Zeit für die Einrichtung und Wartung der Infrastruktur, Planung von Notfallmaßnahmen usw.

Was habe ich gewählt?

Die Anwendungsserver des aktuellen Unternehmens sind so konfiguriert, dass mehrere Instanzen ausgeführt werden, aber ich habe mich für den lokalen Cache entschieden.

Es gibt dafür drei Hauptgründe.

• Die im RDB gespeicherten zu zwischenspeichernden Daten betragen knapp 40.000, so dass sie, wenn sie alle in den Arbeitsspeicher geladen werden, weniger als 4 MB benötigen.
• Die Leistung der Abfragen für datenbezogene Zahlungen musste verbessert werden.
• Es gibt zwar bereits Redis, aber die Speicherung neuer Caches in Redis würde zusätzliche Infrastrukturkosten verursachen.

Wie wird der Cache aktualisiert?

Wenn mehrere Anwendungsserver vorhanden sind, auf denen lokales Caching angewendet wird, kann es sein, dass die im Cache gespeicherten Werte für jeden Anwendungsserver unterschiedlich sind. Beispielsweise kann der im Cache gespeicherte Datenwert des Servers A „1" betragen, während der im Cache gespeicherte Datenwert des Servers B „2" sein kann, nachdem er auf Server B geändert wurde. Wenn ein Benutzer eine Anfrage an den Load Balancer sendet, erhält er unterschiedliche Werte von Server A und Server B.

Daher müssen die Caches für jede Instanz automatisch gelöscht werden, so dass die Daten aus der RDB abgerufen werden können. Dabei wird in der Regel TTL verwendet.

Wie wird TTL eingestellt?

TTL ist die Abkürzung für „Time To Live". Es handelt sich um eine Einstellung, mit der der Cache nach einer bestimmten Zeit gelöscht wird. Wenn beispielsweise TTL auf 5 Sekunden eingestellt ist, wird der Cache nach 5 Sekunden automatisch gelöscht. Wenn es dann zu einem Cache-Fehler kommt, werden die Daten aus der RDB abgerufen und gespeichert.

Wie wird TTL dann eingestellt?

Lesen/Schreiben erfolgt auf einem Cache-Server

Wenn Lesen/Schreiben auf einem globalen Cache-Server wie Redis oder auf einem Anwendungsserver erfolgt, auf dem lokales Caching aktiviert ist, kann TTL auf einen Wert von mindestens einer Stunde erhöht werden. Schließlich werden beim Schreiben die vorhandenen Caches aktualisiert, und der Server, der Daten aus diesem Cache abruft, erhält immer aktualisierte Daten.

In diesem Fall kann TTL auch weggelassen werden, und der Cache-Server kann so konfiguriert werden, dass er automatisch und schrittweise Caches löscht, wenn er voll ist, indem der LRU-Algorithmus verwendet wird.

Lesen/Schreiben erfolgt auf mehreren Cache-Servern

Wenn Lesen/Schreiben auf mehreren globalen Cache-Servern oder auf mehreren Anwendungsservern erfolgt, auf denen lokales Caching aktiviert ist, sollte TTL auf einen Wert von Sekunden bis Minuten festgelegt werden. Dies liegt daran, dass die Möglichkeit besteht, dass alte Daten von Cache-Servern gelesen werden, die die aktualisierten Daten noch nicht reflektieren.

TTL wird in diesem Fall in verschiedenen Kontexten festgelegt. Je wichtiger die Aktualisierung ist und je höher die Wahrscheinlichkeit ist, dass sich der Wert ändert, desto kürzer sollte TTL sein. Je weniger wichtig die Aktualisierung ist und je geringer die Wahrscheinlichkeit ist, dass sich der Wert ändert, desto länger kann TTL sein.

Wie habe ich TTL konfiguriert?

Die Daten, die ich zwischenspeichern möchte, sind mit Zahlungen verbunden, und obwohl das Caching nicht für die strikte Logik angewendet wird, die tatsächlich Zahlungen verarbeitet, ist die Aktualisierung aufgrund der Art der Zahlungen wichtig. Allerdings ist die Wahrscheinlichkeit von Updates gering, so dass ich für TTL vorsichtshalber einen Wert von 5 Sekunden gewählt habe.

Fazit

Zusammenfassend lässt sich sagen, dass ich mich für folgende Caching-Methode entschieden habe:

• Daten im Zusammenhang mit Zahlungen
• Sehr häufige Abfragen, aber nur wenige Änderungen.
• Cache wird nur für Logiken angewendet, die tatsächlich nicht mit Zahlungen zusammenhängen, aber Abfragen durchführen.
• Lokales Caching angewendet, TTL auf 5 Sekunden eingestellt.

Als nächstes werde ich Leistungstests für die tatsächlich implementierte Caching-Methode durchführen. Wie ich die Leistungstests konkret durchführen werde, ist noch in Arbeit, daher werde ich das in einem späteren Beitrag beschreiben!