Ich würde sagen, es hängt mit dem Ablauf des Schlüssels zusammen.
Key/Value Stores wie Redis oder Memcached können es sich nicht leisten, einen physischen Timer pro Objekt zu definieren, der abläuft. Es wären zu viele von ihnen. Stattdessen definieren sie eine Datenstruktur, um ablaufende Elemente einfach zu verfolgen, und multiplexen alle Ablaufereignisse zu einem einzigen physischen Zeitgeber. Sie neigen auch dazu, eine faule Strategie anzuwenden, um mit diesen Ereignissen umzugehen.
Bei Redis passiert nichts, wenn ein Element abläuft. Vor jedem Artikelzugriff wird jedoch systematisch eine Überprüfung durchgeführt, um die Rückgabe abgelaufener Artikel zu vermeiden und den Artikel möglicherweise zu löschen. Zusätzlich zu dieser faulen Strategie wird alle 100 ms ein Scavenger-Algorithmus ausgelöst, um eine Reihe von Elementen physikalisch ablaufen zu lassen (d. h. sie aus dem Hauptwörterbuch zu entfernen). Die Anzahl der berücksichtigten Schlüssel bei jeder Iteration hängt von der Ablaufarbeitslast ab (der Algorithmus ist adaptiv).
Die Folge davon ist, dass Redis zu einem bestimmten Zeitpunkt einen Rückstand von Elementen haben kann, die ablaufen, wenn Sie einen stetigen Fluss von Ablaufereignissen haben.
Zurück zur Frage:Der DBSIZE-Befehl gibt nur die Größe des Hauptwörterbuchs zurück, sodass es abgelaufene Elemente enthält, die noch nicht entfernt wurden. Der KEYS-Befehl durchläuft das gesamte Wörterbuch und greift auf einzelne Schlüssel zu, sodass er alle abgelaufenen Elemente ausschließt. Die Anzahl der Artikel kann daher nicht übereinstimmen.
