AFAIK, nie jest możliwe skonfigurowanie Redis, aby najpierw konsekwentnie eksmitować starsze dane.
Gdy opcje *-ttl lub *-lru są wybrane w maxmemory-policy, Redis nie używa dokładnego algorytmu do wybierania kluczy do usunięcia. Dokładny algorytm wymagałby dodatkowej listy (dla *-lru) lub dodatkowej sterty (dla *-ttl) w pamięci i odniesienia go do normalnej struktury danych słownika Redis. Byłoby to kosztowne pod względem zużycia pamięci.
Przy obecnym mechanizmie eksmisje występują w głównej pętli zdarzeń (tj. potencjalne eksmisje są sprawdzane przy każdej iteracji pętli przed wykonaniem każdego polecenia). Dopóki pamięć nie znajdzie się z powrotem w maksymalnym limicie pamięci, Redis losowo wybiera próbkę n kluczy i wybiera do wygaśnięcia najbardziej bezczynny (dla *-lru) lub ten, który jest najbliższy jego limitowi wygaśnięcia (dla *-ttl). Domyślnie brane są pod uwagę tylko 3 próbki. Wynik nie jest deterministyczny.
Jednym ze sposobów na zwiększenie dokładności tego algorytmu i złagodzenie problemu jest zwiększenie liczby rozważanych próbek (parametr maxmemory-samples w pliku konfiguracyjnym). Nie ustawiaj go zbyt wysoko, ponieważ będzie to zużywać trochę procesora. Jest to kompromis między dokładnością eksmisji a zużyciem procesora.
Teraz, jeśli naprawdę potrzebujesz spójnego zachowania, jednym z rozwiązań jest wdrożenie własnego mechanizmu eksmisji w oparciu o Redis. Na przykład, możesz dodać listę (dla kluczy nieaktualizowalnych) lub posortowany zestaw (dla kluczy aktualizowalnych) w celu śledzenia kluczy, które powinny być najpierw eksmitowane. Następnie dodajesz demona, którego celem jest okresowe sprawdzanie (za pomocą INFO) zużycia pamięci i wysyłanie zapytań o elementy listy/posortowanego zestawu w celu usunięcia odpowiednich kluczy.
Należy pamiętać, że inne systemy buforowania mają swój własny sposób radzenia sobie z tym problemem. Na przykład w przypadku memcached istnieje jedna struktura LRU na płytę (która zależy od rozmiaru obiektu), więc kolejność eksmisji również nie jest dokładna (chociaż w praktyce jest bardziej deterministyczna niż w przypadku Redis).
