AFAIK, es ist nicht möglich, Redis so zu konfigurieren, dass die älteren Daten zuerst konsistent entfernt werden.
Wenn die Optionen *-ttl oder *-lru in der maxmemory-policy ausgewählt werden, verwendet Redis keinen exakten Algorithmus, um die zu entfernenden Schlüssel auszuwählen. Ein exakter Algorithmus würde eine zusätzliche Liste (für *-lru) oder einen zusätzlichen Heap (für *-ttl) im Speicher erfordern und mit der normalen Datenstruktur des Redis-Wörterbuchs querverweisen. Es wäre teuer in Bezug auf den Speicherverbrauch.
Mit dem aktuellen Mechanismus treten Räumungen in der Hauptereignisschleife auf (d. h. potenzielle Räumungen werden bei jeder Schleifeniteration überprüft, bevor jeder Befehl ausgeführt wird). Bis der Speicher wieder unter der maximalen Speichergrenze liegt, wählt Redis nach dem Zufallsprinzip eine Stichprobe von n Schlüsseln aus und wählt für den Ablauf den untätigsten (für *-lru) oder denjenigen aus, der seiner Ablaufgrenze am nächsten liegt (für *-ttl). Standardmäßig werden nur 3 Proben berücksichtigt. Das Ergebnis ist nicht deterministisch.
Eine Möglichkeit, die Genauigkeit dieses Algorithmus zu erhöhen und das Problem zu mindern, besteht darin, die Anzahl der berücksichtigten Samples zu erhöhen (Parameter maxmemory-samples in der Konfigurationsdatei). Stellen Sie ihn nicht zu hoch ein, da dies etwas CPU verbrauchen wird. Es ist ein Kompromiss zwischen Entfernungsgenauigkeit und CPU-Verbrauch.
Wenn Sie jetzt wirklich ein konsistentes Verhalten benötigen, besteht eine Lösung darin, Ihren eigenen Entfernungsmechanismus zusätzlich zu Redis zu implementieren. Sie könnten beispielsweise eine Liste (für nicht aktualisierbare Schlüssel) oder eine sortierte Menge (für aktualisierbare Schlüssel) hinzufügen, um die Schlüssel zu verfolgen, die zuerst entfernt werden sollten. Dann fügen Sie einen Daemon hinzu, dessen Zweck es ist, regelmäßig (mit INFO) den Speicherverbrauch zu überprüfen und die Elemente der Liste/des sortierten Satzes abzufragen, um die relevanten Schlüssel zu entfernen.
Bitte beachten Sie, dass andere Caching-Systeme ihre eigene Art haben, mit diesem Problem umzugehen. Zum Beispiel gibt es bei Memcached eine LRU-Struktur pro Slab (was von der Objektgröße abhängt), daher ist die Räumungsreihenfolge auch nicht genau (obwohl in der Praxis deterministischer als bei Redis).
