Jag skulle säga att det är kopplat till nyckelns utgång.
Nyckel-/värdebutiker som Redis eller memcached har inte råd att definiera en fysisk timer per objekt som ska löpa ut. Det skulle bli för många av dem. Istället definierar de en datastruktur för att enkelt spåra objekt som ska förfalla, och multiplexa alla utgångshändelser till en enda fysisk timer. De tenderar också att implementera en lat strategi för att hantera dessa händelser.
Med Redis, när en vara går ut, händer ingenting. Men innan varje artikelåtkomst görs en kontroll systematiskt för att undvika att returnera utgångna varor och eventuellt radera varan. Utöver denna lata strategi, var 100:e ms, triggas en rensningsalgoritm för att fysiskt förfalla ett antal objekt (dvs. ta bort dem från huvudordboken). Antalet övervägda nycklar vid varje iteration beror på utgångsarbetet (algoritmen är adaptiv).
Konsekvensen är att Redis kan ha en eftersläpning av artiklar som ska förfalla vid en viss tidpunkt, när du har ett jämnt flöde av utgångshändelser.
För att nu komma tillbaka till frågan, DBSIZE-kommandot returnerar bara storleken på huvudordboken, så det inkluderar utgångna objekt som ännu inte har tagits bort. Kommandot KEYS går igenom hela ordboken och kommer åt enskilda nycklar, så det exkluderar alla utgångna objekt. Antalet artiklar kanske inte stämmer överens.