Sie sollten sich nicht um die aktuelle Befehlsausführung kümmern, sondern um die Auswirkungen auf alle anderen Befehle, da Redis Befehle mit einem einzigen Thread verarbeitet (d. h. während ein Befehl ausgeführt wird, müssen alle anderen warten, bis die Ausführung eines Befehls beendet ist).
Während keys oder scan Wenn Sie in Ihrem Fall eine ähnliche oder identische Leistung erzielen, die allein ausgeführt wird, werden einige Millisekunden, die Redis blockieren, die Gesamt-E / A erheblich verringern.
Dies ist der Hauptgrund für die Verwendung von keys für Entwicklungszwecke und scan in Produktionsumgebungen.
OP sagte:
"Während Schlüssel oder Scan Ihnen in Ihrem Fall eine ähnliche oder identische Leistung liefern könnten, wenn sie allein ausgeführt werden, werden einige Millisekunden, die Redis blockieren, die Gesamt-E/A erheblich verringern." - Dieser Satz scheint darauf hinzudeuten, dass ein Befehl Redis blockiert und der andere nicht, was nicht der Fall sein kann. Wenn mir 100 Ergebnisse von meinem Anruf bei KEYS garantiert werden, inwiefern ist es schlimmer als SCAN? Warum glauben Sie, dass ein Befehl anfälliger für Blockierungen ist?
Es sollte einen guten Unterschied geben, wann Sie die Suche paginieren können. Es ist nicht dasselbe, gezwungen zu sein, 100 Schlüssel in einem einzigen Durchgang zu erhalten, als in der Lage zu sein, Paginierung zu implementieren und 100 Schlüssel zu erhalten, 10 mal 10 (oder 50 und 50). Diese sehr kleine Unterbrechung kann dazu führen, dass andere Befehle, die von der Anwendungsschicht gesendet werden, von Redis verarbeitet werden . Sehen Sie sich an, was die offizielle Redis-Dokumentation dazu sagt:
Da diese Befehle eine inkrementelle Iteration ermöglichen und nur eine kleine Anzahl von Elementen pro Aufruf zurückgeben, können sie in der Produktion ohne die Nachteile von Befehlen wie KEYS oder SMEMBERS verwendet werden, die den Server für lange Zeit (sogar mehrere Sekunden) blockieren können, wenn sie gegen große Sammlungen von Schlüsseln aufgerufen werden oder Elemente
.
