Ik zou zeggen dat het verband houdt met het verlopen van de sleutel.
Sleutel/waarde-winkels zoals Redis of memcached kunnen het zich niet veroorloven om een fysieke timer per object te definiëren om te verlopen. Het zouden er te veel zijn. In plaats daarvan definiëren ze een datastructuur om items die vervallen zijn gemakkelijk te volgen, en multiplexen ze alle expiratiegebeurtenissen naar een enkele fysieke timer. Ze hebben ook de neiging om een luie strategie te implementeren om met deze gebeurtenissen om te gaan.
Met Redis gebeurt er niets wanneer een item verloopt. Voordat elk item wordt geopend, wordt echter systematisch een controle uitgevoerd om te voorkomen dat verlopen items worden geretourneerd en mogelijk het item wordt verwijderd. Bovenop deze luie strategie wordt elke 100 ms een scavenger-algoritme geactiveerd om een aantal items fysiek te laten verlopen (d.w.z. ze uit het hoofdwoordenboek te verwijderen). Het aantal beschouwde sleutels bij elke iteratie hangt af van de expiratiebelasting (het algoritme is adaptief).
Het gevolg is dat Redis een achterstand kan hebben met items die op een bepaald moment vervallen, wanneer u een gestage stroom van expiratiegebeurtenissen heeft.
Nu terugkomend op de vraag, de opdracht DBSIZE retourneert gewoon de grootte van het hoofdwoordenboek, dus het bevat verlopen items die nog niet zijn verwijderd. Het KEYS-commando doorloopt het hele woordenboek en heeft toegang tot individuele sleutels, dus het sluit alle verlopen items uit. Het aantal items komt daarom mogelijk niet overeen.