Diese Woche haben wir uns mit einem Risiko befasst, das vor den Feiertagen entdeckt wurde. Ein Dienst, der Redis verwendete und keine TTL für den Schlüssel einstellte, sondern sich auf die Redis-Eliminierungsrichtlinie verließ. Ich sehe, dass dieser Dienst Redis mit einer LRU-Eliminierungsstrategie verwendet. Diese Strategie scheint perfekt zu sein, aber es gibt Fallstricke, wenn über einen bestimmten kürzeren Zeitraum viel Schreibverkehr stattfindet. Dann löst Redis den Eliminierungsprozess aus und gibt sein Bestes, um genügend Speicherplatz freizugeben. Das bedeutet, dass Redis normale Operationen wie Abfragen nicht mehr sehr gut ausführen kann. Dies führt zu dramatischen Schwankungen bei der Lese- und Schreiblatenz für Redis aus der Geschäftsschicht. Ich hatte dieses Problem bisher 2 Mal. Außerdem ist Redis ohne die Einstellung von TTL immer zu 100% ausgelastet, und wir können anhand der Kapazität nicht erkennen, wie viel gekaufte Kapazität für das aktuelle Geschäftsvolumen ausreicht. Es ist auch ungewiss, ob die Kosten durch eine Verringerung der Kapazität in den Zeiten geringerer Auslastung gesenkt werden können. Daher ist es sehr wichtig, ausreichend freien Platz für Redis zu lassen.
Daher muss ich den Dienst so ändern, dass für jeden neu geschriebenen Schlüssel eine TTL gesetzt wird. Nach der Logik von Redis wird auch eine TTL gesetzt, wenn der Schlüssel zum Zeitpunkt des Schreibens bereits existiert. Im Interesse der Stabilität des Geschäfts möchte ich nicht, dass für alle Schlüssel eine TTL gesetzt wird. Ich habe diese Option tatsächlich erforscht und die Notwendigkeit eines Cursors beim Traversieren genutzt. Die Länge des TTL-Satzes ist ebenfalls heikel. Um zu verhindern, dass eine große Anzahl von Schlüsseln gleichzeitig abläuft, was zu großen Schwankungen in der Latenzzeit führt, setzen Sie die TTL auf die Basisdauer der Zeit, nachdem Sie eine zufällige Länge hinzugefügt haben. Angenommen, die Basisdauer ist T, dann liegt die Länge der TTL nach Hinzufügen der Zufallsdauer zwischen T und 2T. Das bedeutet, je länger der Schlüssel bleiben muss, desto breiter ist die Verteilung des Ablaufs. Dies sorgt für eine gleichmäßigere Geschäftslatenz und verhindert eine Überlastung der Datenbank.
