Je dirais que c'est lié à l'expiration de la clé.
Les magasins clé/valeur comme Redis ou memcached ne peuvent pas se permettre de définir une minuterie physique par objet pour expirer. Il y en aurait trop. Au lieu de cela, ils définissent une structure de données pour suivre facilement les éléments à expirer et multiplexer tous les événements d'expiration en une seule minuterie physique. Ils ont également tendance à mettre en œuvre une stratégie paresseuse pour faire face à ces événements.
Avec Redis, lorsqu'un élément expire, rien ne se passe. Cependant, avant chaque accès à un article, une vérification est systématiquement effectuée pour éviter de renvoyer des articles périmés, et éventuellement de supprimer l'article. En plus de cette stratégie paresseuse, toutes les 100 ms, un algorithme de nettoyage est déclenché pour expirer physiquement un certain nombre d'éléments (c'est-à-dire les supprimer du dictionnaire principal). Le nombre de clés considérées à chaque itération dépend de la charge de travail d'expiration (l'algorithme est adaptatif).
La conséquence est que Redis peut avoir un arriéré d'éléments devant expirer à un moment donné, lorsque vous avez un flux constant d'événements d'expiration.
Revenons maintenant à la question, la commande DBSIZE renvoie simplement la taille du dictionnaire principal, elle inclut donc les éléments expirés qui n'ont pas encore été supprimés. La commande KEYS parcourt l'ensemble du dictionnaire, accédant à des clés individuelles, de sorte qu'elle exclut tous les éléments expirés. Le nombre d'éléments peut donc ne pas correspondre.
