Vous ne devez pas vous soucier de l'exécution de la commande en cours, mais de l'impact sur toutes les autres commandes, puisque Redis traite les commandes à l'aide d'un seul thread (c'est-à-dire que pendant qu'une commande est en cours d'exécution, toutes les autres doivent attendre jusqu'à ce que l'exécution d'une commande se termine).
Tandis que les keys ou scan peut vous fournir des performances similaires ou identiques exécutées seules dans votre cas, quelques millisecondes de blocage de Redis réduiront considérablement les E/S globales.
C'est la principale raison d'utiliser les keys à des fins de développement et scan sur les environnements de production.
OP a dit :
"Bien que les clés ou l'analyse puissent vous fournir des performances similaires ou identiques exécutées seules dans votre cas, quelques millisecondes de blocage de Redis réduiront considérablement les E/S globales." - Cette phrase semble indiquer qu'une commande bloque Redis, et l'autre non, ce qui ne peut pas être le cas. Si mon appel à KEYS me garantit 100 résultats, en quoi est-ce pire que SCAN ? Pourquoi pensez-vous qu'une commande est plus susceptible de bloquer ?
Il devrait y avoir une bonne différence lorsque vous pouvez paginer la recherche. Ce n'est pas la même chose d'être obligé d'obtenir 100 clés en une seule passe que de pouvoir implémenter la pagination et d'obtenir 100 clés, 10 par 10 (ou 50 et 50). Cette très petite interruption peut laisser d'autres commandes envoyées par la couche application être traitées par Redis . Voir ce que la documentation officielle de Redis dit à ce sujet :
Étant donné que ces commandes permettent une itération incrémentielle, ne renvoyant qu'un petit nombre d'éléments par appel, elles peuvent être utilisées en production sans l'inconvénient de commandes telles que KEYS ou SMEMBERS qui peuvent bloquer le serveur pendant une longue période (voire plusieurs secondes) lorsqu'elles sont appelées contre de grandes collections de clés. ou éléments
.
