Yo diría que está vinculado a la caducidad de la clave.
Las tiendas de clave/valor como Redis o Memcached no pueden permitirse definir un temporizador físico por objeto para que caduque. Habría demasiados de ellos. En su lugar, definen una estructura de datos para rastrear fácilmente los elementos que caducan y multiplexar todos los eventos de caducidad en un solo temporizador físico. También tienden a implementar una estrategia perezosa para hacer frente a estos eventos.
Con Redis, cuando un artículo caduca, no pasa nada. Sin embargo, antes de acceder a cada artículo, se realiza una verificación sistemática para evitar devolver artículos caducados y, potencialmente, eliminar el artículo. Además de esta estrategia perezosa, cada 100 milisegundos, se activa un algoritmo de recuperación para hacer caducar físicamente una cantidad de elementos (es decir, eliminarlos del diccionario principal). El número de claves consideradas en cada iteración depende de la carga de trabajo de vencimiento (el algoritmo es adaptativo).
La consecuencia es que Redis puede tener una acumulación de elementos que caducan en un momento dado, cuando tiene un flujo constante de eventos de caducidad.
Ahora, volviendo a la pregunta, el comando DBSIZE solo devuelve el tamaño del diccionario principal, por lo que incluye elementos caducados que aún no se han eliminado. El comando KEYS recorre todo el diccionario y accede a claves individuales, por lo que excluye todos los elementos caducados. Por lo tanto, es posible que el número de artículos no coincida.
