AFAIK, není možné nakonfigurovat Redis tak, aby nejprve důsledně vymazal starší data.
Když jsou v maxmemory-policy zvoleny možnosti *-ttl nebo *-lru, Redis nepoužívá přesný algoritmus k výběru klíčů, které mají být odstraněny. Přesný algoritmus by vyžadoval další seznam (pro *-lru) nebo další haldu (pro *-ttl) v paměti a křížový odkaz na něj s normální datovou strukturou slovníku Redis. Bylo by to drahé z hlediska spotřeby paměti.
Se současným mechanismem dochází k vyřazení v hlavní smyčce událostí (tj. potenciální vyřazení jsou kontrolována při každé iteraci smyčky před provedením každého příkazu). Dokud paměť není zpět pod limitem maxmemory, Redis náhodně vybere vzorek n klíčů a pro vypršení vybere ten, který je nejvíce nečinný (pro *-lru) nebo ten, který je nejblíže jeho limitu vypršení (pro *-ttl). Standardně se berou v úvahu pouze 3 vzorky. Výsledek není deterministický.
Jedním ze způsobů, jak zvýšit přesnost tohoto algoritmu a zmírnit problém, je zvýšit počet uvažovaných vzorků (parametr maxmemory-samples v konfiguračním souboru). Nenastavujte jej příliš vysoko, protože bude spotřebovávat určité množství CPU. Je to kompromis mezi přesností vystěhování a spotřebou CPU.
Nyní, pokud opravdu požadujete konzistentní chování, jedním z řešení je implementovat svůj vlastní mechanismus vystěhování na Redis. Můžete například přidat seznam (pro neaktualizovatelné klíče) nebo seřazenou sadu (pro aktualizovatelné klíče), abyste mohli sledovat klíče, které by měly být vyřazeny jako první. Poté přidáte démona, jehož účelem je periodicky kontrolovat (pomocí INFO) spotřebu paměti a dotazovat se na položky seznamu/seřazené sady, abyste odstranili příslušné klíče.
Upozorňujeme, že jiné systémy ukládání do mezipaměti mají svůj vlastní způsob, jak se s tímto problémem vypořádat. Například u memcached existuje jedna struktura LRU na desku (která závisí na velikosti objektu), takže pořadí vystěhování také není přesné (ačkoli v praxi determinističtější než u Redis).