No debería preocuparse por la ejecución del comando actual, sino por el impacto en todos los demás comandos, ya que Redis procesa los comandos usando un solo subproceso (es decir, mientras se ejecuta un comando, todos los demás deben esperar hasta que finalice la ejecución).
Mientras keys o scan podría proporcionarle un rendimiento similar o idéntico ejecutado solo en su caso, algunos milisegundos que bloquean Redis reducirán significativamente la E/S general.
Esta es la razón principal para usar keys para fines de desarrollo y scan en entornos de producción.
OP dijo:
"Si bien las teclas o el escaneo pueden brindarle un rendimiento similar o idéntico ejecutado solo en su caso, algunos milisegundos que bloquean Redis disminuirán significativamente la E/S general". - Esta oración parece indicar que un comando bloquea Redis y el otro no, lo que no puede ser el caso. Si tengo garantizados 100 resultados de mi llamada a KEYS, ¿de qué manera es peor que SCAN? ¿Por qué cree que un comando es más propenso a bloquearse?
Debería haber una buena diferencia cuando puede paginar la búsqueda. No es lo mismo estar obligado a sacar 100 claves de una sola pasada que poder implementar la paginación y sacar 100 claves, 10 por 10 (o 50 y 50). Esta pequeña interrupción puede permitir que Redis procese otros comandos enviados por la capa de aplicación . Vea lo que dice la documentación oficial de Redis sobre esto:
Dado que estos comandos permiten una iteración incremental, devolviendo solo una pequeña cantidad de elementos por llamada, se pueden usar en producción sin la desventaja de comandos como KEYS o SMEMBERS que pueden bloquear el servidor durante mucho tiempo (incluso varios segundos) cuando se les llama contra grandes colecciones de claves. o elementos
.
