Nie powinieneś przejmować się bieżącym wykonaniem polecenia, ale wpływem na wszystkie inne polecenia, ponieważ Redis przetwarza polecenia za pomocą jednego wątku (tj. podczas wykonywania polecenia wszystkie inne muszą poczekać, aż wykonanie jednego się zakończy).
Podczas gdy keys lub scan może zapewnić podobną lub identyczną wydajność wykonywaną samodzielnie w twoim przypadku, niektóre milisekundy blokujące Redis znacznie zmniejszą ogólne operacje we/wy.
To główny powód używania keys do celów programistycznych i scan w środowiskach produkcyjnych.
OP powiedział:
„Chociaż klucze lub skanowanie mogą zapewnić podobną lub identyczną wydajność, wykonywane samodzielnie w Twoim przypadku, niektóre milisekundy blokowania Redis znacznie zmniejszą ogólną liczbę operacji we/wy”. - To zdanie wydaje się wskazywać, że jedno polecenie blokuje Redisa, a drugie nie, co nie może mieć miejsca. Jeśli mam zagwarantowane 100 wyników z mojego wezwania do KEYS, w jakim sensie jest to gorsze od SKANOWANIA? Dlaczego uważasz, że jedno polecenie jest bardziej podatne na blokowanie?
Powinna istnieć duża różnica, kiedy możesz podzielić wyszukiwanie na strony. To nie to samo, co zmuszanie do uzyskania 100 kluczy w jednym przebiegu, niż możliwość zaimplementowania paginacji i uzyskania 100 kluczy, 10 na 10 (lub 50 i 50). Ta bardzo mała przerwa może pozwolić na przetwarzanie innych poleceń wysyłanych przez warstwę aplikacji przez Redis . Zobacz, co mówi o tym oficjalna dokumentacja Redis:
Ponieważ polecenia te pozwalają na stopniową iterację, zwracając tylko niewielką liczbę elementów na wywołanie, można ich używać w produkcji bez wad takich poleceń, jak KLUCZE lub SMEMBERS, które mogą blokować serwer na długi czas (nawet kilka sekund) w przypadku wywołania przeciwko dużym zbiorom kluczy lub elementy
.
