Jeg vil sige, at det er knyttet til nøgleudløb.
Nøgle-/værdilagre som Redis eller memcached har ikke råd til at definere en fysisk timer pr. objekt, der udløber. Dem ville der være for mange af. I stedet definerer de en datastruktur for nemt at spore elementer, der skal udløbe, og multiplekser alle udløbsbegivenheder til en enkelt fysisk timer. De har også en tendens til at implementere en doven strategi for at håndtere disse begivenheder.
Med Redis, når en vare udløber, sker der intet. Inden hver vareadgang foretages der dog systematisk en kontrol for at undgå at returnere udløbne varer, og potentielt slette varen. Oven i denne dovne strategi, hver 100 ms, udløses en scavenger-algoritme til fysisk at udløbe en række elementer (dvs. fjerne dem fra hovedordbogen). Antallet af overvejede nøgler ved hver iteration afhænger af udløbsarbejdsbelastningen (algoritmen er adaptiv).
Konsekvensen er, at Redis kan have et efterslæb af varer, der skal udløbe på et givet tidspunkt, når du har en konstant strøm af udløbsbegivenheder.
Når vi nu vender tilbage til spørgsmålet, returnerer DBSIZE-kommandoen bare størrelsen på hovedordbogen, så den inkluderer udløbne elementer, der endnu ikke er blevet fjernet. Kommandoen KEYS går gennem hele ordbogen og får adgang til individuelle nøgler, så den udelukker alle udløbne elementer. Antallet af varer kan derfor ikke matche.