Edycja:Teraz, dzięki zaktualizowanemu kodowi, uważam, że Twoja metodologia jest zasadniczo wadliwa, poza tym, co zgłaszasz.
Sposób, w jaki go zaimplementowałeś, wymaga uruchomienia KEYS w produkcji - to jest złe. W miarę skalowania będziesz powodować rosnące i niepotrzebne blokowanie systemu na serwerze. Jak wynika z dokumentacji, nie użyj keys w produkcji. Pamiętaj, że zakodowanie czasu wygaśnięcia w nazwie klucza nie daje żadnych korzyści. Jeśli uczynisz tę część nazwy klucza znacznikiem czasu utworzenia lub nawet losową liczbą, nic by się nie zmieniło. Rzeczywiście, jeśli usuniesz ten fragment, nic się nie zmieni.
Bardziej rozsądną drogą byłoby zamiast tego użycie nazwy klucza, która nie jest zależna od czasu. Korzystanie z uchwytów wygaśnięcia, które działają dla Ciebie. Nazwijmy Twoją ograniczoną stawkę „sesją”. Twoja nazwa klucza bez sygnatury czasowej to „identyfikator sesji”. Po ustawieniu na nim wygaśnięcia 60 s, nie będzie już dostępny przy znaku 61 s. Dzięki temu możesz bezpiecznie zwiększać i porównywać wynik do swojego limitu bez konieczności znajomości aktualnego czasu lub czasu wygaśnięcia. Wszystko, czego potrzebujesz, to statyczna nazwa klucza i odpowiednia data ważności.
Jeśli INCR nieistniejący klucz, Redis zwróci „1”, co oznacza, że utworzył klucz i zwiększył go w jednym kroku/wywołaniu. więc logika wygląda tak:
- utwórz identyfikator „sesji”
- przyrost licznika za pomocą identyfikatora
- porównaj wynik z limitem
- jeśli liczba ==1, ustaw wygaśnięcie na 60s
- liczba identyfikatorów> limit, odrzuć
Krok 3.1 jest ważny. Liczba 1 oznacza, że jest to nowy klucz w Redis i chcesz ustawić na nim swoją wygaśnięcie. Wszystko inne oznacza, że wygaśnięcie powinno już być ustawione. Jeśli ustawisz go w 3.2, przerwiesz proces, ponieważ zachowa licznik przez ponad 60 sekund.
Dzięki temu nie musisz mieć dynamicznych nazw kluczy opartych na czasie wygaśnięcia, a zatem nie musisz używać keys aby dowiedzieć się, czy istnieje „sesja” dla obiektu o ograniczonej szybkości. Sprawia również, że Twój kod jest znacznie prostszy i przewidywalny, a także zmniejszy liczbę podróży w obie strony do Redis - co oznacza, że będzie on mniej obciążał Redis i działał lepiej. Co do tego, jak to zrobić z biblioteką klienta, której używasz, nie mogę powiedzieć, ponieważ nie jestem z nią zaznajomiony. Ale podstawowa sekwencja powinna być możliwa do przetłumaczenia, ponieważ jest dość podstawowa i prosta.
Nie pokazałeś jednak niczego, co potwierdzałoby twierdzenie, że wygaśnięcie nie ma miejsca. Wszystko, co zrobiłeś, to pokazanie, że rzeczywiście kazano Redisowi i ustalasz wygaśnięcie. Aby poprzeć swoje roszczenie, musisz wykazać, że klucz nie wygasł. Oznacza to, że musisz pokazać odzyskanie klucza po upływie czasu wygaśnięcia i że licznik nie został „zresetowany” przez odtworzenie po wygaśnięciu. Jednym ze sposobów, w jaki można zobaczyć, jak wygasa wygaśnięcie, jest użycie powiadomień o przestrzeni klawiszy. Dzięki temu będziesz mógł zobaczyć, jak Redis mówi, że klucz wygasł.
Ten proces trochę się nie powiedzie, jeśli wykonasz wiele okien w celu ograniczenia szybkości lub jeśli masz znacznie większe okno (tj. 10 minut), w którym to przypadku posortowane zestawy mogą być bardziej rozsądną opcją, aby zapobiec ładowaniu żądań z przodu - w razie potrzeby. Ale jak napisano twój przykład, powyższe będzie działać dobrze.
