Neměli byste se starat o aktuální provádění příkazů, ale o dopad na všechny ostatní příkazy, protože Redis zpracovává příkazy pomocí jednoho vlákna (tj. zatímco je vykonáván příkaz, všechny ostatní musí čekat, dokud neskončí provádění jednoho).
Zatímco keys nebo scan vám může poskytnout podobný nebo identický výkon prováděný samostatně ve vašem případě, několik milisekund blokování Redis výrazně sníží celkové I/O.
Toto je hlavní důvod, proč používat keys pro účely vývoje a scan v produkčním prostředí.
OP řekl:
"Zatímco klíče nebo skenování vám mohou poskytnout podobný nebo identický výkon prováděný samostatně ve vašem případě, několik milisekund blokování Redis výrazně sníží celkové I/O." - Zdá se, že tato věta naznačuje, že jeden příkaz blokuje Redis a druhý ne, což nemůže být tento případ. Pokud mám zaručeno 100 výsledků z mého volání do KEYS, v čem je to horší než SCAN? Proč máte pocit, že jeden příkaz je náchylnější k blokování?
Když můžete vyhledávání stránkovat, měl by být dobrý rozdíl. Není to stejné být nucen získat 100 klíčů v jednom průchodu, než být schopen implementovat stránkování a získat 100 klíčů, 10 x 10 (nebo 50 a 50). Toto velmi malé přerušení umožňuje Redis zpracovat další příkazy odeslané aplikační vrstvou . Podívejte se, co o tom říká oficiální dokumentace Redis:
Protože tyto příkazy umožňují inkrementální iteraci a vracejí pouze malý počet prvků na volání, lze je použít ve výrobě bez nevýhod příkazů jako KEYS nebo SMEMBERS, které mohou blokovat server na dlouhou dobu (dokonce i několik sekund), když jsou volány proti velkým sbírkám klíčů. nebo prvky
.